[Top] [All Lists]

Re: vfs_altfsid & dm_fsid

To: Aurelien Degremont - Stagiaire <degremont@xxxxxxxxxxx>
Subject: Re: vfs_altfsid & dm_fsid
From: Dean Roehrich <roehrich@xxxxxxx>
Date: Fri, 13 May 2005 11:57:27 -0500
Cc: linux-xfs@xxxxxxxxxxx
Sender: linux-xfs-bounce@xxxxxxxxxxx
>From:  Aurelien Degremont - Stagiaire <degremont@xxxxxxxxxxx>

>'dm_register_and_send_mount_event' (like dm_find_fsreg_and_lock ? :))
>Not really short but at least, very clear :).
>It is seems a good idea to register the filesystem in the same time it 
>is mounted, but this implies a huge and ugly dmapi send mount event 
>function ;)

Even in its current form, dm_send_mount_event() is a dual-purpose call.  It's
responsible for registering the filesystem with dmapi, and for sending a mount

I think you, and Christoph, would be advocating a split between
dm_send_mount_event() and dm_add_fsys_entry().  Moving dm_add_fsys_entry()
from dm_enqueue_mount_event() to dm_send_mount_event() is an obvious first
move.  Maybe the tokevent would not be created for the dm_add_fsys_entry()
call, but would be attached to the dm_fsreg_t later, before
dm_enqueue_mount_event() is called.  I'm not sure how much breakage we'll run

That would allow something like this:

        struct super_block *sb,
        dm_fsid_t *fsid,
        struct filesystem_dmapi_operations *dops)

        This would be a stripped-down version of today's dm_send_mount_event()
        but would call dm_add_fsys_entry() to create a stripped-down
        dm_fsreg_t entry.

        struct super_block *sb,         /* filesystem being mounted */
        dm_right_t      vfsp_right,
        struct inode    *ip,            /* mounted on directory */
        dm_right_t      vp_right,
        struct inode    *rootip,
        dm_right_t      rootvp_right,
        char            *name1,         /* mount path */
        char            *name2)         /* filesystem device name */

        This interface would not change.  This would create the tokevent
        and various tokdata structures, find the dm_fsreg_t entry and
        add more pieces to it, and call to dm_enqueue_mount_event().

I don't know what kind of problems we'll have to address if the dm_fsreg_t
entry is not fully populated, if only for a moment.

On the other hand, I sometimes wonder if we could change dm_send_mount_event()
to throw away the 'ip' and 'vp_right' parameters--they're never used on Linux
today, anyway, and apparently this hasn't caused any problems for our HSM
people.  The spec allows the mounted-on directory info to be invalid.  Then we
could swap those parameters for the two new parameters we want to add and call
it square :)


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