Project

General

Profile

Actions

Bug #2402

open

rnode.r_lkserlock is stupid (NFS4)

Added by Arne Jansen about 10 years ago. Updated over 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
nfs - NFS server and client
Start date:
2012-03-13
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

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

starve.c (1.22 KB) starve.c Arne Jansen, 2012-03-13 08:50 AM
Actions #1

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.

Actions #2

Updated by Marcel Telka over 5 years ago

  • Category set to nfs - NFS server and client
Actions

Also available in: Atom PDF