How to determine a path is a mountpoint.

How to determine a path is a mountpoint.

[Stef Bon]

Hello,

I'm working on a construction of the automounter in combination with a fuse 
module.
The automounter is the mounthelper.
I'm looking for a way to determine in C a directory is a mountpoint, specially
a autofs managed directory, so a virtual directory created by the automounter.

I can parse the /etc/mtab file or /proc/mounts, like in bash:

cat /proc/mounts | grep --word-regexp "$mountpoint"

but this is slow.. I have looked to the code of the program mountpoint,
but this is not possible in an autofs maneged directory. This program
does a cd to the directory and checks the filesystem changes. With autofs this 
makes the mountpoint always mounted, which is of course not what I'm looking 
for.

Stef

Re: How to determine a path is a mountpoint.

[Ian Kent]

On 02/16/2010 05:53 AM, Stef Bon wrote:
> Hello,
> 
> I'm working on a construction of the automounter in combination with a fuse 
> module.
> The automounter is the mounthelper.
> I'm looking for a way to determine in C a directory is a mountpoint, specially
> a autofs managed directory, so a virtual directory created by the automounter.
> 
> I can parse the /etc/mtab file or /proc/mounts, like in bash:
> 
> cat /proc/mounts | grep --word-regexp "$mountpoint"
> 
> but this is slow.. I have looked to the code of the program mountpoint,
> but this is not possible in an autofs maneged directory. This program
> does a cd to the directory and checks the filesystem changes. With autofs this 
> makes the mountpoint always mounted, which is of course not what I'm looking 
> for.

Yes, checking /proc/mounts is slow but is the only way when using older
versions of the kernel module.

In a recent source tree, have a look at lib/mounts.c:is_mounted() and
lib/dev-ioctl-lib.c, and in particular dev_ioctl_ismountpoint().

Ian

Re: How to determine a path is a mountpoint.

[Stef Bon]

On Tuesday 16 February 2010 04:04:17 Ian Kent wrote:
> On 02/16/2010 05:53 AM, Stef Bon wrote:
> > Hello,
> > 

> 
> Yes, checking /proc/mounts is slow but is the only way when using older
> versions of the kernel module.
> 
> In a recent source tree, have a look at lib/mounts.c:is_mounted() and
> lib/dev-ioctl-lib.c, and in particular dev_ioctl_ismountpoint().
> 
> Ian

Thanks for you fast answer.

I've checked the code and found the functions you're pointed, they are indeed 
what I'm looking for.

The function is_mounted looks like an internal function. It makes use of a 
struct ioctl_ops, which is initialised with get_ioctl_ops.  I do not 
understand this, cause this function does not use any parameter (like path!) 
so how does this function determine it's a mountpoint?

Or is it initialised somewhere else?? 
(in that case it looks like an constrcution with fuse handling 
filedescriptors.. when openening a file for writing, it looks for a fd already 
set in the runtimeoptions fuse_file_info->fh, and opens that in stead of 
looking at the path, which happens to be a parameter also) 


The other function you mention is dev_ioctl_ismounpoint, which looks more 
suitable to use in an external program like a fusemodule. The ioctl device, is 
that the device /var/run/autofs.fifo-mnt-mount.md5key-sbon-mount?

(if the map looks like:
/mnt/mount.md5key/sbon/mount  /etc/autofs/auto.md5key MD5KEY_USER=sbon
)

Stef

Re: How to determine a path is a mountpoint.

[Ian Kent]

On 02/16/2010 09:20 PM, Stef Bon wrote:
> On Tuesday 16 February 2010 04:04:17 Ian Kent wrote:
>> On 02/16/2010 05:53 AM, Stef Bon wrote:
>>> Hello,
>>>
> 
>>
>> Yes, checking /proc/mounts is slow but is the only way when using older
>> versions of the kernel module.
>>
>> In a recent source tree, have a look at lib/mounts.c:is_mounted() and
>> lib/dev-ioctl-lib.c, and in particular dev_ioctl_ismountpoint().
>>
>> Ian
> 
> Thanks for you fast answer.
> 
> I've checked the code and found the functions you're pointed, they are indeed 
> what I'm looking for.
> 
> The function is_mounted looks like an internal function. It makes use of a 
> struct ioctl_ops, which is initialised with get_ioctl_ops.  I do not 
> understand this, cause this function does not use any parameter (like path!) 
> so how does this function determine it's a mountpoint?

Read lib/dev-ioctl-lib.c, that's why I mentioned it, it's not that long.

It implements a set of functions for autofs control operations.

Many of them can't be called by just any process but the
dev_ioctl_ismountpoint() function can. It may not look that simple but
if you take some time to understand what it is doing you can take the
bits you need and that will end up being fairly simple.

The one problem you do have is that if the kernel doesn't have the new
device ioctl interface you will need to scan /proc/mounts, the same as
is done by the is_mounted() function if it sees the new functionality
isn't available.

Ian

Re: How to determine a path is a mountpoint.

[Stef Bon]

On Tuesday 16 February 2010 18:29:00 Ian Kent wrote:
> On 02/16/2010 09:20 PM, Stef Bon wrote:
> > On Tuesday 16 February 2010 04:04:17 Ian Kent wrote:
> >> On 02/16/2010 05:53 AM, Stef Bon wrote:
> >>> Hello,
> >> 
> >> Yes, checking /proc/mounts is slow but is the only way when using older
> >> versions of the kernel module.
> >> 
> >> In a recent source tree, have a look at lib/mounts.c:is_mounted() and
> >> lib/dev-ioctl-lib.c, and in particular dev_ioctl_ismountpoint().
> >> 
> >> Ian
> > 
> > Thanks for you fast answer.
> > 
> > I've checked the code and found the functions you're pointed, they are
> > indeed what I'm looking for.
> > 
> > The function is_mounted looks like an internal function. It makes use of
> > a struct ioctl_ops, which is initialised with get_ioctl_ops.  I do not
> > understand this, cause this function does not use any parameter (like
> > path!) so how does this function determine it's a mountpoint?
> 
> Read lib/dev-ioctl-lib.c, that's why I mentioned it, it's not that long.
> 
> It implements a set of functions for autofs control operations.
> 
> Many of them can't be called by just any process but the
> dev_ioctl_ismountpoint() function can. It may not look that simple but
> if you take some time to understand what it is doing you can take the
> bits you need and that will end up being fairly simple.
> 
> The one problem you do have is that if the kernel doesn't have the new
> device ioctl interface you will need to scan /proc/mounts, the same as
> is done by the is_mounted() function if it sees the new functionality
> isn't available.

Ok, but some helpe here is welcome. I've learned C just some months ago, and 
programming devices is new to me.

Look at dev_ioctl_ismountpoint.

The parameters it's using are logopt, ioctlfd, path and mountpoint.

logopt has something to do with logging, and is important, but not the topic.
ioctlfd is the filedescriptor for the fifo(?) in /var/run:

/var/run/autofs.fifo-mnt-mount.md5key-sbon-mount

in /proc/1705/fd :

9 -> /var/run/autofs.fifo-mnt-mount.md5key-sbon-mount

and 15 -> /var/run/autofs.fifo-mnt-mount.md5key-root-mount

futher path is of course the path to be examined. Is it absolute or relative

and mountpoint is the value which is combination of DEV_IOCTL_IS_MOUNTED, 
DEV_IOCTL_IS_AUTOFS and DEV_IOCTL_IS_OTHER. 

Is my analysis good???


To be sure, the value's I'm looking for are autofs managed mountpoints 
(DEV_IOCTL_IS_AUTOFS is 1) and the path is a mountpoint, which means
a resource is actually mounted here. (DEV_IOCTL_IS_OTHER).

I'm using a setup where the autofs managed directories are one level deep, 
nothing more.
But does this function really return a path is a mountpoint. In my module,
it's already clear that it is an autofs managed dir. In my module autofs 
managed dirs are of the form /mnt/mount.md5key/%USERID%/mount/%md5key%
where %md5key% is the md5sum of the resource record.
My fuse module checks the dirname of the path is equal to 
/mnt/mount.md5key/%USERID%, and the basename is 32 long, and exists. 
Resource records, containing all the information about a resource (local like 
USB and remote like SMB and FTP) necessary to mount it.

Now I want to add a test in my fusemodule fuse-workspace-union about this 
autofsmanaged directory is a an active mountpoint, or not active (expired/not 
activated...). 
It's not that important, but I want extra cosmetics. When mounted, I want the 
module to show another icon than when not mounted.

Stef



> 
> Ian

Re: How to determine a path is a mountpoint.

[Ian Kent]

