* autofs 5 not recognizing manual umounts properly
@ 2006-10-28 16:41 Timo Wendt
2006-10-30 6:35 ` Ian Kent
2006-10-30 9:19 ` Ian Kent
0 siblings, 2 replies; 9+ messages in thread
From: Timo Wendt @ 2006-10-28 16:41 UTC (permalink / raw)
To: autofs
[-- Attachment #1.1: Type: text/plain, Size: 716 bytes --]
Hi,
I have just installed FC6 to do some tests with autofs 5 as I need to
use direct mounts. The new version works really great. The only thing
I figured out so far that does not work fine is, when I umount one of
the automounted fs manually.
If I then try to list the contents of that directory it says, that it
is empty. As soon as I try to create a file in that directory, it
fails and seems to realize, that the directory should be mounted and
remounts it, without creating the file though.
Now I have 2 questions:
1. Why is it not remounting the FS when trying an ls on it?
2. Why is it not creating the file after remounting the FS instead of
failing first and then doing the mount?
Timo
[-- Attachment #1.2: Type: text/html, Size: 2895 bytes --]
[-- Attachment #2: Type: text/plain, Size: 140 bytes --]
_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: autofs 5 not recognizing manual umounts properly
2006-10-28 16:41 autofs 5 not recognizing manual umounts properly Timo Wendt
@ 2006-10-30 6:35 ` Ian Kent
2006-10-30 9:53 ` Scott_Rochford
2006-10-30 9:19 ` Ian Kent
1 sibling, 1 reply; 9+ messages in thread
From: Ian Kent @ 2006-10-30 6:35 UTC (permalink / raw)
To: Timo Wendt; +Cc: autofs
On Sat, 2006-10-28 at 18:41 +0200, Timo Wendt wrote:
> Hi,
>
>
> I have just installed FC6 to do some tests with autofs 5 as I need to
> use direct mounts. The new version works really great. The only thing
> I figured out so far that does not work fine is, when I umount one of
> the automounted fs manually.
> If I then try to list the contents of that directory it says, that it
> is empty. As soon as I try to create a file in that directory, it
> fails and seems to realize, that the directory should be mounted and
> remounts it, without creating the file though.
>
>
> Now I have 2 questions:
>
>
> 1. Why is it not remounting the FS when trying an ls on it?
>
>
> 2. Why is it not creating the file after remounting the FS instead of
> failing first and then doing the mount?
I'd need a debug log to see what's going on and more information about
the automount map and the map type you've observed this with.
I'm likely to end up saying that manual umounting of automounted shares
is a bad thing and doing so may lead to unpredictable behavior. I may be
able to improve matters but it is unlikely to be totally reliable.
So I recommend leaving the automounts alone.
Ian
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: autofs 5 not recognizing manual umounts properly
2006-10-30 6:35 ` Ian Kent
@ 2006-10-30 9:53 ` Scott_Rochford
2006-10-30 10:49 ` Ian Kent
0 siblings, 1 reply; 9+ messages in thread
From: Scott_Rochford @ 2006-10-30 9:53 UTC (permalink / raw)
To: autofs
> I'm likely to end up saying that manual umounting of automounted
> shares is a bad thing and doing so may lead to unpredictable
> behavior. I may be able to improve matters but it is unlikely to be
> totally reliable.
> So I recommend leaving the automounts alone.
In an ideal world, yes of course, but in reality in large production
environments with NFS servers going down and/or hanging from time to
time for various reasons I think it's a situation that needs to be
accounted for.
Failing that, an alternative procedure? Stop the automounter, unmount,
and restart it perhaps?
--
Regards,
Scott Rochford
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: autofs 5 not recognizing manual umounts properly
2006-10-30 9:53 ` Scott_Rochford
@ 2006-10-30 10:49 ` Ian Kent
0 siblings, 0 replies; 9+ messages in thread
From: Ian Kent @ 2006-10-30 10:49 UTC (permalink / raw)
To: Scott_Rochford; +Cc: autofs
On Mon, 2006-10-30 at 09:53 +0000, Scott_Rochford@DELL.com wrote:
> > I'm likely to end up saying that manual umounting of automounted
> > shares is a bad thing and doing so may lead to unpredictable
> > behavior. I may be able to improve matters but it is unlikely to be
> > totally reliable.
> > So I recommend leaving the automounts alone.
>
> In an ideal world, yes of course, but in reality in large production
> environments with NFS servers going down and/or hanging from time to
> time for various reasons I think it's a situation that needs to be
> accounted for.
In any world really.
The man pages for the Solaris automounter say much the same thing.
Never the less, it looks like there is some more work to be done in this
area. Also, not all types of automounts will not work properly when they
are manually umounted but I can't say it's OK for some and not others as
that will introduce confusion. In particular, manually umounting parts
of nested mount trees is not something that should be attempted at all.
>
> Failing that, an alternative procedure? Stop the automounter, unmount,
> and restart it perhaps?
As it turns out the FC6 build uses the "--enable-ignore-busy" configure
option. If mounts are wedged then restarting autofs will unlink umount
all mounts and start afresh. This allows existing processes using mounts
that aren't wedged to continue until they are done with the mount, while
new mount requests are handled by the new daemon. Clearly, if a mount is
blocked in an uninterruptable sleep then they won't be released by the
kernel and the process that is stuck would need to be encouraged to go
away in a fairly forceful manner, if it can be persuaded to go away at
all. This is not a perfect solution because there is a finite amount of
time that there is no daemon to answer requests but I can't see any
other way to deal with this.
I've given this problem a lot of thought and considerable effort and
it's about as good as it can be until I can come up with something
better if that's possible.
Ian
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: autofs 5 not recognizing manual umounts properly
2006-10-28 16:41 autofs 5 not recognizing manual umounts properly Timo Wendt
2006-10-30 6:35 ` Ian Kent
@ 2006-10-30 9:19 ` Ian Kent
1 sibling, 0 replies; 9+ messages in thread
From: Ian Kent @ 2006-10-30 9:19 UTC (permalink / raw)
To: Timo Wendt; +Cc: autofs
On Sat, 2006-10-28 at 18:41 +0200, Timo Wendt wrote:
> Hi,
>
>
> I have just installed FC6 to do some tests with autofs 5 as I need to
> use direct mounts. The new version works really great. The only thing
> I figured out so far that does not work fine is, when I umount one of
> the automounted fs manually.
> If I then try to list the contents of that directory it says, that it
> is empty. As soon as I try to create a file in that directory, it
> fails and seems to realize, that the directory should be mounted and
> remounts it, without creating the file though.
And what kernel are you using?
And the version of autofs?
Ian
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: autofs 5 not recognizing manual umounts properly
@ 2006-10-31 19:46 twendt
2006-11-01 3:35 ` Ian Kent
2006-11-05 9:48 ` Ian Kent
0 siblings, 2 replies; 9+ messages in thread
From: twendt @ 2006-10-31 19:46 UTC (permalink / raw)
To: raven; +Cc: autofs
>On Sat, 2006-10-28 at 18:41 +0200, Timo Wendt wrote:
>> Hi,
>>
>>
>> I have just installed FC6 to do some tests with autofs 5 as I need to
>> use direct mounts. The new version works really great. The only thing
>> I figured out so far that does not work fine is, when I umount one of
>> the automounted fs manually.
>> If I then try to list the contents of that directory it says, that it
>> is empty. As soon as I try to create a file in that directory, it
>> fails and seems to realize, that the directory should be mounted and
>> remounts it, without creating the file though.
>
>And what kernel are you using?
>And the version of autofs?
>
>Ian
>
>
Hi,
sorry for the delay I didn't get to check this yesterday.
I have the following maps:
/etc/auto.master:
/- /etc/auto.direct
/etc/auto.direct:
/home/timo 192.168.178.187:/mnt
The IP is actually the local IP, therefore I get bind mounts instead of NFS mounts.
Here is what I am doing:
[root@localhost autofs-5.0.1]# mount
/dev/mapper/vg00-lvroot on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda5 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/mapper/vg00-lvxen on /xen_domains type ext3 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
[root@localhost autofs-5.0.1]# ll /home/timo
total 0
-rw-r--r-- 1 root root 0 Oct 27 20:09 a
[root@localhost autofs-5.0.1]# umount /mnt
[root@localhost autofs-5.0.1]# mount
/dev/mapper/vg00-lvroot on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda5 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/mapper/vg00-lvxen on /xen_domains type ext3 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
[root@localhost autofs-5.0.1]# ll /home/timo
total 0
[root@localhost autofs-5.0.1]# ll /home/timo
total 0
[root@localhost autofs-5.0.1]# touch /home/timo/b
touch: cannot touch `/home/timo/b': Permission denied
[root@localhost autofs-5.0.1]# mount
/dev/mapper/vg00-lvroot on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda5 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/mapper/vg00-lvxen on /xen_domains type ext3 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
/mnt on /home/timo type none (rw,bind)
[root@localhost autofs-5.0.1]# ll /home/timo
total 0
-rw-r--r-- 1 root root 0 Oct 27 20:09 a
Here are the logentries of all that:
Oct 31 21:31:18 localhost automount[4407]: st_expire: state 1 path /-
Oct 31 21:31:18 localhost automount[4407]: expire_proc: exp_proc = 3084585872 path /-
Oct 31 21:31:18 localhost automount[4407]: expire_cleanup: got thid 3084585872 path /- stat 0
Oct 31 21:31:18 localhost automount[4407]: expire_cleanup: sigchld: exp 3084585872 finished, switching from 2 to 1
Oct 31 21:31:18 localhost automount[4407]: st_ready: st_ready(): state = 2 path /-
Oct 31 21:31:21 localhost automount[4407]: handle_packet: type = 5
Oct 31 21:31:21 localhost automount[4407]: handle_packet_missing_direct: token 33, name /home/timo, request pid 4418
Oct 31 21:31:21 localhost automount[4407]: attempting to mount entry /home/timo
Oct 31 21:31:21 localhost automount[4407]: lookup_mount: lookup(file): looking up /home/timo
Oct 31 21:31:21 localhost automount[4407]: lookup_mount: lookup(file): /home/timo -> 192.168.178.187:/mnt
Oct 31 21:31:21 localhost automount[4407]: parse_mount: parse(sun): expanded entry: 192.168.178.187:/mnt
Oct 31 21:31:21 localhost automount[4407]: parse_mount: parse(sun): gathered options:
Oct 31 21:31:21 localhost automount[4407]: parse_mount: parse(sun): dequote("192.168.178.187:/mnt") -> 192.168.178.187:/mnt
Oct 31 21:31:21 localhost automount[4407]: parse_mount: parse(sun): core of entry: options=, loc=192.168.178.187:/mnt
Oct 31 21:31:21 localhost automount[4407]: sun_mount: parse(sun): mounting root /-, mountpoint /home/timo, what 192.168.178.187:/mnt, fstype nfs, options (null)
Oct 31 21:31:21 localhost automount[4407]: mount_mount: mount(nfs): root=/- name=/home/timo what=192.168.178.187:/mnt, fstype=nfs, options=(null)
Oct 31 21:31:21 localhost automount[4407]: mount_mount: mount(nfs): calling mkdir_path /home/timo
Oct 31 21:31:21 localhost automount[4407]: mount_mount: mount(nfs): /home/timo is local, attempt bind mount
Oct 31 21:31:21 localhost automount[4407]: mount_mount: mount(bind): calling mkdir_path /home/timo
Oct 31 21:31:21 localhost automount[4407]: mount_mount: mount(bind): calling mount --bind -s -o defaults /mnt /home/timo
Oct 31 21:31:21 localhost automount[4407]: mount_mount: mount(bind): mounted /mnt type bind on /home/timo
Oct 31 21:31:21 localhost automount[4407]: send_ready: token = 33
Oct 31 21:31:21 localhost automount[4407]: mounted /home/timo
Oct 31 21:31:33 localhost automount[4407]: st_expire: state 1 path /-
Oct 31 21:31:33 localhost automount[4407]: expire_proc: exp_proc = 3084585872 path /-
Oct 31 21:31:33 localhost automount[4407]: expire_proc_direct: send expire to trigger /home/timo
Oct 31 21:31:33 localhost automount[4407]: expire_proc_direct: send expire to trigger /home/timo
Oct 31 21:31:34 localhost automount[4407]: expire_cleanup: got thid 3084585872 path /- stat 2
Oct 31 21:31:34 localhost automount[4407]: expire_cleanup: sigchld: exp 3084585872 finished, switching from 2 to 1
Oct 31 21:31:34 localhost automount[4407]: st_ready: st_ready(): state = 2 path /-
Oct 31 21:31:49 localhost automount[4407]: st_expire: state 1 path /-
Oct 31 21:31:49 localhost automount[4407]: expire_proc: exp_proc = 3084585872 path /-
Oct 31 21:31:49 localhost automount[4407]: expire_proc_direct: send expire to trigger /home/timo
Oct 31 21:31:49 localhost automount[4407]: expire_cleanup: got thid 3084585872 path /- stat 0
Oct 31 21:31:49 localhost automount[4407]: expire_cleanup: sigchld: exp 3084585872 finished, switching from 2 to 1
Oct 31 21:31:49 localhost automount[4407]: st_ready: st_ready(): state = 2 path /-
Oct 31 21:31:57 localhost automount[4407]: handle_packet: type = 5
Oct 31 21:31:57 localhost automount[4407]: handle_packet_missing_direct: token 34, name /home/timo, request pid 4425
Oct 31 21:31:57 localhost automount[4407]: attempting to mount entry /home/timo
Oct 31 21:31:57 localhost automount[4407]: lookup_mount: lookup(file): looking up /home/timo
Oct 31 21:31:57 localhost automount[4407]: lookup_mount: lookup(file): /home/timo -> 192.168.178.187:/mnt
Oct 31 21:31:57 localhost automount[4407]: parse_mount: parse(sun): expanded entry: 192.168.178.187:/mnt
Oct 31 21:31:57 localhost automount[4407]: parse_mount: parse(sun): gathered options:
Oct 31 21:31:57 localhost automount[4407]: parse_mount: parse(sun): dequote("192.168.178.187:/mnt") -> 192.168.178.187:/mnt
Oct 31 21:31:57 localhost automount[4407]: parse_mount: parse(sun): core of entry: options=, loc=192.168.178.187:/mnt
Oct 31 21:31:57 localhost automount[4407]: sun_mount: parse(sun): mounting root /-, mountpoint /home/timo, what 192.168.178.187:/mnt, fstype nfs, options (null)
Oct 31 21:31:57 localhost automount[4407]: mount_mount: mount(nfs): root=/- name=/home/timo what=192.168.178.187:/mnt, fstype=nfs, options=(null)
Oct 31 21:31:57 localhost automount[4407]: mount_mount: mount(nfs): calling mkdir_path /home/timo
Oct 31 21:31:57 localhost automount[4407]: mount_mount: mount(nfs): /home/timo is local, attempt bind mount
Oct 31 21:31:57 localhost automount[4407]: mount_mount: mount(bind): calling mkdir_path /home/timo
Oct 31 21:31:57 localhost automount[4407]: mount_mount: mount(bind): calling mount --bind -s -o defaults /mnt /home/timo
Oct 31 21:31:57 localhost automount[4407]: mount_mount: mount(bind): mounted /mnt type bind on /home/timo
Oct 31 21:31:57 localhost automount[4407]: send_ready: token = 34
Oct 31 21:31:57 localhost automount[4407]: mounted /home/timo
Oct 31 21:32:04 localhost automount[4407]: st_expire: state 1 path /-
Oct 31 21:32:04 localhost automount[4407]: expire_proc: exp_proc = 3084585872 path /-
Oct 31 21:32:04 localhost automount[4407]: expire_proc_direct: send expire to trigger /home/timo
Oct 31 21:32:04 localhost automount[4407]: expire_proc_direct: send expire to trigger /home/timo
Oct 31 21:32:05 localhost automount[4407]: expire_cleanup: got thid 3084585872 path /- stat 2
Oct 31 21:32:05 localhost automount[4407]: expire_cleanup: sigchld: exp 3084585872 finished, switching from 2 to 1
Oct 31 21:32:05 localhost automount[4407]: st_ready: st_ready(): state = 2 path /-
There is no logentry when I umount the directory and then also nothing when I try the ll /home/timo
My Kernel version is:
Linux localhost.localdomain 2.6.18-1.2798.fc6xen #1 SMP Mon Oct 16 15:11:19 EDT 2006 i686 i686 i386 GNU/Linux
[root@localhost autofs-5.0.1]# automount -V
Linux automount version 5.0.1-0.rc2.17
Directories:
config dir: /etc/sysconfig
maps dir: /etc
modules dir: /usr/lib/autofs
Compile options:
DISABLE_MOUNT_LOCKING ENABLE_IGNORE_BUSY_MOUNTS WITH_HESIOD WITH_LDAP
WITH_SASL
Another thing I realized is that it still does expired the mount after the timeout period even if I try to access it it the meantime. After the expiration it does the mount again and everything is working again.
So a workaround seems to be to choose fairly small timeouts. Is there any minimum time out that should be used? Are there any performance affects if I choose very small timeouts?
Thanks for your help,
Timo
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: autofs 5 not recognizing manual umounts properly
2006-10-31 19:46 twendt
@ 2006-11-01 3:35 ` Ian Kent
2006-11-05 9:48 ` Ian Kent
1 sibling, 0 replies; 9+ messages in thread
From: Ian Kent @ 2006-11-01 3:35 UTC (permalink / raw)
To: twendt; +Cc: autofs
On Tue, 2006-10-31 at 20:46 +0100, twendt@online.de wrote:
> >On Sat, 2006-10-28 at 18:41 +0200, Timo Wendt wrote:
> >> Hi,
> >>
> >>
> >> I have just installed FC6 to do some tests with autofs 5 as I need to
> >> use direct mounts. The new version works really great. The only thing
> >> I figured out so far that does not work fine is, when I umount one of
> >> the automounted fs manually.
> >> If I then try to list the contents of that directory it says, that it
> >> is empty. As soon as I try to create a file in that directory, it
> >> fails and seems to realize, that the directory should be mounted and
> >> remounts it, without creating the file though.
> >
> >And what kernel are you using?
> >And the version of autofs?
> >
> >Ian
> >
> >
> Hi,
>
> sorry for the delay I didn't get to check this yesterday.
I'll try and duplicate this.
>
> I have the following maps:
>
> /etc/auto.master:
>
> /- /etc/auto.direct
>
> /etc/auto.direct:
>
> /home/timo 192.168.178.187:/mnt
>
> The IP is actually the local IP, therefore I get bind mounts instead of NFS mounts.
>
> Here is what I am doing:
>
> [root@localhost autofs-5.0.1]# mount
> /dev/mapper/vg00-lvroot on / type ext3 (rw)
> proc on /proc type proc (rw)
> sysfs on /sys type sysfs (rw)
> devpts on /dev/pts type devpts (rw,gid=5,mode=620)
> /dev/hda5 on /boot type ext3 (rw)
> tmpfs on /dev/shm type tmpfs (rw)
> /dev/mapper/vg00-lvxen on /xen_domains type ext3 (rw)
> none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
> sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
> nfsd on /proc/fs/nfsd type nfsd (rw)
>
> [root@localhost autofs-5.0.1]# ll /home/timo
> total 0
> -rw-r--r-- 1 root root 0 Oct 27 20:09 a
Would have been good to have a list of mounts here.
And at this point a copy of /proc/mounts.
>
> [root@localhost autofs-5.0.1]# umount /mnt
>
> [root@localhost autofs-5.0.1]# mount
> /dev/mapper/vg00-lvroot on / type ext3 (rw)
> proc on /proc type proc (rw)
> sysfs on /sys type sysfs (rw)
> devpts on /dev/pts type devpts (rw,gid=5,mode=620)
> /dev/hda5 on /boot type ext3 (rw)
> tmpfs on /dev/shm type tmpfs (rw)
> /dev/mapper/vg00-lvxen on /xen_domains type ext3 (rw)
> none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
> sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
> nfsd on /proc/fs/nfsd type nfsd (rw)
And again a copy of /proc/mounts.
>
> [root@localhost autofs-5.0.1]# ll /home/timo
> total 0
>
> [root@localhost autofs-5.0.1]# ll /home/timo
> total 0
>
> [root@localhost autofs-5.0.1]# touch /home/timo/b
> touch: cannot touch `/home/timo/b': Permission denied
>
> [root@localhost autofs-5.0.1]# mount
> /dev/mapper/vg00-lvroot on / type ext3 (rw)
> proc on /proc type proc (rw)
> sysfs on /sys type sysfs (rw)
> devpts on /dev/pts type devpts (rw,gid=5,mode=620)
> /dev/hda5 on /boot type ext3 (rw)
> tmpfs on /dev/shm type tmpfs (rw)
> /dev/mapper/vg00-lvxen on /xen_domains type ext3 (rw)
> none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
> sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
> nfsd on /proc/fs/nfsd type nfsd (rw)
> /mnt on /home/timo type none (rw,bind)
>
> [root@localhost autofs-5.0.1]# ll /home/timo
> total 0
> -rw-r--r-- 1 root root 0 Oct 27 20:09 a
>
> Here are the logentries of all that:
snip ...
> Oct 31 21:31:57 localhost automount[4407]: mounted /home/timo
> Oct 31 21:32:04 localhost automount[4407]: st_expire: state 1 path /-
> Oct 31 21:32:04 localhost automount[4407]: expire_proc: exp_proc = 3084585872 path /-
> Oct 31 21:32:04 localhost automount[4407]: expire_proc_direct: send expire to trigger /home/timo
> Oct 31 21:32:04 localhost automount[4407]: expire_proc_direct: send expire to trigger /home/timo
This isn't right.
There should only be one real mount at this point.
The mount lists above should tell us what's wrong here.
> Oct 31 21:32:05 localhost automount[4407]: expire_cleanup: got thid 3084585872 path /- stat 2
> Oct 31 21:32:05 localhost automount[4407]: expire_cleanup: sigchld: exp 3084585872 finished, switching from 2 to 1
> Oct 31 21:32:05 localhost automount[4407]: st_ready: st_ready(): state = 2 path /-
>
>
>
> There is no logentry when I umount the directory and then also nothing when I try the ll /home/timo
Looking at the code I can see a problem but it doesn't look like it
would lead to this symptom, but you never know. Again I'll try this out.
and see.
>
> My Kernel version is:
> Linux localhost.localdomain 2.6.18-1.2798.fc6xen #1 SMP Mon Oct 16 15:11:19 EDT 2006 i686 i686 i386 GNU/Linux
>
> [root@localhost autofs-5.0.1]# automount -V
>
> Linux automount version 5.0.1-0.rc2.17
>
> Directories:
> config dir: /etc/sysconfig
> maps dir: /etc
> modules dir: /usr/lib/autofs
>
> Compile options:
> DISABLE_MOUNT_LOCKING ENABLE_IGNORE_BUSY_MOUNTS WITH_HESIOD WITH_LDAP
> WITH_SASL
>
>
> Another thing I realized is that it still does expired the mount after the timeout period even if I try to access it it the meantime. After the expiration it does the mount again and everything is working again.
Yes.
The expire semantic is a little different in v5.
A mount is considered busy only if it is continually busy. An open file
or a process working directory will do it.
>
> So a workaround seems to be to choose fairly small timeouts. Is there any minimum time out that should be used? Are there any performance affects if I choose very small timeouts?
Only the frequency of expire runs.
Shouldn't be a problem for small maps.
Ian
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: autofs 5 not recognizing manual umounts properly
2006-10-31 19:46 twendt
2006-11-01 3:35 ` Ian Kent
@ 2006-11-05 9:48 ` Ian Kent
2006-11-16 12:48 ` Timo Wendt
1 sibling, 1 reply; 9+ messages in thread
From: Ian Kent @ 2006-11-05 9:48 UTC (permalink / raw)
To: twendt; +Cc: autofs
[-- Attachment #1: Type: text/plain, Size: 4415 bytes --]
On Tue, 2006-10-31 at 20:46 +0100, twendt@online.de wrote:
> >On Sat, 2006-10-28 at 18:41 +0200, Timo Wendt wrote:
> >> Hi,
> >>
> >>
> >> I have just installed FC6 to do some tests with autofs 5 as I need to
> >> use direct mounts. The new version works really great. The only thing
> >> I figured out so far that does not work fine is, when I umount one of
> >> the automounted fs manually.
> >> If I then try to list the contents of that directory it says, that it
> >> is empty. As soon as I try to create a file in that directory, it
> >> fails and seems to realize, that the directory should be mounted and
> >> remounts it, without creating the file though.
> >
> >And what kernel are you using?
> >And the version of autofs?
> >
> >Ian
> >
> >
> Hi,
>
> sorry for the delay I didn't get to check this yesterday.
>
> I have the following maps:
>
> /etc/auto.master:
>
> /- /etc/auto.direct
>
> /etc/auto.direct:
>
> /home/timo 192.168.178.187:/mnt
>
> The IP is actually the local IP, therefore I get bind mounts instead of NFS mounts.
>
> Here is what I am doing:
>
> [root@localhost autofs-5.0.1]# mount
> /dev/mapper/vg00-lvroot on / type ext3 (rw)
> proc on /proc type proc (rw)
> sysfs on /sys type sysfs (rw)
> devpts on /dev/pts type devpts (rw,gid=5,mode=620)
> /dev/hda5 on /boot type ext3 (rw)
> tmpfs on /dev/shm type tmpfs (rw)
> /dev/mapper/vg00-lvxen on /xen_domains type ext3 (rw)
> none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
> sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
> nfsd on /proc/fs/nfsd type nfsd (rw)
>
> [root@localhost autofs-5.0.1]# ll /home/timo
> total 0
> -rw-r--r-- 1 root root 0 Oct 27 20:09 a
>
> [root@localhost autofs-5.0.1]# umount /mnt
>
> [root@localhost autofs-5.0.1]# mount
> /dev/mapper/vg00-lvroot on / type ext3 (rw)
> proc on /proc type proc (rw)
> sysfs on /sys type sysfs (rw)
> devpts on /dev/pts type devpts (rw,gid=5,mode=620)
> /dev/hda5 on /boot type ext3 (rw)
> tmpfs on /dev/shm type tmpfs (rw)
> /dev/mapper/vg00-lvxen on /xen_domains type ext3 (rw)
> none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
> sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
> nfsd on /proc/fs/nfsd type nfsd (rw)
>
> [root@localhost autofs-5.0.1]# ll /home/timo
> total 0
>
> [root@localhost autofs-5.0.1]# ll /home/timo
> total 0
>
> [root@localhost autofs-5.0.1]# touch /home/timo/b
> touch: cannot touch `/home/timo/b': Permission denied
>
> [root@localhost autofs-5.0.1]# mount
> /dev/mapper/vg00-lvroot on / type ext3 (rw)
> proc on /proc type proc (rw)
> sysfs on /sys type sysfs (rw)
> devpts on /dev/pts type devpts (rw,gid=5,mode=620)
> /dev/hda5 on /boot type ext3 (rw)
> tmpfs on /dev/shm type tmpfs (rw)
> /dev/mapper/vg00-lvxen on /xen_domains type ext3 (rw)
> none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
> sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
> nfsd on /proc/fs/nfsd type nfsd (rw)
> /mnt on /home/timo type none (rw,bind)
>
> [root@localhost autofs-5.0.1]# ll /home/timo
> total 0
> -rw-r--r-- 1 root root 0 Oct 27 20:09 a
>
There are three kernel patches that resulted from testing that aren't
present in the FC6 kernel. They are working their way through the rc
process for 2.6.19 at the moment. I've attached them.
I think that the autofs4-2.6.18-rc4-mm1-follow_link-false-negative.patch
patch resolves this issue. This patch allows autofs4 to recognize a
direct mount trigger as a mount point even if it has remnant dentrys
(basically stale or never instantiated directories). I'm a little
surprised as I didn't think this was a case where remnant dentrys are
created and I can't see where it happens in the log. The other two
patches address quite different issues.
Additionally, I noticed that the manual umount can lead to a file handle
leak and the patch
autofs-5.0.1-rc2-check-fh-on-mount-trigger.patch should fix that.
I haven't tested this last patch yet apart from that it compiles.
I must reiterate that manually umounting mounts is not recommended
although it should be fine for simple indirect and direct mounts.
Multi-mounts are another matter altogether. If you know the autofs
internals of how they work, manually umounting such a tree (including
the internal autofs trigger mounts) in the correct order may work but
you could easily get yourself into the situation where entries won't
mount or expire, which would require a restart to fix.
Ian
[-- Attachment #2: autofs4-2.6.18-rc4-mm1-follow_link-false-negative.patch --]
[-- Type: text/x-patch, Size: 510 bytes --]
--- linux-2.6.18-rc4-mm1/fs/autofs4/root.c.follow_link-false-negative 2006-08-14 10:13:59.000000000 +0800
+++ linux-2.6.18-rc4-mm1/fs/autofs4/root.c 2006-08-14 10:15:26.000000000 +0800
@@ -359,7 +359,7 @@ static void *autofs4_follow_link(struct
* don't try to mount it again.
*/
spin_lock(&dcache_lock);
- if (!d_mountpoint(dentry) && list_empty(&dentry->d_subdirs)) {
+ if (!d_mountpoint(dentry) && __simple_empty(dentry)) {
spin_unlock(&dcache_lock);
status = try_to_fill_dentry(dentry, 0);
[-- Attachment #3: autofs4-2.6.18-rc4-mm2-clear-pending.patch --]
[-- Type: text/x-patch, Size: 732 bytes --]
--- linux-2.6.18-rc4-mm2/fs/autofs4/root.c.clear-pending 2006-08-20 13:20:23.000000000 +0800
+++ linux-2.6.18-rc4-mm2/fs/autofs4/root.c 2006-08-20 13:21:30.000000000 +0800
@@ -281,9 +281,6 @@ static int try_to_fill_dentry(struct den
DPRINTK("mount done status=%d", status);
- if (status && dentry->d_inode)
- return status; /* Try to get the kernel to invalidate this dentry */
-
/* Turn this into a real negative dentry? */
if (status == -ENOENT) {
spin_lock(&dentry->d_lock);
@@ -540,6 +537,9 @@ static struct dentry *autofs4_lookup(str
return ERR_PTR(-ERESTARTNOINTR);
}
}
+ spin_lock(&dentry->d_lock);
+ dentry->d_flags &= ~DCACHE_AUTOFS_PENDING;
+ spin_unlock(&dentry->d_lock);
}
/*
[-- Attachment #4: autofs4-2.6.18-rc6-mm2-zero-timeout.txt --]
[-- Type: text/plain, Size: 1327 bytes --]
If the timeout of an autofs mount is set to zero then umounts
are disabled. This works fine, however the kernel module checks
the expire timeout and goes no further if it is zero. This is
not the right thing to do at shutdown as the module is passed
an option to expire mounts regardless of their timeout setting.
This patch allows autofs to honor the force expire option.
Signed-off-by: Ian Kent <raven@themaw.net>
---
--- linux-2.6.18-rc6-mm2/fs/autofs4/expire.c.zero-timeout 2006-09-14 10:25:55.000000000 +0800
+++ linux-2.6.18-rc6-mm2/fs/autofs4/expire.c 2006-09-14 10:37:54.000000000 +0800
@@ -32,7 +32,7 @@ static inline int autofs4_can_expire(str
if (!do_now) {
/* Too young to die */
- if (time_after(ino->last_used + timeout, now))
+ if (!timeout || time_after(ino->last_used + timeout, now))
return 0;
/* update last_used here :-
@@ -253,7 +253,7 @@ static struct dentry *autofs4_expire_dir
struct dentry *root = dget(sb->s_root);
int do_now = how & AUTOFS_EXP_IMMEDIATE;
- if (!sbi->exp_timeout || !root)
+ if (!root)
return NULL;
now = jiffies;
@@ -293,7 +293,7 @@ static struct dentry *autofs4_expire_ind
int do_now = how & AUTOFS_EXP_IMMEDIATE;
int exp_leaves = how & AUTOFS_EXP_LEAVES;
- if ( !sbi->exp_timeout || !root )
+ if (!root)
return NULL;
now = jiffies;
[-- Attachment #5: autofs-5.0.1-rc2-check-fh-on-mount-trigger.patch --]
[-- Type: text/x-patch, Size: 590 bytes --]
diff --git a/daemon/direct.c b/daemon/direct.c
index c92a745..f75ce2d 100644
--- a/daemon/direct.c
+++ b/daemon/direct.c
@@ -1392,8 +1392,14 @@ int handle_packet_missing_direct(struct
return 1;
}
- ioctlfd = open(me->key, O_RDONLY);
- if (ioctlfd < 0) {
+ if (me->ioctlfd != -1) {
+ /* Maybe someone did a manual umount, clean up ! */
+ ioctlfd = me->ioctlfd;
+ me->ioctlfd = -1;
+ } else
+ ioctlfd = open(me->key, O_RDONLY);
+
+ if (ioctlfd == -1) {
cache_unlock(mc);
pthread_setcancelstate(state, NULL);
crit(ap->logopt, "failed to create ioctl fd for %s", me->key);
[-- Attachment #6: Type: text/plain, Size: 140 bytes --]
_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: autofs 5 not recognizing manual umounts properly
2006-11-05 9:48 ` Ian Kent
@ 2006-11-16 12:48 ` Timo Wendt
0 siblings, 0 replies; 9+ messages in thread
From: Timo Wendt @ 2006-11-16 12:48 UTC (permalink / raw)
To: Ian Kent; +Cc: autofs
[-- Attachment #1.1: Type: text/plain, Size: 4930 bytes --]
Hi,
that are really good news. Thanks for the effort. I will see if I can
check these patches out.
Timo
Am 05.11.2006 um 10:48 schrieb Ian Kent:
> On Tue, 2006-10-31 at 20:46 +0100, twendt@online.de wrote:
>>> On Sat, 2006-10-28 at 18:41 +0200, Timo Wendt wrote:
>>>> Hi,
>>>>
>>>>
>>>> I have just installed FC6 to do some tests with autofs 5 as I
>>>> need to
>>>> use direct mounts. The new version works really great. The only
>>>> thing
>>>> I figured out so far that does not work fine is, when I umount
>>>> one of
>>>> the automounted fs manually.
>>>> If I then try to list the contents of that directory it says,
>>>> that it
>>>> is empty. As soon as I try to create a file in that directory, it
>>>> fails and seems to realize, that the directory should be mounted
>>>> and
>>>> remounts it, without creating the file though.
>>>
>>> And what kernel are you using?
>>> And the version of autofs?
>>>
>>> Ian
>>>
>>>
>> Hi,
>>
>> sorry for the delay I didn't get to check this yesterday.
>>
>> I have the following maps:
>>
>> /etc/auto.master:
>>
>> /- /etc/auto.direct
>>
>> /etc/auto.direct:
>>
>> /home/timo 192.168.178.187:/mnt
>>
>> The IP is actually the local IP, therefore I get bind mounts
>> instead of NFS mounts.
>>
>> Here is what I am doing:
>>
>> [root@localhost autofs-5.0.1]# mount
>> /dev/mapper/vg00-lvroot on / type ext3 (rw)
>> proc on /proc type proc (rw)
>> sysfs on /sys type sysfs (rw)
>> devpts on /dev/pts type devpts (rw,gid=5,mode=620)
>> /dev/hda5 on /boot type ext3 (rw)
>> tmpfs on /dev/shm type tmpfs (rw)
>> /dev/mapper/vg00-lvxen on /xen_domains type ext3 (rw)
>> none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
>> sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
>> nfsd on /proc/fs/nfsd type nfsd (rw)
>>
>> [root@localhost autofs-5.0.1]# ll /home/timo
>> total 0
>> -rw-r--r-- 1 root root 0 Oct 27 20:09 a
>>
>> [root@localhost autofs-5.0.1]# umount /mnt
>>
>> [root@localhost autofs-5.0.1]# mount
>> /dev/mapper/vg00-lvroot on / type ext3 (rw)
>> proc on /proc type proc (rw)
>> sysfs on /sys type sysfs (rw)
>> devpts on /dev/pts type devpts (rw,gid=5,mode=620)
>> /dev/hda5 on /boot type ext3 (rw)
>> tmpfs on /dev/shm type tmpfs (rw)
>> /dev/mapper/vg00-lvxen on /xen_domains type ext3 (rw)
>> none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
>> sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
>> nfsd on /proc/fs/nfsd type nfsd (rw)
>>
>> [root@localhost autofs-5.0.1]# ll /home/timo
>> total 0
>>
>> [root@localhost autofs-5.0.1]# ll /home/timo
>> total 0
>>
>> [root@localhost autofs-5.0.1]# touch /home/timo/b
>> touch: cannot touch `/home/timo/b': Permission denied
>>
>> [root@localhost autofs-5.0.1]# mount
>> /dev/mapper/vg00-lvroot on / type ext3 (rw)
>> proc on /proc type proc (rw)
>> sysfs on /sys type sysfs (rw)
>> devpts on /dev/pts type devpts (rw,gid=5,mode=620)
>> /dev/hda5 on /boot type ext3 (rw)
>> tmpfs on /dev/shm type tmpfs (rw)
>> /dev/mapper/vg00-lvxen on /xen_domains type ext3 (rw)
>> none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
>> sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
>> nfsd on /proc/fs/nfsd type nfsd (rw)
>> /mnt on /home/timo type none (rw,bind)
>>
>> [root@localhost autofs-5.0.1]# ll /home/timo
>> total 0
>> -rw-r--r-- 1 root root 0 Oct 27 20:09 a
>>
>
> There are three kernel patches that resulted from testing that aren't
> present in the FC6 kernel. They are working their way through the rc
> process for 2.6.19 at the moment. I've attached them.
>
> I think that the autofs4-2.6.18-rc4-mm1-follow_link-false-
> negative.patch
> patch resolves this issue. This patch allows autofs4 to recognize a
> direct mount trigger as a mount point even if it has remnant dentrys
> (basically stale or never instantiated directories). I'm a little
> surprised as I didn't think this was a case where remnant dentrys are
> created and I can't see where it happens in the log. The other two
> patches address quite different issues.
>
> Additionally, I noticed that the manual umount can lead to a file
> handle
> leak and the patch
> autofs-5.0.1-rc2-check-fh-on-mount-trigger.patch should fix that.
>
> I haven't tested this last patch yet apart from that it compiles.
>
> I must reiterate that manually umounting mounts is not recommended
> although it should be fine for simple indirect and direct mounts.
> Multi-mounts are another matter altogether. If you know the autofs
> internals of how they work, manually umounting such a tree (including
> the internal autofs trigger mounts) in the correct order may work but
> you could easily get yourself into the situation where entries won't
> mount or expire, which would require a restart to fix.
>
> Ian
>
> <autofs4-2.6.18-rc4-mm1-follow_link-false-negative.patch>
> <autofs4-2.6.18-rc4-mm2-clear-pending.patch>
> <autofs4-2.6.18-rc6-mm2-zero-timeout.txt>
> <autofs-5.0.1-rc2-check-fh-on-mount-trigger.patch>
[-- Attachment #1.2: Type: text/html, Size: 18271 bytes --]
[-- Attachment #2: Type: text/plain, Size: 140 bytes --]
_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-11-16 12:48 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-28 16:41 autofs 5 not recognizing manual umounts properly Timo Wendt
2006-10-30 6:35 ` Ian Kent
2006-10-30 9:53 ` Scott_Rochford
2006-10-30 10:49 ` Ian Kent
2006-10-30 9:19 ` Ian Kent
-- strict thread matches above, loose matches on Subject: below --
2006-10-31 19:46 twendt
2006-11-01 3:35 ` Ian Kent
2006-11-05 9:48 ` Ian Kent
2006-11-16 12:48 ` Timo Wendt
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.