Message-Id: <200402231607.i1NG789i14093412@clink.americas.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: Re: DMAPI test suite. 
Date: Mon, 23 Feb 2004 10:07:08 -0600
From: Dean Roehrich <roehrich@clink.americas.sgi.com>
Sender: linux-xfs-bounce@oss.sgi.com
Errors-to: linux-xfs-bounce@oss.sgi.com
Precedence: bulk


>From:  Ram Pai <linuxram@us.ibm.com>
>Looking through the xfs dmapi code, 2 questions pop up:
>1. How can the pre_unmount event, when generated through the put_super()
>code provide the DM_UNMOUNT_FORCE information.  There is now way for the
>put_super() code to know if the unmount is a forceful one or not. 

Our implementation does not use this UNMOUNT_FORCE feature, even on Irix, so I
can't fall back to an example.  I don't see the Linux MNT_FORCE option going
all that far down the stack.

The operation s_op->umount_begin looks like a valid place to insert the
PREUNMOUNT event, with UNMOUNT_FORCE implied.  The comment in do_umount makes
it sound like it's almost tailored to DMAPI's needs.  Unfortunately,
s_op->umount_begin is not general-purpose--it works only for MNT_FORCE and it
uses lock_kernel().


>2. And finally I find that all the DMAPI event generators are stubbed
>to   fs_nosys or fs_noerr or fs_noval . So does XFS ever generate DM
>events ?

You'll need the XFS code from oss.sgi.com.


>> Al Viro is distinctly anti dmapi, so chances are slim to none I would
>> say.
>
>hmm...that makes it difficult. Is he against Dmapi implemented in VFS or
>against the overall idea of supporting DMAPI anywhere in linux?  I hope
>he is just against DMAPI implemented at the VFS level and is ok with 
>supporting filesystems to implement it. 

The implementation is just an easy target.  The spec is the root of the
objections.  This preunmount discussion highlights some of it.

Which HSM are you working with now?  Is this HPSS, or something else?  Are you
attempting to make DMAPI work with other filesystems?


Dean