--PGNNI9BzQDUtgA2J
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 05, 2001 at 10:52:33AM +0100, Bernd Sieker wrote:
> LFS is not recommended for vital partitions, (such as /usr),
> though. since it is still considered "beta". It may develop
> inconsistencies and you may even lose it entirely even in normal
> operation.

More importantly, you really don't want it for /usr since it'll
probably be slower than our current FFS for the usage model in /usr
(which is almost all reads, plus some mmap()s that may have to jump
around the disk more than they would under FFS if you ever update
some libraries without updating others).

LFS really shines in a file system you'll be *writing* to on a
regular basis. (Say, /usr/obj.)

> I have in the past had inconsistencies that led to a kernel panic just
> mounting the LFS. Sometimes read-only mounting allows to backup most
> of the contents. To get it usable again, fsck will not do, but the
> filesystem will sometimes have to be re-formatted.

I have never had problems with my LFS partition on a macppc machine,
which I use for a CVS repository. But I've also never gone to great
lengths to stress it. (Like, say, filling it up all the way, which,
though it is worked around in the code in -current, at least
conceptually makes lfs_cleanerd's life *extremely* hard.)

> Note that in fsck_lfs(8) it says under BUGS:
>=20
>   "fsck_lfs cannot currently [...] correct all of the errors it can detec=
t."
>=20
> And some of these errors might lead to kernel panics when trying to
> use the LFS.

Well, sure, but in theory fsck_lfs shouldn't be necessary. (That's
the point of a log.) I never fsck my LFS partition. But that machine
runs till the power dies as the result of a storm in the building
where it lives, which is usually about 120 days. But I've never had
bitching about inconsistencies.

> That said, for the two partitions I use it on, it has served me
> well. Unpacking source trees is an order of magnitude faster than even
> FFS with softdep. So is deleting source trees.

Well, sure it is, since softdep isn't much of a fix if you're going
to keep writing. I mean, that data has to go to disk eventually...
FFS+softdep is great for interactively-edited files, but there's not
much you can do to make FFS fast for prolonged writes. Kind of the
point of FFS is that it's pretty good at as much as it can be good
at without being outstanding at anything in particular.

> You mileage may vary.

Always true. But mine sounds a lot like yours, Bernd. :^>

--=20
gabriel rosenkoetter
gr@eclipsed.net

--PGNNI9BzQDUtgA2J
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (NetBSD)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjwQUpYACgkQ9ehacAz5CRoskQCcC5vUwh2egbLmoiyztkfUS1uL
gTMAoI0Q+LMM5LAo5H7lGC/qCSR+S0OW
=I5Gm
-----END PGP SIGNATURE-----

--PGNNI9BzQDUtgA2J--