Subject: Re: LFS frailty vs. datestamping [Was Re: /dev/clock pseudodevice]
To: Greywolf <firstname.lastname@example.org>
From: gabriel rosenkoetter <email@example.com>
Date: 07/29/2001 11:53:10
On Sat, Jul 28, 2001 at 04:28:04PM -0700, Greywolf wrote:
> ...with all I've been hearing about LFS and seeing the headaches
> concerning it (rearranging the order of data on disk, having a cleanerd,
> and now the above), I posit that LFS is a horribly fragile filesystem
Do you have any comprehension of why we *have* LFS to begin with?
It is a huge win over FFS and even more over "journaling" file systems (which
must write in two separate places on disk with each write) in write
speed (with read speed no slower than standard FFS). It does what it
is supposed to do, and it does it quite well, thanks. (My private
CVS repository has lived on an LFS partition on an UltraFast SCSI
disk on a macppc machine quite contentedly for over two years now,
and it's definitely more responsive than other machines on the same
network connection when I do large commits.)
It provides the same thing as journaling file systems claim to (as
near as I understand it, quick reboots through the lack of a need to
fsck), and it does it without the speed hit that they imply... and
yields a speed *gain* over FFS.
Sure, it moves blocks around. So what. Don't use it as your boot
disk. You shouldn't be using RAID as your boot disk either, but you
sure as hell should be using RAID in certain applications.
Alternately, hack either of these file systems to ignore the first X
blocks of a disk and put your boot block there. But rather than
bitching, how 'bout some code?
~ g r @ eclipsed.net