> On Tuesday, May 20, 2003, at 17:52 Europe/Rome, Bill Studenmund wrote:
> > If fsck has any algorithms that go faster than O(n), one bigger
> > partition
> s/faster/slower/ ... or "whose complexity grows faster than...", then I
> understand it :)
>
> > will take longer than two smaller ones. fsck used to have O(n^3)
> > algorithms in it. ISTR Charles fixed a number of them.
>
> I have no idea about the internals of fsck, but I can't conceptually
> see reasons why it cannot be made run linear or, at worse,
> O(N lg N): and even with N lg N would not make a *concrete*
> difference splitting the filesystem in smaller pieces.

the explanation is that seeks are shorter and faster in smaller
partitions.

anyway NetBSD is not windows and doesn't crash every day, so 5-10 minutes
more fsck doesn't matter. at least for me.

I did lot of small partitions in DOS times (large partition=wasting of
space) and i hated this (i have 20MB on E, 30MB of F and 5MB on C and i
have to store 40MB file).

I'm doing one partition+swap scheme since i used unix first time! no
problems.