Re: stat shows stale info on autofs-managed mounts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 20/7/23 00:19, Robert Vasek wrote:
Dear autofs mailing list,

When stat()-ing mountpoints under autofs, the info it returns is
stale, and takes about 3min to for it to reflect up-to-date data after
it's changed. I suspect this is related to some caching and timeout
settings, but I'm having trouble finding the right config options to
set the refresh interval to something shorter. Is there a way to
configure this?

What I mean by stale info: in my setup, the mounts under autofs are
backed by a FUSE-based driver. If the driver process goes down (for
any reason; crashing, exiting without first unmounting, being
killed...), stat()-ing the mountpoint should normally fail with
ENOTCONN. I need to detect these situations and reconcile. When the
mounts are managed by autofs however, once the FUSE process is down,
it takes around 3min for it to go from returning the old stat info
until it gives me ENOTCONN.

It's necessary to understand what's happening to work out if there's

anything that can be done.

Without information about what's going on once the mount is mounted

by autofs then there's very little autofs can do other than check if

the mount should be expired and attempt to umount it if it thinks it

has timed out.

It sounds to me like the case you are describing is similar to the

mount becoming unresponsive such as like when an NFS server stops

responding. Mostly autofs doesn't know about situations like this

and if it tries to umount the mount it will often take a long time

to timeout when the mount isn't responsive. A lot of time has been

put into dealing with NFS mounts that become unresponsive and they

are still a problem at times.

To implement a server monitoring system is problematic too, for

example, how does autofs know how to check the fuse mounts here,

even that's not straight forward and could be different for

different file system types.


# automount --version

Linux automount version 5.1.7-36.el9

config dir: /etc/sysconfig
maps dir: /etc
modules dir: /usr/lib64/autofs

Compile options:

# uname -srvmpio
Linux 5.19.9-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Sep 15
09:49:52 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Contents of /etc/auto.master.d/eos.autofs map:
/eos /etc/auto.eos

Contents of /etc/auto.eos:
ams -fstype=eosx,fsname=ams  :eosxd
atlas -fstype=eosx,fsname=atlas  :eosxd
cms -fstype=eosx,fsname=cms  :eosxd
experiment -fstype=eosx,fsname=experiment  :eosxd
geant4 -fstype=eosx,fsname=geant4  :eosxd
lhcb -fstype=eosx,fsname=lhcb  :eosxd

The automount daemon is set to run with a timeout of 300 seconds.

# stat /eos/atlas
   File: /eos/atlas
   Size: 4096       Blocks: 8          IO Block: 4096   directory
Device: 100033h/1048627d Inode: 26193792    Links: 2
Access: (0700/drwx------)  Uid: (110701/ UNKNOWN)   Gid: ( 2763/ UNKNOWN)
Access: 2023-07-11 15:29:03.528901692 +0200
Modify: 2023-07-11 15:29:03.528901692 +0200
Change: 2023-07-11 15:29:03.528901692 +0200
  Birth: -

# kill <PID>

(stat keeps showing the same output)
(... ~3 minutes later ...)

# stat /eos/atlas
stat: cannot statx '/eos/atlas': Transport endpoint is not connected



[Index of Archives]     [Linux Filesystem Development]     [Linux Ext4]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux