Re: (struct dentry *)->vfsmnt;

[Andreas Dilger <adilger@turbolinux.com>]

You write:
> > For the same reason that the UUID and LABEL are stored in the superblock:
> > you want this infomation kept with the filesystem and not anywhere else,
> > otherwise it will quickly get out-of-date.  Wherever you mounted the
> > filesystem last is where it would be mounted if you import the VG on
> > another system.  You can obviously edit /etc/fstab afterwards if it is
> > wrong, and then remount the filesystem(s), and this will store the
> > correct mountpoint into the filesystem for the next vgimport.
> 
> Al is saying `why not do this in mount(8) instead of mount(2)?'  I haven't
> seen you answer that yet.

Because this is totally filesystem specific - why put extra knowledge
of filesystem internals into mount?  I personally don't want it writing
into the ext2 or ext3 superblock.  How can it possibly know what to do,
without embedding a lot of knowledge there?  Yes, mount(8) can _read_
the UUID and LABEL for ext2 filesystems, but I would rather not have it
_write_ into the superblock.  Also, InterMezzo and SnapFS have the same
on-disk format as ext2, but would mount(8) know that?

There are other filesystems (at least IBM JFS) that could also take
advantage of this feature, should we make mount(8) have code for each
and every filesystem?  Yuck.  Sort of ruins the whole modularity thing.
Yes, I know mount(8) does funny stuff for SMB and NFS, but that is a
reason to _not_ put more filesystem-specific information into mount(8).

Actually, one more reason to have this in the kernel is for InterMezzo
(distributed filesystem which uses ext3 for on-disk storage).  Currently,
the mount point is passed as a mount parameter (yuck) because it is
needed internally to the InterMezzo kernel code.  If the filesystem
could extract this information at mount time, it would remove the need
for the mount parameter.

The benefit of doing all of this in *_read_super() (probably would be in
ext2_setup_super() for ext2) is that filesystems which can use this feature
will do so, and others will not.  It is a matter of a single "d_path()"
call at mount (or remount for R/O mounted filesystems), so it is not like
it's going to slow down the system a lot.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert