On Wed, 2014-01-29 at 17:02 +0100, Donald Buczek wrote: > Hello, > > we are trying to switch from amd to autofs. After successfully testing > and rolling it out to the first several machines, from time to time we > get directories stuck with "Too many levels of symbolic links" on a path > which should be automounted via an indirect map. > > linux 3.8.13 > autofs 5.0.8 > > As an example, here is data from a system where the path /scratch/tmp is > stuck: > > http://www.molgen.mpg.de/~buczek/autofs-demo/ > > auto.master # master map > auto.scratch # indirect map for /scratch > autofs # from /etc/defaults > typescript # shows the problem and a bit of gdb dump of kernel > structures > typescript.l # same with line numbers for reference > gdb-macros # macros used in the gdb session > > From typescript.l , line 122ff it is clear, that /scratch/tmp is not > currently mounted. On the other hand, the gdb session finds the dentry > of /scratch/tmp which has d_flags 0x70080 (line 99,120). This is > DCACHE_MANAGE_TRANSIT+DCACHE_NEED_AUTOMOUNT+DCACHE_MOUNTED+DCACHE_RCUACCESS > with DCACHE_MOUNTED indicating that there should be something mounted > there(?). I think, this state is faulty and necessarily leads to ELOOP > during path walk. Probably the situation is known by the gurus here? Yes, I can see how DCACHE_MOUNTED being set would lead to ELOOP in this case. But, having been there before too, I couldn't see any way the DCACHE_MOUNTED would not be cleared on umount. Also, DCACHE_MOUNTED is only changed within the VFS and isn't changed very often. It can't see how a code path that should lead to one of those changes doesn't go there. I'll have another look ..... Ian -- To unsubscribe from this list: send the line "unsubscribe autofs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