On 02/17/2010 08:43 PM, Stef Bon wrote:
> On Tuesday 16 February 2010 18:29:00 Ian Kent wrote:
>> On 02/16/2010 09:20 PM, Stef Bon wrote:
>>> On Tuesday 16 February 2010 04:04:17 Ian Kent wrote:
>>>> On 02/16/2010 05:53 AM, Stef Bon wrote:
>>>>> Hello,
>>>>
>>>> Yes, checking /proc/mounts is slow but is the only way when using older
>>>> versions of the kernel module.
>>>>
>>>> In a recent source tree, have a look at lib/mounts.c:is_mounted() and
>>>> lib/dev-ioctl-lib.c, and in particular dev_ioctl_ismountpoint().
>>>>
>>>> Ian
>>>
>>> Thanks for you fast answer.
>>>
>>> I've checked the code and found the functions you're pointed, they are
>>> indeed what I'm looking for.
>>>
>>> The function is_mounted looks like an internal function. It makes use of
>>> a struct ioctl_ops, which is initialised with get_ioctl_ops.  I do not
>>> understand this, cause this function does not use any parameter (like
>>> path!) so how does this function determine it's a mountpoint?
>>
>> Read lib/dev-ioctl-lib.c, that's why I mentioned it, it's not that long.
>>
>> It implements a set of functions for autofs control operations.
>>
>> Many of them can't be called by just any process but the
>> dev_ioctl_ismountpoint() function can. It may not look that simple but
>> if you take some time to understand what it is doing you can take the
>> bits you need and that will end up being fairly simple.
>>
>> The one problem you do have is that if the kernel doesn't have the new
>> device ioctl interface you will need to scan /proc/mounts, the same as
>> is done by the is_mounted() function if it sees the new functionality
>> isn't available.
> 
> Ok, but some helpe here is welcome. I've learned C just some months ago, and 
> programming devices is new to me.
> 
> Look at dev_ioctl_ismountpoint.
> 
> The parameters it's using are logopt, ioctlfd, path and mountpoint.
> 
> logopt has something to do with logging, and is important, but not the topic.
> ioctlfd is the filedescriptor for the fifo(?) in /var/run:

You probably wouldn't need logopt, it's for autofs per-mount log level
so it's automount daemon specific. Read the comment above the function,
you don't have a file descriptor so you can give it a (full) path and
set the file descriptor to -1.

> 
> /var/run/autofs.fifo-mnt-mount.md5key-sbon-mount

Forget about those named pipes they are nothing to do with this.
You need to read this whole file to understand what is going on and
adapt the bits you need for your own use.

If you have a recent kernel then you can use the miscellaneous device
/dev/autofs for ioctl control functions such as is done in
dev_ioctl_ismountpoint(). To find out if the kernel supports it you need
to use a construct similar to that seen in init_ioctl_ctl(). If the
device file is available init_ioctl_ctl() opens the device file, stores
the descriptor in the struct ioctl_ctl, and uses the file descriptor
from that structure for autofs ioctl operations, as is seen in
dev_ioctl_ismountpoint().

You need to see the bugger picture of what is going on in
dev-ioctl-lib.c to be able to make use of it.

> 
> in /proc/1705/fd :
> 
> 9 -> /var/run/autofs.fifo-mnt-mount.md5key-sbon-mount
> 
> and 15 -> /var/run/autofs.fifo-mnt-mount.md5key-root-mount
> 
> futher path is of course the path to be examined. Is it absolute or relative
> 
> and mountpoint is the value which is combination of DEV_IOCTL_IS_MOUNTED, 
> DEV_IOCTL_IS_AUTOFS and DEV_IOCTL_IS_OTHER. 
> 
> Is my analysis good???
> 
> 
> To be sure, the value's I'm looking for are autofs managed mountpoints 
> (DEV_IOCTL_IS_AUTOFS is 1) and the path is a mountpoint, which means
> a resource is actually mounted here. (DEV_IOCTL_IS_OTHER).

If nothing is mounted on the directory it should set
DEV_IOCTL_IS_AUTOFS, if there is an "other" mount it should set the
DEV_IOCTL_IS_OTHER bit. I need to look again at the implementation in
dev-ioctl-lib.c and the kernel module to be sure of what it will return.

> 
> I'm using a setup where the autofs managed directories are one level deep, 
> nothing more.
> But does this function really return a path is a mountpoint. In my module,
> it's already clear that it is an autofs managed dir. In my module autofs 
> managed dirs are of the form /mnt/mount.md5key/%USERID%/mount/%md5key%
> where %md5key% is the md5sum of the resource record.
> My fuse module checks the dirname of the path is equal to 
> /mnt/mount.md5key/%USERID%, and the basename is 32 long, and exists. 
> Resource records, containing all the information about a resource (local like 
> USB and remote like SMB and FTP) necessary to mount it.

I'm don't really understand what you are trying to do and I shouldn't
need to, I just need to know what you want to know about a given path so
try not to cloud the description with implementation detail. I thought
your issue was that if you use a system call like statfs(2) to get file
system information it will cause a mount to occur which you don't want.

> 
> Now I want to add a test in my fusemodule fuse-workspace-union about this 
> autofsmanaged directory is a an active mountpoint, or not active (expired/not 
> activated...). 
> It's not that important, but I want extra cosmetics. When mounted, I want the 
> module to show another icon than when not mounted.

And I will check the implementation and get back with specific
behaviours, if this is what you need.

