Is it possible to get mount point from VFS read_super() method?
David Chow
> way, and I think a mount event should be created somewhere around ->read_super
> time, and that's about it, no matter how many places the device is mounted.
> Why? Because the HSM should not be using pathnames anyway, and the spec makes
> it easy to do all the work via handles so there's no reason to use pathnames.
> The HSM really just needs to know which device is being mounted; it shouldn't
> need to know where or even how many paths there are for it. That the spec
> implies otherwise is unfortunate.
I am working with FiST also I am doing research on stackable
filesystems. I am also implementing a stackable mounted filesystem with
an overlay mount. I need to no the mount point of the filesystem at
mount time, somewhere I can reach in read_super().
>
> Someone...Luka, I guess... did mention that they wanted a pathname so their
> HSM could migrate/recall files--look over the invisible I/O feature in the
> spec and use handles, and you'll find that the HSM doesn't need pathnames.
>
> Face it, dm_handle_to_path() is an unfortunate idea, even before the
> multi-mount stuff that Linux has thrown at us. Don't build an HSM on it.
>
> So, Al is wondering why I'm saying this after I just spent so much time going
> back and forth with him working on that mountpoint (no, he certainly didn't
> condone it, but he was willing to discuss the issues)... Well, at the
> moment, I just need something that follows the spec.
>
For --bind, I don't think it involves operations like read_super()
right? I think its up to the fs developer to use the mount point in
their operations or not. For namespace problems, if we use bind,
sym-links will change anyway because they are context based stuff. Also,
its up to the developers want to use that pathname for ongoing
operations, but I suggest not to store the pathname in the super block
structure. It should up to the developer to store it or not, using the
private data of superblock is the best choice. But at least somewhere at
mount time should give a hint to read_super where the fs is mounting
at!!
> I'm open to ideas. Maybe the library-side of dm_get_events() could munge
> through /proc/mounts and patch up mount events, I dunno.
>
> Dean
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
For example, I want an overlay mount to translating my files using a
stackable fs mount
mount -t myfs none /mnt/myfs
Why not? I think this is greate and clean. How can this be done without
knowing the mount point at mount time? Now FiST work around using an
extra option to pass the source directory into read_super which I think
it is not clean although it works, but I do think people like me want a
clean stacked overlay mount.
regards,
DC
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Christoph Hellwig
> For --bind, I don't think it involves operations like read_super()
> right?
Nope.
->read_super is called on _first_ mount of a device. Additional mounts
or VFS bdindings (mount --bind) don't call it.
>
> mount -t myfs none /mnt/myfs
>
> Why not? I think this is greate and clean. How can this be done without
> knowing the mount point at mount time?
How do you get locking vs. access through other mounts of the same fs
right?
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
Alexander Viro
On 17 Nov 2001, David Chow wrote:
> I am working with FiST also I am doing research on stackable
> filesystems. I am also implementing a stackable mounted filesystem with
> an overlay mount. I need to no the mount point of the filesystem at
> mount time, somewhere I can reach in read_super().
So pass it as an option.
> For --bind, I don't think it involves operations like read_super()
> right? I think its up to the fs developer to use the mount point in
> their operations or not. For namespace problems, if we use bind,
There is no such thing as "the" mount point.
> mount time should give a hint to read_super where the fs is mounting
> at!!
Quite possibly - nowhere.
> For example, I want an overlay mount to translating my files using a
> stackable fs mount
>
> mount -t myfs none /mnt/myfs
>
> Why not? I think this is greate and clean. How can this be done without
It isn't. First of all, if your code depends on underlying fs staying
hidden - it's broken. Said fs may be mounted in many other places.
What's more, unless you hold a reference to underlying vfsmount(s) - keep
in mind that your covering fs may be moved elsewhere and underlying one -
unmounted.
> knowing the mount point at mount time? Now FiST work around using an
> extra option to pass the source directory into read_super which I think
> it is not clean although it works, but I do think people like me want a
> clean stacked overlay mount.
Naive variant of stacking is incompatible with multiple mounts. Notice
the word naive - there are variants that _are_ compatible and combination
allows more that 4.4BSD-style stacking does.
For instance, ask yourself - how should covering interact with underlying
mountpoints? E.g. you cover /usr; do you want to cover /usr/local? What
should happen if local on /usr is non-empty and /usr/local had been mounted
atop of that? Would you want mounting a layer to expose old contents of
/usr/local?
There's a lot of corner cases where 4.4BSD model acts very ugly. Moreover,
in places where it relies on underlying fs staying hidden (as *BSD unionfs
does) it's simply broken - try to union-mount atop of NFS and see what
happens if somebody has the same thing exported to another box. Hint:
remotely triggerable kernel panic is generally considered a Bad Thing(tm).
As I've said, there are saner models. E.g. "layer lives over a tree
that may consist of many filesystems". In case of Linux that means
using copy_tree() and then dealing with resulting tree of vfsmounts.
It may be taken from _any_ place, not just one you mount over. And
it doesn't depend on original tree remaining hidden _or_ unchanged -
you get a private copy and it keeps relevant superblocks alive.
Again, _any_ variant relying on "OK, we mount atop of the place where
underlying fs lives, so nobody will touch it" is broken. It's not
just Linux - figuring out how to crash FreeBSD with that is left as
an exercise for readers. And as soon as your code _doesn't_ rely on
that, it turns into completely unmotivated restriction - there's a
lot of very sane uses of layering that mount the layer in a new place.
Trivial example: you have a read-only tree with clean source. Several
developers have unionfs over it mounted in different places, each with
its own covering layer. Each of them got a copy of his own (all changes
go into his tree, etc.) and we keep all benefits of unionfs.
Peter J. Braam
So how do we solve the problem of mount objects in a file system:
- a process is about to enter (lookup inside, readdir) a directory,
- FS finds mount information suspends process
- the FS calls an automount daemon
- the daemon mounts the new FS on top of the directory the process is
going into
Can this be done without the FS knowing the vfsmount?
If I understand things right, it cannot (even if the FS knows a
pathname where the parent is mounted), since the new vfsmount will not
show up in the right place unless the vfsmount of the directory the
calling process is known.
- Peter -
--
Alexander Viro
On Fri, 16 Nov 2001, Christoph Hellwig wrote:
> I think this kind of funtionality should be moved into VFS.
> The basic idea is to add a new mount subtype (let's name it MS_HOOK),
> similar to MS_BIND mounts it can be applied to any kind of filesystem
> object, not just diretcories.
Umm... Mount-traps are completely separate story and they don't look
like the thing Peter was talking about.
> The basic idea of this VFS-handled mount type is to allow callbacks
> into userspace using exec_usermodehelper when looking up. Once looked
> up it would be replaced by the real vfsmnt.
>
> The real difficulty is getting timing out and umount on unused right
> in the VFS.
That's easy (just keep a pipe to creating process), but again, what
does it have to layering?
Christoph Hellwig
On Fri, Nov 16, 2001 at 12:14:05PM -0700, Peter J. Braam wrote:
> Al,
>
> So how do we solve the problem of mount objects in a file system:
>
> - a process is about to enter (lookup inside, readdir) a directory,
> - FS finds mount information suspends process
> - the FS calls an automount daemon
> - the daemon mounts the new FS on top of the directory the process is
> going into
>
> Can this be done without the FS knowing the vfsmount?
I think this kind of funtionality should be moved into VFS.
The basic idea is to add a new mount subtype (let's name it MS_HOOK),
similar to MS_BIND mounts it can be applied to any kind of filesystem
object, not just diretcories.
The basic idea of this VFS-handled mount type is to allow callbacks
into userspace using exec_usermodehelper when looking up. Once looked
up it would be replaced by the real vfsmnt.
The real difficulty is getting timing out and umount on unused right
in the VFS.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
Christoph Hellwig
> > The real difficulty is getting timing out and umount on unused right
> > in the VFS.
>
Then it's done by the process, not the VFS.
It might be the better soloution, although it isn't that generic.
> but again, what
> does it have to layering?
nothing.
Alexander Viro
On Fri, 16 Nov 2001, Peter J. Braam wrote:
> Al,
>
> So how do we solve the problem of mount objects in a file system:
>
> - a process is about to enter (lookup inside, readdir) a directory,
> - FS finds mount information suspends process
> - the FS calls an automount daemon
> - the daemon mounts the new FS on top of the directory the process is
> going into
>
> Can this be done without the FS knowing the vfsmount?
Wrong model. FS has its own superblock. Additionally, it maintains a private
tree of vfsmounts (pointing to other filesystems), not attached to the global
tree.
So when you step on a directory (dentry/inode on your fs) you mount on
the vfsmount/dentry in underlying tree. IOW, no new visible vfsmounts
appear - you just extend dentry tree of your fs _and_ add a new chunk
to covered (private) tree.
See what I mean? You have a single tree (one that is served by your fs
code) over private composite tree. That way even no matter where your
fs is mounted, stepping on a magic object is visible in all instances -
simply because it looks like growth of dentry tree of your fs. No
coherence problems, no hunting for vfsmount of instance you've stepped
on.
Christoph Hellwig
> I want the mount objects stored IN the file system, not in config
> files (as the automounter currently has). The VFS cannot make the
> decision how the FS encodes its mount objects.
>
> Would you suggest then that the FS can mark an object as a mount
> object and then the VFS can invoke a mount related operation?
I basically thought that it should be done userspace (ala configfiles).
Why do you want to store it in the FS?
Basically Hurd's passive translators and I never understood why they
want those..
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
Peter J. Braam
> [fullquote nuked]
>
> On Fri, Nov 16, 2001 at 12:14:05PM -0700, Peter J. Braam wrote:
> > Al,
> >
> > So how do we solve the problem of mount objects in a file system:
> >
> > - a process is about to enter (lookup inside, readdir) a directory,
> > - FS finds mount information suspends process
> > - the FS calls an automount daemon
> > - the daemon mounts the new FS on top of the directory the process is
> > going into
> >
> > Can this be done without the FS knowing the vfsmount?
>
> The basic idea is to add a new mount subtype (let's name it MS_HOOK),
> similar to MS_BIND mounts it can be applied to any kind of filesystem
> object, not just diretcories.
I want the mount objects stored IN the file system, not in config
files (as the automounter currently has). The VFS cannot make the
decision how the FS encodes its mount objects.
Would you suggest then that the FS can mark an object as a mount
object and then the VFS can invoke a mount related operation?
Did you see the design I wrote down for this with Lee Ward
(http://www.lustre.org/docs/namespace.html).
>
> The real difficulty is getting timing out and umount on unused right
> in the VFS.
Yes.
>
> Christoph
>
> --
> Of course it doesn't work. We've performed a software upgrade.
--
Anton Altaparmakov
>On Fri, Nov 16, 2001 at 12:26:35PM -0700, Peter J. Braam wrote:
> > I want the mount objects stored IN the file system, not in config
> > files (as the automounter currently has). The VFS cannot make the
> > decision how the FS encodes its mount objects.
> >
> > Would you suggest then that the FS can mark an object as a mount
> > object and then the VFS can invoke a mount related operation?
>
>Why do you want to store it in the FS?
>Basically Hurd's passive translators and I never understood why they
>want those..
Well I don't know why he wants it but I know NTFS has it so if the kernel
had support for this kind of things, they would be easier to implement in NTFS.
In Windows these kind of objects (i.e. ones which cause the FS to invoke
external drivers to do things based on the type and contents of the object)
are used to implement mountpoints, symbolic links, hierarchical storage
management/off line storage, anything else driver writers might come up with...
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
Peter J. Braam
> At 19:55 16/11/01, Christoph Hellwig wrote:
> >On Fri, Nov 16, 2001 at 12:26:35PM -0700, Peter J. Braam wrote:
> > > I want the mount objects stored IN the file system, not in config
> > > files (as the automounter currently has). The VFS cannot make the
> > > decision how the FS encodes its mount objects.
> > >
> > > Would you suggest then that the FS can mark an object as a mount
> > > object and then the VFS can invoke a mount related operation?
> >
> >I basically thought that it should be done userspace (ala configfiles).
> >Why do you want to store it in the FS?
> >Basically Hurd's passive translators and I never understood why they
> >want those..
In that way you administer your namespace in one place, and users can
add fileset mount points themselves.
>
> Well I don't know why he wants it but I know NTFS has it so if the kernel
> had support for this kind of things, they would be easier to implement in NTFS.
>
> In Windows these kind of objects (i.e. ones which cause the FS to invoke
> external drivers to do things based on the type and contents of the object)
> are used to implement mountpoints, symbolic links, hierarchical storage
> management/off line storage, anything else driver writers might come up with...
AFS, Coda, DCE/DFS has it too and too some extent InterMezzo as well.
I have some gripes with the NTFS, AFS/Coda etc methods, since the
symbolic links they use lead to troubles with the link numbers and
mounting on symbolic links isn't that easy either. (see
http://lustre.org/docs/namespace.html)
Al Viro's plan to manage this a tree of vfsmounts under the superblock
is really cool though.
- Peter -