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? That 'could'
be justified on the basis that the format of the metadata is outside
the control of file owner and depending on what's supported, included
or logged in metadata, the size could vary greatly -- all outside of the
direct control of the user. However, by adding extended attributes,
the user can, likely, affect the disk space used by the metadata
regardless of how it implemented and stored on disk -- so in that respect
it is user data. Similarly, system CPU time is attributed to the user
causing the CPU time to be spent, and so on.
To highlight the type of problems this can cause: starting after
Windows XP, MS decided to combine network file I/O requests over 64K to
be dispatched to the 'System' daemon to optimize network I/O from
multiple processes using bigger windows to try to keep the network pipe
as full as possible (competing, of course, with QOS for conforming
apps).
This created a problem -- applications that flood the network
sit mostly idle waiting for their rpc call to finish and all their
BW is attributed to System.
FWIW -- you cannot change any of the priorities for System
without it going all blue screen on you telling you that it's crashing
to protect you -- because something changed one of it's priority number
(IO/cpu/memory...etc).
Problem is that any intensive prioritizing slows everything down
and the entire computer becomes unresponsive (10Gb link) as network
requests are reduced in size. Usually it is possible to restore
normality by restarting Explorer (assuming you have enough cpu time to
do so). About 10% of the time, pulling the network cord is required to
stop the storm, and VERY rarely, <.01% of the time power-cycling is
required.
Attributing user-generated I/O to system processes that are "unaccountable" *can* and does cause DoS "opportunities"....
Is this metadata really I/O that is completely disconnected from
a user that they cannot affect?
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
