Subject: Re: Making FFS fsck faster
To: Courtney R. Spencer <cspencer@mindspring.com>
From: Greywolf <greywolf@starwolf.com>
List: current-users
Date: 04/19/2005 19:06:54
[Thus spake Courtney R. Spencer ("CRS: ") 7:48pm...]

CRS: fsck a default mounted / that is only 64 mb lately?

Every time I reboot.  Takes 2.5 seconds for a full fsck.

CRS: /usr and /var may be separate but you still need them
CRS: so you would not mount the dirty filesystems so you
CRS: still need to fsck them, regardless of your partitioning
CRS: scheme.

Well, yes, but putting 120G as a hold-everything root partition
borders between folly and insanity.  I'm sure there's a middle ground
here...

CRS: It still takes a lot of relative time even with only 64 mb and
CRS: using a small / partition caused me many headaches that had to
CRS: be semi-fixed with either null mounts for mfs based /tmp
CRS: depending on the system build.

Well, depending on your system, sure.

CRS: Oh yeah, some of these systems are running on alpha with scsi
CRS: disks and the fsck performance is no better than an x86 box
CRS: with ide.

No, in fact, I'd posit they were worse.

CRS: The alphas have 9 gig disks and the PC had a 20 gig
CRS: disc. So I, for one, am interested in the original question
CRS: about lfs and snapshot scripts since partitioning schemes
CRS: only take you so far and still result in hair loss.

(ponders...) yyyyeah, I think I see your point on that one, although
I don't seem to have too many problems on a sparc with a 9G and a
2G disk, other than the fact that I can't host home dirs AND /usr/src
on such a setup.

I was only offering up one potential solution.  I'm sure something about
lfs or some other quick-come-up solution would work equally well.

<opinion>
I'm not really willing to consider LFS, though, until it can run at
near capacity without problems; otherwise you're only wasting space
and begging the question of how useful LFS could really be.

And "small root" need not be as small as it once was -- I used to be
able to run it at 32MB with one kernel onboard.  Lately (as in,
"within the last five years"), I find 64MB to be the smallest I can
deal with and comfortably store several kernels "just in case".  With
the speed of disks these days (and I'm going to go against one of my
major principles here), 96M or 128M for a root partition would be
acceptable.

It's been argued that / and /usr should be co-mounted.  I can't really
take a side on that based on technical merit; my preference is one of
conditioning (I still keep them on separate spindles).

/var should be separate just because it's a bad idea, security-wise,
to have anyplace writable by which one can hard-link to system binaries,
libraries, devices...but then I think like a server admin, even on
my own desktop.

/usr should probably NOT play host directly to X11 or pkg or src or
pkgsrc.  Ideally they'd have their own playgrounds, as would /home
or /export/home or whatever.
</opinion>



				--*greywolf;
--
Friends don't let friends use System V.