Re: [PATCH 00/15] xfs: minimize DMAPI footprint

From: Dave Chinner
Date: Tue Jun 29 2010 - 20:20:52 EST

On Tue, Jun 29, 2010 at 03:57:34AM -0400, Christoph Hellwig wrote:
> > SGI has a product that uses the DMAPI support code that's
> > included in mainline XFS, along with some additional code
> > (the "never merged" stuff Christoph refers to) that we
> > maintain separately. To our customers that need it, this
> > is an extremely important feature.
> So why don't you bother to get HSM support upstream properly,
> or at least maintain it somewhere where you can get at it?
> What sourcxe tree do those important customers use it?
> > What follows is a set of patches that I think accomplishes
> > these goals. The net result of these changes is:
> While this is a lot better than the old DMAPI supoort, it's still
> lots of dead code in the mainline tree, that won't ever be used
> there, as proper HSM suport if it ever was merged would sit at
> the VFS layer.

My question about the DMAPI hooks also still stands - if we leave
the hooks in mainline, how are we supposed to test that they are
still placed correctly for the out-of-tree patches to function
correctly? I can't see that we can actually do this, so I question
the value of even leaving minimal hooks in place....

> In addition to that the people who effectively maintain XFS for both
> the community and lots of paying customers have done a large amount
> of work ontop of the DMAPI removal of the last 1 1/2 month. So I'd
> say rebase your changes over
> and keep them in a separate branch dmapi-dev branch where SGI can pull
> the code for it's customers from. This branch could also include the
> actual dmapi code and core kernel modifications, so that people that
> want dmapi support actually have chance to find a complete kernel tree
> for it.

This makes a lot of sense to me. I'd prefer an all-or-nothing
approach to supporting DMAPI (and any other out-of-tree enabling
functionality for that matter) and putting it all in separate
branch would give us both all and nothing. ;)

It would also help us test the DMAPI infrastructure without needing
a HSM as the xfsqa test suite does a pretty good job of testing it.
And, of course, we could also help clean it up if it is testable. As
such, I'd be quite happy to maintain a dmapi-dev branch in the above
repo if the eventual goal is to try to move the code towards being
more acceptible for mainline inclusion....


Dave Chinner
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at