Bug #2402
openrnode.r_lkserlock is stupid (NFS4)
0%
Description
Lock requests to a file hosted on nfs4 (and probably also nfs3) can slow down or completely starve writes to that file, as demonstrated in the attached "starve.c".
The problem is that nfs4_write wants a read lock on r_lkserlock, while nfs4_frlock holds a write lock to it while it calls the server. So every locking attempt slows down the writes. If there are sufficiently many processes trying to get the lock, the write() can completely starve, as the implementation of nfs_rw_enter_sig prefers writers over readers.
The problem can be alleviated when nfs4_write acquires an RW_WRITER. In this case, the write still gets slowed down massively, but at least it still makes progress.
For the fun of it: echo "nfs4_write+0x25e/v 0" | mdb -kw
Files
Updated by Gordon Ross about 10 years ago
Would be good to figure out why the NFS code is holding this lock here, while calling out for a remote lock. Usually, holding locks while calling a remote is a very bad idea.
Updated by Marcel Telka over 5 years ago
- Category set to nfs - NFS server and client