Don't forget that if the kernel doesn't support the mount check ioctl
you will need to use something like what is done in
lib/mounts.c:is_mounted() and call something like
lib/mounts.c:table_is_mounted() to scan /proc/mounts. It does this when
it sees the kernel doesn't support the new function. That is when it
sees that the struct ioctl_ops ismountpoint field is null (because there
is no ioctl entry point for it).

Ian

Re: How to determine a path is a mountpoint.

[Stef Bon]

On Wednesday 17 February 2010 15:25:08 Ian Kent wrote:

> 
> And I will check the implementation and get back with specific
> behaviours, if this is what you need.
> 
> Don't forget that if the kernel doesn't support the mount check ioctl
> you will need to use something like what is done in
> lib/mounts.c:is_mounted() and call something like
> lib/mounts.c:table_is_mounted() to scan /proc/mounts. It does this when
> it sees the kernel doesn't support the new function. That is when it
> sees that the struct ioctl_ops ismountpoint field is null (because there
> is no ioctl entry point for it).
> 
> Ian

OK,

I know that I need something else when the kernel does not support the ioctl check. 

Maybe I should have been more clear in what I want.
I'm afraid I have totell you something about my setup, although you don't need to understand it. Please do not forget just learned C and not "home" in the 
autofs code and construction.

I'm using a very simple map file:

*            -fstype=md5key :/&

that's it!
It passes every key to the mountcommand of the nonexistant md5key  filesystem:
/sbin/mount.md5key

which is a wrapper for other (real) mount commands. The automounter just let this happen what is a pretty nice thing!

Now the mountpoint where this map is assigned to depends to the user, the line
in the auto.master looks like:

/mnt/mount.md5key/sbon/mount       /etc/autofs/auto.md5key    MD5KEY_USER=sbon

Now this directory is not to be accessed directly by the user, but through a fusemodule I'm working on. In short, it points to directories (keys) in the
/mnt/mount.md5key/sbon/mount directory, which are one level deep. Every key is actually the md5sum of a record (I call them resource records) about a 
resource, local(USB) or remote (CIFS, FTP, SSH). 

Now in the autofs managed directory 

/mnt/mount.md5key/sbon/mount 

only those directories exist of resources actually mounted! If I access a SMB share in my connection tree, my call is redirected to the proper md5key 
directory in /mnt/mount.md5key/sbon/mount, making the automounter mount the share:

mount | grep /mnt/mount.md5key/sbon

//SCLFS20091030/video on /mnt/mount.md5key/sbon/mount/e23e33a53d5d08ad8f0425de4edd9309 type cifs (rw,mand)


and when I do /bin/ls -l /mnt/mount.md5key/sbon/mount:
total 0
drwxr-xr-x 10 root root    0 2010-02-09 12:11 e23e33a53d5d08ad8f0425de4edd9309

when I enter other shares these appear as well. When unmounted, the directories disapear. Logic, you might say, but this is crucial.

My fusemodule is an overlay fs, which mirrors another directory under the directory under which it's mounted, and does some changes.

Now how does my module know which share is mounted when building an directory overview with readdir and applications like Dolphin
are searching for a .directory file. The call for this .directory file in the target is intercepted by my fuse module, cause otherwise
this call will also make the automounter mount the share, while only the .directory is looked up.

Now like I've said before, I cannot do a stat of the target key directory, cause this will make the automounter to mount the share.
It's possible to make my fuse module to read the contents of /mnt/mount.md5key/sbon/mount, and check the key to be investigated
is in this directory. I haven't tested this, but it should work.

Right now I looking for a way the automounter can give the answer.
It looks like the dev_ioctl_ismountpoint return -1 for the case the share is not mounted, and *mountpoint is equal to 0.
When mounted, another filesystem is mounted, so *mountpoint is DEV_IOCTL_ISMOUNTED | DEV_IOCTL_IS_OTHER.

So probably I have to create a exampleprogram doing this, with the path as a parameter.

Stef Bon

Re: How to determine a path is a mountpoint.

[Ian Kent]

On 02/19/2010 07:18 AM, Stef Bon wrote:
> On Wednesday 17 February 2010 15:25:08 Ian Kent wrote:
> 
>> 
>> And I will check the implementation and get back with specific 
>> behaviours, if this is what you need.
>> 
>> Don't forget that if the kernel doesn't support the mount check
>> ioctl you will need to use something like what is done in 
>> lib/mounts.c:is_mounted() and call something like 
>> lib/mounts.c:table_is_mounted() to scan /proc/mounts. It does this
>> when it sees the kernel doesn't support the new function. That is
>> when it sees that the struct ioctl_ops ismountpoint field is null
>> (because there is no ioctl entry point for it).
>> 
>> Ian
> 
> OK,
> 
> I know that I need something else when the kernel does not support
> the ioctl check.
> 
> Maybe I should have been more clear in what I want. I'm afraid I have
> totell you something about my setup, although you don't need to
> understand it. Please do not forget just learned C and not "home" in
> the autofs code and construction.

