From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timo Wendt Subject: autofs 5 not recognizing manual umounts properly Date: Sat, 28 Oct 2006 18:41:13 +0200 Message-ID: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/mixed; boundary="===============8769823635489907005==" Return-path: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org To: autofs@linux.kernel.org --===============8769823635489907005== Content-Type: multipart/alternative; boundary=Apple-Mail-14--937120087 --Apple-Mail-14--937120087 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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 --Apple-Mail-14--937120087 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII

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?

= --Apple-Mail-14--937120087-- --===============8769823635489907005== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============8769823635489907005==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Kent Subject: Re: autofs 5 not recognizing manual umounts properly Date: Mon, 30 Oct 2006 14:35:02 +0800 Message-ID: <1162190102.2900.13.camel@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org To: Timo Wendt Cc: autofs@linux.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Kent Subject: Re: autofs 5 not recognizing manual umounts properly Date: Mon, 30 Oct 2006 17:19:27 +0800 Message-ID: <1162199967.2900.15.camel@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org To: Timo Wendt Cc: autofs@linux.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subject: Re: autofs 5 not recognizing manual umounts properly Date: Mon, 30 Oct 2006 09:53:21 -0000 Message-ID: <0F5A1C742BC73849AFF518F1F8249D4D0181D723@mtpx3m2.mtp.emea.dell.com> References: <1162190102.2900.13.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-class: urn:content-classes:message In-Reply-To: <1162190102.2900.13.camel@localhost> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org To: autofs@linux.kernel.org > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Kent Subject: Re: autofs 5 not recognizing manual umounts properly Date: Mon, 30 Oct 2006 18:49:12 +0800 Message-ID: <1162205352.2900.40.camel@localhost> References: <0F5A1C742BC73849AFF518F1F8249D4D0181D723@mtpx3m2.mtp.emea.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <0F5A1C742BC73849AFF518F1F8249D4D0181D723@mtpx3m2.mtp.emea.dell.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org To: Scott_Rochford@DELL.com Cc: autofs@linux.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: twendt@online.de Subject: Re: autofs 5 not recognizing manual umounts properly Date: Tue, 31 Oct 2006 20:46:23 +0100 Message-ID: <10272992.2537671162323983680.JavaMail.servlet@kundenserver> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org To: raven@themaw.net Cc: autofs@linux.kernel.org >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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Kent Subject: Re: autofs 5 not recognizing manual umounts properly Date: Wed, 01 Nov 2006 11:35:34 +0800 Message-ID: <1162352134.3579.33.camel@localhost> References: <10272992.2537671162323983680.JavaMail.servlet@kundenserver> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <10272992.2537671162323983680.JavaMail.servlet@kundenserver> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org To: twendt@online.de Cc: autofs@linux.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Kent Subject: Re: autofs 5 not recognizing manual umounts properly Date: Sun, 05 Nov 2006 17:48:37 +0800 Message-ID: <1162720118.13896.25.camel@localhost> References: <10272992.2537671162323983680.JavaMail.servlet@kundenserver> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-H8Saj7u4y/F9lMJvtHnv" Return-path: In-Reply-To: <10272992.2537671162323983680.JavaMail.servlet@kundenserver> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org To: twendt@online.de Cc: autofs@linux.kernel.org --=-H8Saj7u4y/F9lMJvtHnv Content-Type: text/plain Content-Transfer-Encoding: 7bit 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 --=-H8Saj7u4y/F9lMJvtHnv Content-Disposition: attachment; filename=autofs4-2.6.18-rc4-mm1-follow_link-false-negative.patch Content-Type: text/x-patch; name=autofs4-2.6.18-rc4-mm1-follow_link-false-negative.patch; charset=utf-8 Content-Transfer-Encoding: 7bit --- 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); --=-H8Saj7u4y/F9lMJvtHnv Content-Disposition: attachment; filename=autofs4-2.6.18-rc4-mm2-clear-pending.patch Content-Type: text/x-patch; name=autofs4-2.6.18-rc4-mm2-clear-pending.patch; charset=utf-8 Content-Transfer-Encoding: 7bit --- 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); } /* --=-H8Saj7u4y/F9lMJvtHnv Content-Disposition: attachment; filename=autofs4-2.6.18-rc6-mm2-zero-timeout.txt Content-Type: text/plain; name=autofs4-2.6.18-rc6-mm2-zero-timeout.txt; charset=utf-8 Content-Transfer-Encoding: 7bit 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 --- --- 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; --=-H8Saj7u4y/F9lMJvtHnv Content-Disposition: attachment; filename=autofs-5.0.1-rc2-check-fh-on-mount-trigger.patch Content-Type: text/x-patch; name=autofs-5.0.1-rc2-check-fh-on-mount-trigger.patch; charset=utf-8 Content-Transfer-Encoding: 7bit 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); --=-H8Saj7u4y/F9lMJvtHnv Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --=-H8Saj7u4y/F9lMJvtHnv-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timo Wendt Subject: Re: autofs 5 not recognizing manual umounts properly Date: Thu, 16 Nov 2006 13:48:25 +0100 Message-ID: <16B02FD4-DC07-4D2D-AC2F-9DAEFA10D462@online.de> References: <10272992.2537671162323983680.JavaMail.servlet@kundenserver> <1162720118.13896.25.camel@localhost> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/mixed; boundary="===============8564587283663096083==" Return-path: In-Reply-To: <1162720118.13896.25.camel@localhost> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org To: Ian Kent Cc: autofs@linux.kernel.org --===============8564587283663096083== Content-Type: multipart/alternative; boundary=Apple-Mail-45-690511682 --Apple-Mail-45-690511682 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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 > > > > > --Apple-Mail-45-690511682 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

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:

=A0 =A0 =A0 = 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=3D5,mode=3D620)
/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

proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts = (rw,gid=3D5,mode=3D620)
/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

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=3D5,mode=3D620)
/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=A0
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