Bug#837907: stat() hangs on a particular file
Sergio Gelato <Sergio.Gelato@astro.su.se> writes:
Package: linux-image-3.16.0-4-amd64
Version: 3.16.36-1+deb8u1
One of our systems is suddenly unable to stat() a particular file
(cookies.sqlite-wal in a user's Firefox profile). Any attempt to
^^^^^^^^^^^^^^^^^^
do so hangs in the system call, as shown by strace. The file resides
on an NFSv4 share (sec=krb5p). Other files in the same directory on
the same share remain accessible. The affected file is normally accessible
on the NFS server and from other NFS clients running the same kernel.
(This does not invalidate this bug report [looks like genuine kernel {or
hardware} issue]), but sqlite3 does NOT support placing databases on any
networked filesystem (NFS, samba/cifs, etc); this may easily result in
database corruption or other locking issues (inconsistent data reported
by concurrent database connections); and as WAL mode uses mmap, it can
be even more problematic on NFS.
So, it is very bad idea to place firefox/thunderbird profile
directories on NFS.
See
https://www.sqlite.org/howtocorrupt.html#_filesystems_with_broken_or_missing_lock_implementations
(but, again, this is *user-level* issue [non-working locks can result in
database corruption], and your bug is about *kernel-level* issue [hangs
on stat(), which is not supposed to be possible to trigger by any
user-level craziness]).
The user has reported a similar incident yesterday on some directories
on a different NFS share (also sec=krb5p, but hosted on a different
server). He rebooted to clear up the problem.
Reply to: