Subject: Re: lfs
To: Konrad Schroder <email@example.com>
From: Thor Lancelot Simon <firstname.lastname@example.org>
Date: 02/27/2003 14:01:20
On Thu, Feb 27, 2003 at 10:46:05AM -0800, Konrad Schroder wrote:
> On Thu, 27 Feb 2003, Thor Lancelot Simon wrote:
> > I don't understand this. How can we have demand for 20% of the segments
> > in the filesystem, even if there is simultaneous cleaning and user I/O
> > going on? How can we require 20% "slop" in order to avoid deadlock? The
> > Sprite code, IIRC, reserved two segments, and noted that reserving one
> > should theoretically be sufficient.
> In theory, yes, one reserved segment should be sufficient. We have some
> problems that I don't know if Sprite had (apparently not).
> If we get really short on available space, the cleaner has to run through
> the entire filesystem moving the files all around. This in itself is not
> a problem, but it means that ~every file will be moved, which means that
> the cleaner will at some point load each of their vnodes. If there are
> many files, this means that we will run out of vnodes at some point and
> have to flush all the writes that are blocked awaiting the cleaner anyway.
> Voila, no clean segments. This is not an insoluble problem, just a little
Hm. When this happens, are we trying to clean one segment at a time, or
is the cleaner scanning for multiple segments to clean, reading vnodes and
thus potentially causing writes?
It seems to me that it might be reasonable, in the name of avoiding
deadlock, to allow the cleaner to simply increase maxvnodes if it
condition occurs. Or to relate the amount of space reserved for the
cleaner to both number of inodes in the filesystem and number of dirty
vnodes in the cache?