From: Dave Chinner <david@fromorbit.com>
To: "L.A. Walsh" <xfs@tlinx.org>
Cc: xfs@oss.sgi.com
Subject: Re: I/O 'owner' DoS probs (was Re: Does XFS support cgroup writeback limiting?)
Date: Wed, 2 Dec 2015 07:18:08 +1100 [thread overview]
Message-ID: <20151201201808.GU19199@dastard> (raw)
In-Reply-To: <565D7E03.20008@tlinx.org>
On Tue, Dec 01, 2015 at 03:01:23AM -0800, L.A. Walsh wrote:
>
>
> Dave Chinner wrote:
> >Metadata IO not throttled - it is owned by the filesystem and hence
> >root cgroup.
> ----
> Please forgive me if this is "obvious"....
>
> If it is owned by the file system, then logically, such meta
> data wouldn't count against the user's quota limits?
Filesystem space usage accounting is not the same thing. It's just
accounting, and has nothign to do with how the metadata is dependent
on the transaction subsystem, caching, locking, parent/child
relationships with other metadata in the filesystem, etc.
> Is this metadata really I/O that is completely disconnected from
> a user that they cannot affect?
throttling metadata IO - read or write - can lead to entire
filesystem stalls/deadlocks. e.g. transaction reservation cannot
complete because the inode that pins the tail of the log is blocked
from being written due to the process that needs to write it being
throttled by the IO controller. Hence every transaction in the
filesytem stalls until the IO controller allows the critical
metadata IO to be dispatched and completed...
Or, alternatively, a process is trying to allocate a block, and
holds an AG locked. It then tries to read a btree block, which is
throttled and blocked for some time. Any other allocation that needs
to take place in that AG is now blocked until the first allocation
is completed.
i.e. the moment we start throttling global metadata IO based on
per-process/cgroup limits, we end up with priority inversions and
partial/complete fs stalls all over the place. You can educate/ban
stupid users, but we can't easily iprevent stalls due to
IO level priority inversions we have no control over at the
filesystem level...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2015-12-01 20:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-23 11:05 Does XFS support cgroup writeback limiting? Lutz Vieweg
2015-11-23 20:26 ` Dave Chinner
2015-11-23 22:08 ` Lutz Vieweg
2015-11-23 23:20 ` Dave Chinner
2015-11-25 18:28 ` Lutz Vieweg
2015-11-25 21:35 ` Dave Chinner
2015-11-29 21:41 ` Lutz Vieweg
2015-11-30 23:44 ` Dave Chinner
2015-12-01 8:38 ` automatic testing of cgroup writeback limiting (was: Re: Does XFS support cgroup writeback limiting?) Martin Steigerwald
2015-12-01 16:38 ` Tejun Heo
2015-12-03 0:18 ` automatic testing of cgroup writeback limiting Lutz Vieweg
2015-12-03 15:38 ` Tejun Heo
2015-12-01 11:01 ` I/O 'owner' DoS probs (was Re: Does XFS support cgroup writeback limiting?) L.A. Walsh
2015-12-01 20:18 ` Dave Chinner [this message]
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=20151201201808.GU19199@dastard \
--to=david@fromorbit.com \
--cc=xfs@oss.sgi.com \
--cc=xfs@tlinx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox