Re: [RFC 0/8] Xattr inode operation removal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2016-05-03 at 13:49 +0200, Andreas Gruenbacher wrote:
> On Tue, May 3, 2016 at 4:40 AM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote:
> > Hi Andreas,
> >
> > On Tue, 2016-05-03 at 00:45 +0200, Andreas Gruenbacher wrote:
> >> Hi all,
> >>
> >> what are your thoughts on this patch set?  It applies on top of the
> >> work.xattr branch [*], converts the remaining filesystems over to xattr
> >> handlers, and replaces the getxattr, setxattr, and removexattr inode
> >> operations.  The only way to implement getxattr, setxattr, and
> >> removexattr with this approach is through xattr handlers.
> >
> > The patch description should provide the motivation/reason for the
> > change (eg. performance, locking).  Up to now these xattr functions
> > required the caller to take the i_mutex.  Is the i_mutex still required?
> 
> Yes, the documentation needs updating. The locking rules are still the same.

I meant to say, this cover letter needs to provide the motivation/reason
for the change(s).   From my perspective, the main motivation would
either be "locking" or keeping the file data and metadata in sync.  If
these aren't the motivation/reasons for the change, please provide an
explanation.

thanks,

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux