[Top] [All Lists]

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

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 00/15] xfs: minimize DMAPI footprint
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 30 Jun 2010 10:20:43 +1000
Cc: Alex Elder <aelder@xxxxxxx>, xfs@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
In-reply-to: <20100629075734.GA31118@xxxxxxxxxxxxx>
References: <1277762653.2040.554.camel@doink> <20100629075734.GA31118@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
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
> http://git.kernel.org/?p=linux/kernel/git/dgc/xfsdev.git;a=shortlog;h=refs/heads/for-2.6.36
> 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

<Prev in Thread] Current Thread [Next in Thread>