Jason Thorpe <thorpej@wasabisystems.com> 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.

        - Nathan