Re: dropping dmapi support, was Re: [PATCH 00/17] pending patches

[Dave Chinner <david@fromorbit.com>]

On Thu, Jun 03, 2010 at 01:08:18PM -0400, Christoph Hellwig wrote:
> On Thu, Jun 03, 2010 at 12:01:46PM -0500, Alex Elder wrote:
> > I would like to have a chance to submit an alternative to simply
> > removing that code.  I recognize it sits in the first part of your
> > patch series, and I will gladly do the work to rearrange them to
> > put it at the end, in order to give me some time to develop my
> > proposed change.
> > 
> > Basically what I'd like to do is update the DMAPI support code
> > so that it is much better isolated.  I would like to replace
> > the big ugly hunks that lie in common code paths with small
> > function calls, so that their footprint is minimal and not
> > distracting (along the lines of tracing calls).
> > 
> > I got a start on doing this, and had hoped to send the result
> > pretty soon after your initial posting of the patch, but that
> > work unfortunately got preempted by other more pressing stuff.
> > I wanted to provide actual code to help make the discussion
> > of the merits of removal versus cleanup more concrete.  I
> > now think I'll be able to put something together within the
> > next week or so.
> 
> I don't think it's a good idea.  I'm happy to not burn all bridges
> and leave certain code structured in a way that makes adding it easier,
> but if the hooks are as easy as you say above they can easily live in
> an out of tree patchset.  The general Linux kernel policy is that we
> don't keep hooks for out of tree code around, and I tend to agree to
> it.  We kept all that dmapi cruft in, and it's never served any
> purpose for us.  I think that HSM support is actually a very useful
> feature, but the a kernel interface based on the DMAPI specification
> much less so, and the horrible SGI implementation that used to be
> in the XFS CVS tree even less so.
> 
> If you want to push a new one the metadata hooks really need to be
> entirely outside the low-level filesystem, that is before calling
> into the namespace inode operations, which is easily doable even
> while keeping the current DMAPI core.

Regardless of the implementation cruftiness, I think this a much
better approach. The events and checks really aren't XFS specific,
and putting them at a higher level cleanly separates the filesystem
functionality from the event+blocking functionality of DMAPI.

> But what's much more difficult is the read/write path.  The dmapi
> code really gets in the way there, and I have additional simplification
> of this code pending that require this cruft to go away.  XFS currently
> has a needlessly complicated write path, and getting closer to the
> generic code will help us with lots of things like the upcoming multi
> page write support.

That is true, and also intervening higher up in the IO path for
DMAPI would avoid a lot of the locking complexity that XFS has to go
through now to be able to block on events in dmapi calls.

Further, with ext4 gaining a persitent handle interface, adding
DMAPI to the VFS would also enable HSMs to work on more than just
XFS...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs