[Ocfs2-devel] 答复: [patch -next] ocfs2: Add the trace_ocfs2_read_blocks_end

[zhangqilong <zhangqilong3@huawei.com>]

Hi, Joseph

I think it makes sense, the 'begin' trace entry will always be paired 
with 'end'. For the post processing the trace, it would be easier to 
reconstruct such reading block operation and mark immediately as 'not sent' (avoiding 
to bother about entries which only have 'begin'). Logging an error message could help 
locate problems quickly in case error.
It looks good to me, so feel free to add it.

Best wish, thanks,
Zhang Qilong

> -----????-----
> ???: Joseph Qi [mailto:joseph.qi at linux.alibaba.com]
> ????: 2020?10?19? 15:46
> ???: zhangqilong <zhangqilong3@huawei.com>; mark at fasheh.com;
> jlbec at evilplan.org
> ??: ocfs2-devel at oss.oracle.com
> ??: Re: [patch -next] ocfs2: Add the trace_ocfs2_read_blocks_end
> 
> 
> 
> On 2020/10/16 17:11, Zhang Qilong wrote:
> > Missing the trace_ocfs2_read_blocks_end when reading blocks fails.>
> Why do you need the trace in case error?
> In general, it will log an error message if fail.
> 
> Thanks,
> Joseph
> 
> > Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
> > ---
> >  fs/ocfs2/buffer_head_io.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/fs/ocfs2/buffer_head_io.c b/fs/ocfs2/buffer_head_io.c
> > index f0b104e483d8..0e6ee6e9b201 100644
> > --- a/fs/ocfs2/buffer_head_io.c
> > +++ b/fs/ocfs2/buffer_head_io.c
> > @@ -395,11 +395,10 @@ int ocfs2_read_blocks(struct ocfs2_caching_info
> *ci, u64 block, int nr,
> >  	}
> >  	ocfs2_metadata_cache_io_unlock(ci);
> >
> > +bail:
> >  	trace_ocfs2_read_blocks_end((unsigned long long)block, nr,
> >  				    flags, ignore_cache);
> >
> > -bail:
> > -
> >  	return status;
> >  }
> >
> >