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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
