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