On Sun, Jan 24, 2016 at 11:53:04AM +1100, Dave Chinner wrote:
> > readdir() is another potential target for weaker exclusion (i.e. switching
> > it to taking that thing shared), but that's a separate story and I'd prefer
> > to deal with ->lookup() first. There are potentially hairy issues around
> > the instances that pre-seed dcache and I don't want to mix them into the
> > initial series.
>
> So you're doing this for purely to enable lookup concurrency, not
> for anyone else to be able to use the inode lock as a read/write
> lock? Can anyone use the inode rwsem as a read/write lock for their
> own purposes? If so, we can probably use it to replace the XFS
> IOLOCK and so effectively remove a layer of locking in various
> XFS IO paths. What's the policy you are proposing here?
Depends... I definitely want to keep directory modifiers with that thing
taken exclusive, with lookup and possibly readdir - shared. Non-directories...
it's mostly up to filesystems; the only place where VFS cares is setattr
and {set,remove}xattr, and that probably should stay exclusive (or be
separated, for that matter, but I hadn't looked into implications of that;
we probably can do that, but there might be dragons).
For data operations on regular files it's probably up to filesystems, as
i_mutex is now. Not sure if IOLOCK would map well on that; can you live with
that thing taken outside of transaction?
--
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
