Re: [RFC PATCH 0/6] xfs: truncate vs page fault IO exclusion

[Dave Chinner <david@fromorbit.com>]

On Thu, Jan 08, 2015 at 04:24:48AM -0800, Christoph Hellwig wrote:
> > This patchset passes xfstests and various benchmarks and stress
> > workloads, so the real question is now:
> > 
> > 	What have I missed?
> > 
> > Comments, thoughts, flames?
> 
> Why is this done in XFS and not in generic code?

We might be able to do that. Indeed, if the concept is considered
sound, then this was the next question I was going to ask everyone.
I just don't know enough about other filesystem locking to be able
to say "this will always work", hence the wide distribution of the
RFC.  Different filesystems have different locking heirarchies, and
so there may be some are not able to use this technique
(cluster/network fs?)....

In the end, however, the main reason I decided on doing it in XFS
first was things like that swap extent operation that requires us to
lock multiple locks on two inodes in a specific order. We already
have all the infrastructure in XFS to enforce and *validate at
runtime* the specific lock ordering required, so it just made it a
no-brainer to do it this way first.

We also have several entry points in XFS that don't go through the
VFS that needed this page fault serialisation and they currently
only use XFS internal locks to serialise against IO.  Again, doing
it in XFS first is the easy-to-validate solution.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>