Well, I tried to keep the discussion simple!
We will just have to work through it then.

> 
> I'm using a very simple map file:
> 
> *            -fstype=md5key :/&
> 
> that's it! It passes every key to the mountcommand of the nonexistant
> md5key  filesystem: /sbin/mount.md5key
> 
> which is a wrapper for other (real) mount commands. The automounter
> just let this happen what is a pretty nice thing!
> 
> Now the mountpoint where this map is assigned to depends to the user,
> the line in the auto.master looks like:
> 
> /mnt/mount.md5key/sbon/mount       /etc/autofs/auto.md5key
> MD5KEY_USER=sbon
> 
> Now this directory is not to be accessed directly by the user, but
> through a fusemodule I'm working on. In short, it points to
> directories (keys) in the /mnt/mount.md5key/sbon/mount directory,
> which are one level deep. Every key is actually the md5sum of a
> record (I call them resource records) about a resource, local(USB) or
> remote (CIFS, FTP, SSH).
> 
> Now in the autofs managed directory
> 
> /mnt/mount.md5key/sbon/mount
> 
> only those directories exist of resources actually mounted! If I
> access a SMB share in my connection tree, my call is redirected to
> the proper md5key directory in /mnt/mount.md5key/sbon/mount, making
> the automounter mount the share:
> 
> mount | grep /mnt/mount.md5key/sbon
> 
> //SCLFS20091030/video on
> /mnt/mount.md5key/sbon/mount/e23e33a53d5d08ad8f0425de4edd9309 type
> cifs (rw,mand)
> 
> 
> and when I do /bin/ls -l /mnt/mount.md5key/sbon/mount: total 0 
> drwxr-xr-x 10 root root    0 2010-02-09 12:11
> e23e33a53d5d08ad8f0425de4edd9309
> 
> when I enter other shares these appear as well. When unmounted, the
> directories disapear. Logic, you might say, but this is crucial.
> 
> My fusemodule is an overlay fs, which mirrors another directory under
> the directory under which it's mounted, and does some changes.

aka unionfs type behaviour?

You are in for a bundle of trouble if your trying to implement an
overlay file system. If there are enough restrictions on functionality
you might be able to get this working reliably but the locking alone
will likely drive you nuts! You understand that once you play in kernel
space you can have multiple concurrent code paths accessing and possibly
changing the same data structures at the same time.

> 
> Now how does my module know which share is mounted when building an
> directory overview with readdir and applications like Dolphin are
> searching for a .directory file. The call for this .directory file in
> the target is intercepted by my fuse module, cause otherwise this
> call will also make the automounter mount the share, while only the
> .directory is looked up.
> 
> Now like I've said before, I cannot do a stat of the target key
> directory, cause this will make the automounter to mount the share. 
> It's possible to make my fuse module to read the contents of
> /mnt/mount.md5key/sbon/mount, and check the key to be investigated is
> in this directory. I haven't tested this, but it should work.

It sounds like you have essentially got a kernel module here.

In that case you should not need to use an ioctl because you already
have access to the same information that the mounted check ioctl has. If
you are within a callback from kernel space deadlock is very likely
going to happen if you start calling back to the kernel again via an ioctl.

Is this a kernel module you are working with or callbacks from the
kernel? If it is then you really should be doing this a completely
different way, like using d_lookup() to locate the dentry in the
directory and then doing the checks. But I don't know exactly what
environment you are working within yet so I can't quite help.

> 
> Right now I looking for a way the automounter can give the answer. It
> looks like the dev_ioctl_ismountpoint return -1 for the case the
> share is not mounted, and *mountpoint is equal to 0. When mounted,
> another filesystem is mounted, so *mountpoint is DEV_IOCTL_ISMOUNTED
> | DEV_IOCTL_IS_OTHER.

The -1 is an error so maybe we can get more info from errno but lets
continue this discussion after we work out what environment we are in
from the question above.

Ian

Re: How to determine a path is a mountpoint.

[Stef Bon]

On Friday 19 February 2010 04:57:15 Ian Kent wrote:
> On 02/19/2010 07:18 AM, Stef Bon wrote:
> > On Wednesday 17 February 2010 15:25:08 Ian Kent wrote:
> > My fusemodule is an overlay fs, which mirrors another directory under
> > the directory under which it's mounted, and does some changes.
> 
> aka unionfs type behaviour?
> 
> You are in for a bundle of trouble if your trying to implement an
> overlay file system. If there are enough restrictions on functionality
> you might be able to get this working reliably but the locking alone
> will likely drive you nuts! You understand that once you play in kernel
> space you can have multiple concurrent code paths accessing and possibly
> changing the same data structures at the same time.

Well it's difficult, well not for me, but for the deveopers of FUSE. It's not in kernel space, but in userspace. Never heard of?

With Fuse one is able to write your own fs, by just writing what all the basic function do, like getattr, readdir, open, write and close. These are just a 
selection, look at the website for more info.

http://fuse.sourceforge.net/

Im not running into trouble, it's just an filesystem which happens to be an overlay fs.

My overlay is just like the mount --bind (or mount --rbind) command. It just mirrors the contents of one directory into another.But it does more. It 
reckognizes symbolic links which point to an autofs managed resource. Let me explain:

A tree to SMB resources look like
$HOME/Network/Windows Network/BONONLINE/ADMIN/admin	  -> /mnt/mount.md5key/sbon/mount/50b89942f697f095ac66359eae1b3a8f
                                            	  /documentation  -> /mnt/mount.md5key/sbon/mount/68141c6ce3077c8e438f7b31c3002053
                                                  /public	  -> /mnt/mount.md5key/sbon/mount/795e5d59a7901e91296cf6aae0987c94
                                                  /sbon	          -> /mnt/mount.md5key/sbon/mount/8236f6c5eae783204a24f447c4ea8ec3

where the keys (50b8999... and the others) are names of records in /var/cache/mount.md5key. Here the directories with these names exist, and contain 
information about the resource. This record is looked up by mount.md5key, and the real mountcommand is started, with the right parameters.

Now this is not ideal, cause were dealing with symbolic links, pointing to the targets. Most applications "forget" where they are coming from, which result in 
the user browsing in /mnt/mount.md5key/.... which should not happen. Futher, when accessing the directory of the server, and listing the contents,
everey share is mounted, cause almost all applications want to know what the target is what the links ar pointing at. And last but not least, a lot of 
applications in KDE (I do not know abou Gnome) search for a .directory file in the directory, making every target mounted.

To prevent this behaviour, I've started fuse-workspace-union, which mirrors the connectionstree (with allkinds of links to different resources) to the directory 
under which it's mounted, and does some things. First it will translate symbolic links, pointing to a directory in /mnt/mount.md5key/sbon/, into a directory.
This will make it look like the shares are directl mounted in the connectionsmap, while in fact it's just a trick.

mkdir -p /var/lib/workspace/sbon/{bind,conf}

mv $HOME/Network /var/lib/workspace/sbon/bind

mkdir $HOME/Workspace

start fuse-workspace-union with the right parameters:

/usr/bin/fuse-workspace-union $HOME/Workspace \
			      --bind-directory=/var/lib/workspace/sbon/bind \
                              --conf-directory=/var/lib/workspace/sbon/conf \
                              --autofs-mount-directory=/mnt/mount.md5key/sbon/mount \
                              --autofs-cache-directory=/var/cache/mount.md5key \
                              -o allow_root,default_permissions,use_ino 




Now when I do:
cd $HOME/Workspace/Network/Windows Network/BONONLINE/ADMIN
ls -l
drwxr-xr-x 2 sbon netgroup 61 2009-12-31 21:17 admin
drwxr-xr-x 2 sbon netgroup 61 2009-12-31 21:17 documentation
drwxr-xr-x 2 sbon netgroup 61 2009-12-31 21:17 public
drwxr-xr-x 2 sbon netgroup 61 2009-12-31 21:17 sbon


Futher it will intercept call's for a .directory file, which will make the resource to be mounted by the automounter, and present a standard .directory file 
instead.

FUSE does a lot of administration for me. It will generate inodes,   handle locks, is multitheaded. Extended attributes are supported, locking does work.
Only inotify is not implemented yet in my fs. 

I hope things get more clear now, after this long story.

In a previous mail I've said that the key directories in the autofs managed directory disappear when the resource is unmounted. I am wrong!
I've checked it again, and now the directories stay there, while the resource is not mounted. Huh?? How come??

My directory looks like:

root [ /usr/src/cblfs-200910/autofs-5.0.5 ]# /bin/ls -l /mnt/mount.md5key/sbon/mount/
total 0
dr-xr-xr-x 2 root root 0 2010-02-19 13:42 60ef51078836b9a9c78a3398f053d562
dr-xr-xr-x 2 root root 0 2010-02-19 13:42 7bfb90bb66496650c21925bd56a71bdc
dr-xr-xr-x 2 root root 0 2010-02-19 13:42 e23e33a53d5d08ad8f0425de4edd9309


while nothing is mounted:

root [ /usr/src/cblfs-200910/autofs-5.0.5 ]# mount | grep /mnt/mount.md5key/
root [ /usr/src/cblfs-200910/autofs-5.0.5 ]#


Is this behaviour normal? Is there a configuration switch?? Obvioulsy the automounter allows autofs directories to exists, while the are not connected.



Stef Bon



> 
> > Now how does my module know which share is mounted when building an
> > directory overview with readdir and applications like Dolphin are
> > searching for a .directory file. The call for this .directory file in
> > the target is intercepted by my fuse module, cause otherwise this
> > call will also make the automounter mount the share, while only the
> > .directory is looked up.
> > 
> > Now like I've said before, I cannot do a stat of the target key
> > directory, cause this will make the automounter to mount the share.
> > It's possible to make my fuse module to read the contents of
> > /mnt/mount.md5key/sbon/mount, and check the key to be investigated is
> > in this directory. I haven't tested this, but it should work.
> 
> It sounds like you have essentially got a kernel module here.
> 
> In that case you should not need to use an ioctl because you already
> have access to the same information that the mounted check ioctl has. If
> you are within a callback from kernel space deadlock is very likely
> going to happen if you start calling back to the kernel again via an ioctl.
> 
> Is this a kernel module you are working with or callbacks from the
> kernel? If it is then you really should be doing this a completely
> different way, like using d_lookup() to locate the dentry in the
> directory and then doing the checks. But I don't know exactly what
> environment you are working within yet so I can't quite help.
> 
> > Right now I looking for a way the automounter can give the answer. It
> > looks like the dev_ioctl_ismountpoint return -1 for the case the
> > share is not mounted, and *mountpoint is equal to 0. When mounted,
> > another filesystem is mounted, so *mountpoint is DEV_IOCTL_ISMOUNTED
> > 
> > | DEV_IOCTL_IS_OTHER.
> 
> The -1 is an error so maybe we can get more info from errno but lets
> continue this discussion after we work out what environment we are in
> from the question above.
> 
> Ian

Re: How to determine a path is a mountpoint.

[Ian Kent]

On 02/21/2010 09:28 PM, Stef Bon wrote:
> On Friday 19 February 2010 15:11:49 Stef Bon wrote:
>> On Friday 19 February 2010 04:57:15 Ian Kent wrote:
>>> On 02/19/2010 07:18 AM, Stef Bon wrote:
>>>> On Wednesday 17 February 2010 15:25:08 Ian Kent wrote:
>>>> My fusemodule is an overlay fs, which mirrors another directory under
>>>> the directory under which it's mounted, and does some changes.
>>>
>>> aka unionfs type behaviour?
>>>
>>> You are in for a bundle of trouble if your trying to implement an
>>> overlay file system. If there are enough restrictions on functionality
>>> you might be able to get this working reliably but the locking alone
>>> will likely drive you nuts! You understand that once you play in kernel
>>> space you can have multiple concurrent code paths accessing and possibly
>>> changing the same data structures at the same time.
>>
>> Well it's difficult, well not for me, but for the deveopers of FUSE. It's
>> not in kernel space, but in userspace. Never heard of?
>>
>>
>> My directory looks like:
>>
>> root [ /usr/src/cblfs-200910/autofs-5.0.5 ]# /bin/ls -l
>> /mnt/mount.md5key/sbon/mount/ total 0
>> dr-xr-xr-x 2 root root 0 2010-02-19 13:42 60ef51078836b9a9c78a3398f053d562
>> dr-xr-xr-x 2 root root 0 2010-02-19 13:42 7bfb90bb66496650c21925bd56a71bdc
>> dr-xr-xr-x 2 root root 0 2010-02-19 13:42 e23e33a53d5d08ad8f0425de4edd9309
>>
>>
>> while nothing is mounted:
>>
>> root [ /usr/src/cblfs-200910/autofs-5.0.5 ]# mount | grep
>> /mnt/mount.md5key/ root [ /usr/src/cblfs-200910/autofs-5.0.5 ]#
>>
>>
>> Is this behaviour normal? Is there a configuration switch?? Obvioulsy the
>> automounter allows autofs directories to exists, while the are not
>> connected.
>>
> 
> Well I've found the sollution to path's not disappearing. Somehow when in my script the environment variables are set like follows:
> 
> USE_MISC_DEVICE="no"
> BROWSE_MODE="no"
> APPEND_OPTIONS="yes"
> LOGGING="debug"
> 
> /usr/sbin/automount --pidfile /var/run/autofs.var-run-autofs-auto.master.pid  /var/run/autofs/auto.master
> 
> the automounter is not taking these values, what suprised me a lot! This is the way the automounter reads various settings, via the environment. Values in 
> /etc/sysconfig/autofs (or /etc/sysconfig/autofs.conf depends on your distro...) are read and set this way!
> Now when I do something like:
> 
> USE_MISC_DEVICE="no"
> export BROWSE_MODE="no"
> APPEND_OPTIONS="yes"
> export LOGGING="debug"
> 
> /usr/sbin/automount --pidfile /var/run/autofs.var-run-autofs-auto.master.pid  /var/run/autofs/auto.master
> 
> I can see that I get the desired behaviour: unmounted entries (keys) are deleted!
> I've checked the "file" environ in the /proc/3689 directory, and only found the values LOGGING and BROWSE_MODE, not USE_MISC_DEVICE and 
> APPEND_OPTIONS. But there is logging and browse_mode is not used!
> 
> So, am I missing here something? Or has something changed?
> When I look to the various init rc scripts, the file /etc/sysconfig/autofs  file is sourced.

