[PATCH] JFS DMAPI

[PATCH] JFS DMAPI

[Dave Kleikamp]

Andrew,
Would you consider adding this patch to -mm?  This would add the DMAPI
interface to JFS.  This function has long been requested by HSMs
(Hierarchical Storage Managers).  It is based on SGI's XFS
implementation, but has been clean up to avoid their vnode interface.

Most of the code is in the fs/jfs/dmapi subdirectory.  The amount of
code in the normal jfs codepaths is quite small.  There is no code
outside of fs/jfs.

Due to the size of the patch, I haven't included it here, but it can be
downloaded from
http://www10.software.ibm.com/developer/opensource/jfs/project/pub/dmapi/dmapi-2.6.4-rc2.patch

There is a user library which can be downloaded at
http://oss.software.ibm.com/jfs/

Thanks,
Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

Re: [PATCH] JFS DMAPI

[Andreas Dilger]

On Mar 04, 2004  17:54 -0600, Dave Kleikamp wrote:
> Would you consider adding this patch to -mm?  This would add the DMAPI
> interface to JFS.  This function has long been requested by HSMs
> (Hierarchical Storage Managers).  It is based on SGI's XFS
> implementation, but has been clean up to avoid their vnode interface.
> 
> Most of the code is in the fs/jfs/dmapi subdirectory.  The amount of
> code in the normal jfs codepaths is quite small.  There is no code
> outside of fs/jfs.

It looks like the largest portion of this code is actually not JFS specific.
Why not put the common code into fs/dmapi instead of fs/jfs/dmapi and then
there will be some possibility that the XFS and JFS DMAPI implementations
will become a single one (only one place to fix bugs, etc), and also give
the opportunity to have DMAPI support in other filesystems?

I'm sure Christoph will jump all over this (even though his name is in the
code), so I thought I'd do it nicely first ;-).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [PATCH] JFS DMAPI

[Christoph Hellwig]

On Thu, Mar 04, 2004 at 05:20:46PM -0700, Andreas Dilger wrote:
> I'm sure Christoph will jump all over this (even though his name is in the
> code), so I thought I'd do it nicely first ;-).

My name is only in the compat wrappers for the IRIX synchronizcations
primites.  And the existance of those in code under fs/jfs just shows what
a huge hack this is..

Re: [PATCH] JFS DMAPI

[Christoph Hellwig]

On Thu, Mar 04, 2004 at 05:54:52PM -0600, Dave Kleikamp wrote:
> Andrew,
> Would you consider adding this patch to -mm?  This would add the DMAPI
> interface to JFS.  This function has long been requested by HSMs
> (Hierarchical Storage Managers).  It is based on SGI's XFS
> implementation, but has been clean up to avoid their vnode interface.

Umm, no.  There's a reason the XFS code this is based on isn't merged, and
the problem is the DMAPI spec.  E.g. you still have this utterly incompatible
to Linux semantics of providing a mount option to specifiy the canonical
name for a mount  point as dmapi doesn't understand the concept of multiple
mounts for a given fs or namespaces, you still don't get the post-unmount
even rights, the handle2path stuff is still as broken, how do you handle
the mprotect vs dmapi regions interaction the 2.4 XFS tree has the mprotect
vm operation hack for, etc..?

So the question is whether IBM just wants to provide this for customers that
can live with the incompatbilities or really wants to provide HSM support
for mainline.

In the first case I'd suggest you clean up the changes to the JFS core to
not require ifdefs all over the place and submit that one for mainline
inclusion so the dmapi dir can more less be dropped into the tree ala
XFS.

If IBM actually wants to support proper HSM support for Linux let's go back
to the drawing board.  Some specific requirements:

 - move the events from fs-specific code to common code.  That we have two
   filesystems now that want it shows pretty much that fs-specific code
   is the wrong place.
 - get rid of the concept of a canoical path in kernelspace.  If userspace
   wants it they can't search the mount tab for the right st_dev to provide
   dmapi semantics.
 - clean up the whole ioctl API mess.  I think we'd mostly be done with
   a O_HSM option for open to avoid interactions with the callouts and some
   generic handle API.