All of lore.kernel.org
 help / color / mirror / Atom feed
From: daedalus@pingtimeout.net
To: linux-nfs@vger.kernel.org
Subject: Regarding client fairness
Date: Wed, 28 Mar 2018 14:04:57 +0300	[thread overview]
Message-ID: <f9c6c1c493d0dde6c4a24afeca00fa5b@pingtimeout.net> (raw)

I came across a rather annoying issue where a single NFS client caused 
resource starvation for NFS server. The server has several storage pools 
which are used, in this particular case a single client did fairly large 
read requests and effectively ate all nfsd threads on the server and 
during that other clients were getting hardly any I/O through to the 
other storage pool which was completely idle.

I then proceeded to make a simple testcase and noticed that reading a 
file with large blocksize causes NFS server to read using multiple 
threads, effectively consuming all nfsd threads on the server and 
causing starvation to other clients regardless of the share/backing disk 
they were accessing.

In my testcase a simple (ridiculous) dd was able to effectively reserve 
the entire NFS server for itself:

# dd if=fgsfds bs=1000M count=10000 iflag=direct

Also several similar dd runs with blocksize of 100M caused the same 
effect. During those dd-runs the server was responding at a very slow 
rate to any other requests by other clients (or to other NFS shares on 
different disks on the server).

My question here is that are there any methods to ensure client fairness 
with Linux NFS and/or are there some best common practices to ensure 
something like that. I think it would be pretty awesome if clients had 
some kind of limit/fairness that would be scoped like {client, 
share-on-server} so client which accesses a single share on a server 
(with large read IO requests) would not effectively cause denial of 
service for the entire NFS server but rather only to the share it is 
accessing and at same time other clients accessing different/same share 
would get fair amount of access to the data.

             reply	other threads:[~2018-03-28 11:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-28 11:04 daedalus [this message]
2018-03-28 14:54 ` Regarding client fairness J. Bruce Fields
2018-03-28 14:59   ` J. Bruce Fields
2018-03-28 15:35     ` Antti Tönkyrä
2018-03-28 15:47       ` J. Bruce Fields
2018-03-28 15:58       ` J. Bruce Fields
2018-03-28 16:49         ` Antti Tönkyrä

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f9c6c1c493d0dde6c4a24afeca00fa5b@pingtimeout.net \
    --to=daedalus@pingtimeout.net \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.