[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <db947cce565d9ae766906d6f131cd9e2cf58cb7f.camel@zoho.com.cn>
Date: Fri, 24 May 2019 16:58:37 +0800
From: "cgxu519@...o.com.cn" <cgxu519@...o.com.cn>
To: Jan Kara <jack@...e.cz>
Cc: jack@...e.com, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext2: optimize ext2_xattr_get()
On Fri, 2019-05-24 at 10:07 +0200, Jan Kara wrote:
> On Fri 24-05-19 10:07:05, cgxu519@...o.com.cn wrote:
> > On Thu, 2019-05-23 at 16:46 +0200, Jan Kara wrote:
> > > On Tue 21-05-19 16:21:39, Chengguang Xu wrote:
> > > > Since xattr entry names are sorted, we don't have
> > > > to continue when current entry name is greater than
> > > > target.
> > > >
> > > > Signed-off-by: Chengguang Xu <cgxu519@...o.com.cn>
> > >
> > > Thanks for the patch! If we are going to do these comparisons in multiple
> > > places, then please create a helper function to do the comparison (so that
> > > we have the same comparison in every place). Something like:
> > >
> > > int ext2_xattr_cmp(int name_index, size_t name_len, const char *name,
> > > struct ext2_xattr_entry *entry)
> > >
> >
> > Hi Jan,
> >
> > Thanks for the review and advice.
> >
> > You are right we should introduce a helper to handle this part of work
> > and personally I think maybe implementing a helper to find target entry
> > will be more useful, do you think it makes sense?
>
> It makes sense but ext2_xattr_set() also computes min_offs and last during
> the search so using the search function in that case won't be a readbility
> win I guess. So I'm not sure the search function pays off in the end.
Yes, I noticed that too, I plan to set min_offs pointer as function parameter
so that we can seperate different search modes based on it.
Thanks,
Chengguang
Powered by blists - more mailing lists