In the init script the sourcing of the configuration is redundant but
environment variables that are exported will be seen by child processes
(as per normal shell environment variable export rules) and can be used
to over-ride the settings in the autofs configuration. Note that the
internal autofs default is BROWSE_MODE="yes" and that is set to "no" by
the default installed configuration for backward compatibility.

The USE_MISC_DEVICE is the only exception. It is used only by the init
script for checking if /dev/autofs is present and if we want to use
/dev/autofs for kernel communication.

Ian

Re: How to determine a path is a mountpoint.

[Stef Bon]

On Monday 22 February 2010 04:54:03 Ian Kent wrote:


> > 
> > So, am I missing here something? Or has something changed?
> > When I look to the various init rc scripts, the file
> > /etc/sysconfig/autofs  file is sourced.
> 
> In the init script the sourcing of the configuration is redundant but
> environment variables that are exported will be seen by child processes
> (as per normal shell environment variable export rules) and can be used
> to over-ride the settings in the autofs configuration. Note that the
> internal autofs default is BROWSE_MODE="yes" and that is set to "no" by
> the default installed configuration for backward compatibility.


Now when I export them all, they are detected and used. I see logging and browse mode is set to no.

OK now I'm beginning to understand, the automounter reads the configuration values directly, from the default configuration file.
I thought the automounter reads them from the environement, cause the conf file is sourced at the beginning of the init file.

I've found the code. This is, and it happens to me more often, not well documented. Please start a wiki or something. 
I know you are very busy, I recieved some copies of emails about an important issue this weekend.

I'm working also a lot with FUSE, and the wiki there provides a lot of information, although it's not complete. 
I would like to help if I can.

Stef Bon

> 
> The USE_MISC_DEVICE is the only exception. It is used only by the init
> script for checking if /dev/autofs is present and if we want to use
> /dev/autofs for kernel communication.
> 
> Ian

Re: How to determine a path is a mountpoint.

[Ian Kent]

On 02/23/2010 12:30 AM, Stef Bon wrote:
> On Monday 22 February 2010 04:54:03 Ian Kent wrote:
> 
> 
>>>
>>> So, am I missing here something? Or has something changed?
>>> When I look to the various init rc scripts, the file
>>> /etc/sysconfig/autofs  file is sourced.
>>
>> In the init script the sourcing of the configuration is redundant but
>> environment variables that are exported will be seen by child processes
>> (as per normal shell environment variable export rules) and can be used
>> to over-ride the settings in the autofs configuration. Note that the
>> internal autofs default is BROWSE_MODE="yes" and that is set to "no" by
>> the default installed configuration for backward compatibility.
> 
> 
> Now when I export them all, they are detected and used. I see logging and browse mode is set to no.
> 
> OK now I'm beginning to understand, the automounter reads the configuration values directly, from the default configuration file.
> I thought the automounter reads them from the environement, cause the conf file is sourced at the beginning of the init file.
> 
> I've found the code. This is, and it happens to me more often, not well documented. Please start a wiki or something. 
> I know you are very busy, I recieved some copies of emails about an important issue this weekend.
> 
> I'm working also a lot with FUSE, and the wiki there provides a lot of information, although it's not complete. 
> I would like to help if I can.

Yeah, a wiki would be useful but unless we can get a group of us (at
least three people) interested in working on it (and get access details
sorted out) I'm reluctant to set the request for a kernel.org autofs
wiki in motion.

I must admit I'm not keen on having to maintain a wiki site, as I've
said before, purely because in my experience, it's actually quite a bit
of work to make and keep it useful.

> 
> Stef Bon
> 
>>
>> The USE_MISC_DEVICE is the only exception. It is used only by the init
>> script for checking if /dev/autofs is present and if we want to use
>> /dev/autofs for kernel communication.
>>
>> Ian