Subject: Re: LFS partition limitations
To: Tracy J. Di Marco White <email@example.com>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 10/03/2000 18:25:10
On Tue, Oct 03, 2000 at 11:15:56AM -0500, Tracy J. Di Marco White wrote:
> The idea was to have a central fileserver at home, I'm planning to keep
> NetBSD's source trees on it, as well as storing all our CDs in mp3 format,
> and basically anything else we find that we want to keep. Given our lack
> of anything to back up something that large in a reasonable amount of
> time (DLT/AIT is still a little pricey) we thought a journal/log based
> filesystem would be a good thing. We're planning to back up things that
> would be hard to replace, but the mp3s could be easily replicated from
> the CD collection (all it takes it time, after all), source trees can
> be grabbed again, etc. I convinced my husband NetBSD/LFS would be
> something to try with our new drives, the machine had been running
> Linux with ext2fs on the old 2GB drive. Generally we're not looking
> at stress testing LFS.
Why would a journal/log based filesystem be more reliable ?
From people working with True64 or irix, it's worse because Digital or SGI
doesn't provide a tool to repair the fs is something got really from.
At last with LFS we have a fsck. But I would still trust better ffs, even
when the known LFS bugs will be corrected.
Now I'm running LFS for a few filesystems, because its performances for
lots of small files is far better than FFS+softdep. It's good for
web caches and such (I also have my sources tree on it :)
Sure ext2fs is not a good choise but it's linux fault: as it's completely
async you can end up with a lot of things in lost+found after a crash; not
really easy to recover the original names. Also the 2G file size limit
is something annoying.
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr