On Thu, Jan 19, 2012 at 01:39:47PM -0600, Ben Myers wrote:
> I would like to discuss how to get DMAPI accepted into the mainline
> kernel. DMAPI is or was supported by a number of filesystems which are
> included in linux (including XFS) and also is supported by a number of
> proprietary filesystems. However, the DMAPI implementation has not yet
> been accepted into the main line.
> - What are the barriers to inclusion and how can they be resolved?
The grotty DMAPI interface. That includes both the high-level ioctl
implementations as well as lower level details.
In the end most of it boils down to three things:
- a notification API telling the daemon about changes, and allowing
it to block them. That's in some ways fairly similar to fanotify,
which should be reused. Preferably including the interface, but at
the very least the underlying implementation.
- a handle based I/O method. We now have open by handle at the VFS,
so it might just need a few additions like the invisible I/O flag.
- ways to make extents offline in the fs, and set various HSM specific
flags. This is the actual filesystem-specific piece of code, but
we'll need to think about an interface to query and set these bits.
filesystem-specific piece of code.
> - What FOSS HSM projects are available to use the interface?
> * xfstests/dmapi/sample_hsm
That actually seems to be the only one.
> * openhsm (opensms)
While that one has HSM in the name it actually seems to work quite
differently from the traditional partially offline HSM model, nevermind
that it seems abandoned.
> * tinyhsm (unfinished, unreleased)
> In the end I'd like to come up with a plan that seems reasonable toward
> getting DMAPI included mainline. I know that Alex Elder and others have
> done work in this area and I would like to see it bear fruit.
I'm not really sure discussing this grand highlevel design without
backing code really fits for LSF. Might be a fine topic for a BOF
if enough interested people are around.