1577159431 M * Bertl_oO Guy-: timeout on network filesystem?
1577159442 M * Bertl_oO  off to bed now ... have a good one everyone!
1577159452 N * Bertl_oO Bertl_zZ
1577172856 J * Ghislain ~Ghislain@adsl1.aqueos.com
1577176116 J * fstd_ ~fstd@xdsl-87-79-83-217.nc.de
1577176586 Q * fstd Ping timeout: 480 seconds
1577180193 Q * Aiken Remote host closed the connection
1577184068 J * Aiken ~Aiken@b951.h.jbmb.net
1577185091 M * Ghislain hi there, have nice end of year holiday !
1577187130 M * Guy- Bertl_zZ: it's a tmpfs
1577187154 M * Guy- my hunch says it's some dentry cache eviction that takes too long
1577188446 Q * Aiken Remote host closed the connection
1577192924 Q * romster Remote host closed the connection
1577193615 J * romster ~romster@158.140.215.184
1577194222 N * Bertl_zZ Bertl
1577194225 M * Bertl  morning folks!
1577194234 M * Bertl Ghislain: you too!
1577194271 M * Bertl Guy-: well, there is a difference between 'taking too long' and 'being noticeable'
1577197561 M * Guy- Bertl: it's most frequently more or less exactly 5s when it takes long (4.99something, as above), which suggests some timeout
1577197568 M * Guy- I've also seen ~7s though
1577197575 M * Guy- and yes, merry Christmas :)
1577197672 M * Bertl that's what I mean, 5s+ for a tmpfs access is way too long
1577197693 M * Bertl does that happen on the host or in a guest?
1577197719 M * Bertl do you have swap enabled and is the swap space used?
1577197844 M * Guy- Bertl: it's on the host, when a client attempts to automount an nfs share
1577197853 M * Guy- no swap usage
1577197870 M * Bertl so it is network fs related then :)
1577197887 M * Guy- not _quite_
1577197897 M * Guy- I see this in the strace of rpc.mountd on the server
1577197921 M * Guy- and if I try to mkdir (also on the server) a directory whose name_to_handle_at() took long, that also takes long (still on the same tmpfs)
1577197932 M * Guy- I've seen mkdir take 2+s
1577197938 M * Guy- (but not 5, interestingly)
1577197972 M * Bertl well, handles are typically used for network filesystems not for local filesystems
1577198023 M * Ghislain thanks, fyi 4.9.207 compiles and boot
1577198062 M * Bertl Guy-: I presume some network mount or filesystem action is initiated which holds a lock for a specific directory or maybe even the filesystem
1577198088 M * Bertl this doesn't work out and then times out after a few seconds, releasing the lock
1577198200 M * Bertl the main question here is: why does it time out in the first place
1577198227 M * Guy- tbh I don't understand what's going on... when the client tries the mount, rpc.mountd picks a random(?) prefix of the directory name the client requestet and calls name_to_handle_at() on it
1577198271 M * Guy- e.g. the client tries to mount /srv/movies and rpc.mountd looks at /srv/movie or /srv/mov
1577198299 M * Guy- I worked around the slowness by creating all such prefix directories too, but I'd like to understand what's happening :)
1577198310 M * Guy- *requested
1577198342 M * Guy- the client requests the directory by following a symlink to a specific directory that exists, so it's not something like tab completion in the client's shell
1577198382 M * Guy- I'll try to obtain a backtrace with sysrq-t sometime
1577198430 M * Bertl why does the guest need autofs in the first place and what gets mounted if it succeeds?
1577198582 M * Guy- the client is not a guest, it's remote laptops -- the server just happens to run a vserver kernel
1577198616 M * Guy- I have no reason to suspect vserver involvement other than that I can't reproduce this with non-vserver boxes that all run much newer kernels
1577198620 M * Guy- (this is with 4.4.206)
1577198625 M * Bertl so the same setup would work with an unpatched kernel as well?
1577198644 M * Guy- this part would, yes -- but the vserver guests wouldn't :)
1577198657 M * Bertl if so, I'd strongly suggest to try that, with the same kernel version
1577198670 M * Guy- I'm fairly certain it would be equally slow
1577198702 M * Bertl then it isn't Linux-VServer related :)
1577198715 M * Guy- that's what I said :)
1577198739 M * Bertl okay, still my guess would be network timeout
1577198752 M * Bertl most likely a firewall issue
1577198773 M * Bertl i.e. some ports for some rpc/id mapping not open
1577198786 M * Bertl or maybe some necessary daemons not running
1577198845 M * Guy- but shouldn't I see something related to that when stracing rpc.mountd?
1577198877 M * Bertl rpc.mountd is only one part of network fs mounting
1577198895 M * Bertl and if it is a blocked packet, what do you expect to see?
1577198955 M * Guy- I'd expect to see that in dmesg (I log dropped packets), but reading name_to_handle_at(2) didn't give me the impression it would cause network activity
1577212110 J * Aiken ~Aiken@b951.h.jbmb.net
1577216734 J * Silas ~user@103.127.65.40
1577221988 Q * Hurga Quit: Verlassend
1577222117 J * Hurga ~hurga@000131c9.user.oftc.net
1577226644 Q * Silas Remote host closed the connection