On Mon, 23 May 2005, Jeff Moyer wrote:
==> Regarding Re: [autofs] handle_packet_missing called with wrong path; [EMAIL
PROTECTED] adds:
raven> On Mon, 23 May 2005, Jeff Moyer wrote:
Hi, Ian, list,
I have a user reporting a problem with autofs whereby his automounts
fail for a period of time, and then start to work again. The map looks
like this:
soldyn2 -rsize=8192,wsize=8192 alexandria:/export/soldyn2 clouds2
-rsize=8192,wsize=8192 alexandria:/export/clouds2 waves2
-rsize=8192,wsize=8192 alexandria:/export/waves2 sw1
-rsize=8192,wsize=8192 alexandria:/export/data1 radar3
-rsize=8192,wsize=8192 alexandria:/export/radar3 bigmeadow
-rsize=8192,wsize=8192 alexandria:/export/bigmeadow
And here is a debug log trace that shows, when the problem occurs, that
the kernel passes on a missing packet with relative path of
radar3/saber:
automount[3488]: handle_packet: type = 0 automount[3488]:
handle_packet_missing: token 250, name radar3/saber automount[3488]:
attempting to mount entry /data/radar3/saber automount[14482]:
lookup(yp): looking up radar3/saber automount[14482]: ret = 8
automount[14482]: failed to mount /data/radar3/saber automount[14482]:
umount_multi: path=/data/radar3/saber incl=1
raven> I wish I new what caused this. I thought I'd sorted this out long
raven> ago but maybe it's a different problem.
raven> This can happen if the lookup doesn't think that, for some reason,
raven> radar3 is a mountpoint during the path walk. It is probably because
raven> the subdirs list for the radar3 dentry is not empty when it should
raven> be. Oddly enough this might not be due to directory create and
raven> removal. It might be that a dentry from a path lookup hasn't been
raven> cleaned up for some reason. Quite difficult to diagnose.
Found it.
This happens for browsable maps that request a mount at the same time as
an expire is happening. My understanding of the lookup was slightly
incorrect in that, when the directory exists the revalidate succeeds when
it should fail, in order to ensure that lookup is called. Instead lookup
is called on the next path component which should be whithin the mount.
Unfortuneately, the parent isn't mounted.
This patch seems to fix the problem.
diff -Nurp linux-2.6.12-rc5-mm1.orig/fs/autofs4/root.c
linux-2.6.12-rc5-mm1/fs/autofs4/root.c
--- linux-2.6.12-rc5-mm1.orig/fs/autofs4/root.c 2005-05-29 14:46:30.000000000
+0800
+++ linux-2.6.12-rc5-mm1/fs/autofs4/root.c 2005-05-29 14:47:04.000000000
+0800
@@ -306,7 +306,14 @@ static int try_to_fill_dentry(struct den
DPRINTK("expire done status=%d", status);
- return 0;
+ /*
+ * If the directory still exists the mount request must
+ * continue otherwise it can't be followed at the right
+ * time during the walk.
+ */
+ status = d_invalidate(dentry);
+ if (status != -EBUSY)
+ return 0;
}
DPRINTK("dentry=%p %.*s ino=%p",
_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs
