lkml.org 
[lkml]   [2016]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [git pull] vfs.git - including i_mutex wrappers
On Sun, Jan 24, 2016 at 06:04:06PM +1100, Dave Chinner wrote:

> Hence even for ->setattr, we can remove the IOLOCK usage if the
> vfs takes the the new i_rwsem in exclusive mode because we would
> still have a functional IO submission barrier....
>
> > 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?
>
> Yes. IOLOCK has the same scope as i_mutex in the IO path.

Umm... So e.g. xfs_create() could take IOLOCK before xfs_trans_reserve()?
If so, you probably could eventually be able to use ->i_rwsem for it (and
drop it in places where it's already taken by method callers). I'm nowhere
near being familiar enough with details of fs/xfs locking to tell how much
PITA would the last part be - e.g. a function used both inside ->lookup()
and in ->read_iter() and currently taking IOLOCK shared would need to
have it lifted into both callers and removed from ->lookup(), etc., which
might or might not be painful.

\
 
 \ /
  Last update: 2016-01-24 09:01    [W:0.038 / U:1.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site