Subject: Re: Progress meter for fsck, revisited
To: Jason Thorpe <firstname.lastname@example.org>
From: Nathan J. Williams <email@example.com>
Date: 01/13/2004 19:25:24
Jason Thorpe <firstname.lastname@example.org> writes:
> > .. and you're going to hold your breath until you turn blue, I see.
> I don't think it's worth over-complicating a cute feature that you
> have to choose to turn on. This is not enabled by default. If you
> want cute, you have to give up something. In my particular
> application, I need the cute, and the trade-off is completely
> acceptable. What's the problem?
It's of sufficently limited value that I don't think it's worth having
in the tree.
> > I think this change sucks. It's cute to have the progress-bar output,
> > but parallel fsck is sufficently useful for speed that it means the
> > progress bar can only be used in single-filesystem configurations,
> > which rules out many configurations. Why add the progress bar if it's
> > so completely limited?
> In the applications where I need them, there is typically only one
> (very large) file system, and the start-up scripts that handle this
> don't enable parallelism in any case.
That's nice, but it's decidedly a special case.
> Just because parallelism is disabled, doesn't mean you can't use it in
> multi-filesystem configurations! I don't know where on earth you got
> that idea.
You could, but you'd be giving up the performance benefits of the
parallelism, which are substantial. I think that running multiple
fsck's in series when they can run in parallel is downright
pathological and barely worth supporting.
> If NetBSD doesn't want the changes, fine. No skin off my back.
I don't think it does.