Mountpoint lookup

Mountpoint lookup

[Florin Malita]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

Is there a way of finding the mountpoint a fs is being mounted on at
read_super time?

I'm developing a userland filesystem interface (LUFS -
http://lufs.sourceforge.net) and the only way of getting the mountpoint
I found so far is to wait until I get a struct file* (in readdir for
example) and then go through its f_vfsmount, building the mountpoint
path. This is race prone.

I suspect there's some sort of Zen restriction floating around the
mountpoint (the darn fs shall not need to know its mountpoint) but I'm
relying on it for absolute symlinks remapping.

Thanks,
 
-- 
Florin Malita      web:        http://www.malinux.net
                   public key: http://www.malinux.net/data/fmalita.gpg

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Mountpoint lookup

[Christoph Hellwig]

On Wed, Feb 05, 2003 at 05:02:01PM +0200, Florin Malita wrote:
> Is there a way of finding the mountpoint a fs is being mounted on at
> read_super time?

No there is not, and there may in fact not even be a mount point.

Why do you think you need it?

Re: Mountpoint lookup

[Andrew Sharp]

On Wed, Feb 05, 2003 at 05:02:01PM +0200, Florin Malita wrote:
> Is there a way of finding the mountpoint a fs is being mounted on at
> read_super time?
> 
> I'm developing a userland filesystem interface (LUFS -
> http://lufs.sourceforge.net) and the only way of getting the mountpoint
> I found so far is to wait until I get a struct file* (in readdir for
> example) and then go through its f_vfsmount, building the mountpoint
> path. This is race prone.
> 
> I suspect there's some sort of Zen restriction floating around the
> mountpoint (the darn fs shall not need to know its mountpoint) but I'm
> relying on it for absolute symlinks remapping.

It's the bizarre code of the FS, happy to give you your 'device' but
not your mount path.  It is, however, almost always in the data pointer.
Look at the source for the mount command, or write your own mount
command if that regular one isn't giving you what you want.  I recently
dealt with this exact issue, but I am using my own mount command so it
was no biggy.

a

Re: Mountpoint lookup

[Christoph Hellwig]

On Wed, Feb 05, 2003 at 11:13:00AM -0800, Andrew Sharp wrote:
> It's the bizarre code of the FS, happy to give you your 'device' but
> not your mount path.  It is, however, almost always in the data pointer.
> Look at the source for the mount command, or write your own mount
> command if that regular one isn't giving you what you want.  I recently
> dealt with this exact issue, but I am using my own mount command so it
> was no biggy.

Unfortunately the second mount of the same device won't even call back into
your filesystem code.  Or mount --move or mount --bind.  Youre hack is
just broken, there is no non-ambiguous mount path -> superblock mapping
in linux.

Re: Mountpoint lookup

[Florin Malita]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

On Wed, 2003-02-05 at 17:45, Christoph Hellwig wrote:
> On Wed, Feb 05, 2003 at 05:39:03PM +0200, Florin Malita wrote:
> > On Wed, 2003-02-05 at 17:03, Christoph Hellwig wrote:
> > > No there is not, and there may in fact not even be a mount point.
> > > 
> > > Why do you think you need it?
> > 
> > For translating remote absolute symlinks to local ones. Lufs supports
> > several networked filesystems and I wanted to be able to map a remote
> > /path symlink to a local /mount_point/path.
> > 
> > So I guess the solution would be to translate to a local relative
> > symlink?
> 
> There is no way to do that translation, as there may be multiple mount points.
> I still don't see why you actually need to do that - anyone who uses absolute
> symlinks on exported filesystem deserves what he gets..

I agree to that. However, there are some lufs filesystem modules (sshfs,
ftpfs) which can give you access to the whole remote fs (which was never
meant to be exported this way). In this case, an absolute symlink
translation would come in handy.

Thanks for the clarification,

-- 
Florin Malita      web:        http://www.malinux.net
                   public key: http://www.malinux.net/data/fmalita.gpg

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Mountpoint lookup

[Bryan Henderson]

On Wed, Feb 05, 2003 at 11:13:00AM -0800, Andrew Sharp wrote:
>> It's the bizarre code of the FS, happy to give you your 'device' but
>> not your mount path.
>
>Your hack is
>just broken, there is no non-ambiguous mount path -> superblock mapping
>in linux.

I agree.  People, remember that (in Unix in general, not just Linux)
mounting a filesystem and creating a filesystem image are quite separate
concepts, even though they have traditionally been done and undone at the
same time.  Mounting is simply adding the files in a filesystem to the
system's name space.  Creating a file system image means setting up all the
data structures, methods, etc. to access the files in a filesystem.

A filesystem driver is responsible for providing access to files, and thus
for creating a filesystem image at read_super time, but it is none of the
filesystem driver's business what naming system the code above uses to
identify that filesystem image.  One way a filesystem image can exist
without being mounted is you create and
mount it, then open a file, then unmount it (I think the option you need on
the conventional Linux Mount program to do that is -l).  The system
destroys the filesystem image when you later close that file.  I don't
think there's a way today to open a file without ever mounting the
filesystem, but it's certainly a reasonable thing to do.

Re: Mountpoint lookup

[Bryan Henderson]

>However, there are some lufs filesystem modules (sshfs,
>ftpfs) which can give you access to the whole remote fs (which was never
>meant to be exported this way). In this case, an absolute symlink
>translation would come in handy.

To the extent that this translation would be handy, it would be appropriate
to pass the information as a filesystem-type-specific mount parameter
(which is actually a parameter of the filesystem image, not of the mount),
but the semantics of the parameter wouldn't be "this is the mount point,"
but rather "translate absolute symlinks with respect to this base path."
You could have a mount program that automatically sets this parameter to
the same path as the mount point, but of course you'd still have to have a
lot of disclaimers that imported absolute symlinks don't always work the
way the user expects.

--
Bryan Henderson                  IBM Almaden Research Center
San Jose CA                                      Filesystems

Re: Mountpoint lookup

[Florin Malita]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

On Wed, 2003-02-05 at 23:15, Bryan Henderson wrote:
> To the extent that this translation would be handy, it would be appropriate
> to pass the information as a filesystem-type-specific mount parameter
> (which is actually a parameter of the filesystem image, not of the mount),
> but the semantics of the parameter wouldn't be "this is the mount point,"
> but rather "translate absolute symlinks with respect to this base path."
> You could have a mount program that automatically sets this parameter to
> the same path as the mount point, but of course you'd still have to have a
> lot of disclaimers that imported absolute symlinks don't always work the
> way the user expects.

Sounds reasonable.

But how about translating all remote absolute symlinks to relative ones?
Seems to be quite easy and eliminates any need of mount point knowledge.

-- 
Florin Malita      web:        http://www.malinux.net
                   public key: http://www.malinux.net/data/fmalita.gpg

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Mountpoint lookup

[David Chow]

Florin Malita wrote:

>On Wed, 2003-02-05 at 23:15, Bryan Henderson wrote:
>  
>
>>To the extent that this translation would be handy, it would be appropriate
>>to pass the information as a filesystem-type-specific mount parameter
>>(which is actually a parameter of the filesystem image, not of the mount),
>>but the semantics of the parameter wouldn't be "this is the mount point,"
>>but rather "translate absolute symlinks with respect to this base path."
>>You could have a mount program that automatically sets this parameter to
>>the same path as the mount point, but of course you'd still have to have a
>>lot of disclaimers that imported absolute symlinks don't always work the
>>way the user expects.
>>    
>>
>
>Sounds reasonable.
>
>But how about translating all remote absolute symlinks to relative ones?
>Seems to be quite easy and eliminates any need of mount point knowledge.
>
>  
>
Actually, this question is some question I've asked before. Al response 
to me with the same answer. However, I do find it important in 
communicating with user land fs implementation or stackable fs 
implementation. However, the file system path (user space view) doesn't 
even exists after read_super() returns. I suggests the fs driver to 
implement a /proc interface for communication to user space. Because the 
user space path not always tells you or able to correctly locate the 
root dentry of your file system. Think of --bind or othermounts ontop of 
your previous mounts. User space must check fs type or as I said some 
/proc or ioctls. Symlinks is even more complicate as it can be cross 
devices, this is something impossible to handle with a couple of --bind 
on one another. You have to make your choice of assumptions.

regards,
David Chow