Subject: Re: LFS frailty vs. datestamping [Was Re: /dev/clock pseudodevice]
To: Jason R Thorpe , Greywolf <firstname.lastname@example.org>
From: Andrew Gillham <email@example.com>
Date: 07/30/2001 08:21:26
On Mon, Jul 30, 2001 at 09:27:42AM -0700, Jason R Thorpe wrote:
> On Mon, Jul 30, 2001 at 12:21:38AM -0700, Greywolf wrote:
> > It causes problems with bootblocks.
> It causes problems with bootblocks on SOME platforms. Not all. And
> on the platforms for which it is a problem, chances are this could be
> fixed with a little effort.
Filling up the partition causes me problems on i386 & Alpha. So while the
i386 port may lack "modern" bootblocks, it certainly suffers from the
same LFS issues as Alpha.
FWIW, I somewhat agree with Greywolf that LFS is fragile. Perhaps not for
the same reasons though.
1. Filling up the partition (attempting to anyway) causes bad
things to happen. Either kernel panics, or just going catatonic.
(a tar process can sit for hours without getting an error returned)
2. The current fsck_lfs can't fix anything, requiring me to newfs_lfs.
3. Not UBC'ified yet. This means things that now expect mmap() to be
coherent (which it is on FFS) don't work when moved to LFS.
Sort of unrelated:
4. I have occasionally typed "newfs" rather than "newfs_lfs" and newfs
happily changes the partition type to 4.2BSD and creates an FFS
file system. This seems wrong, :)
I would still consider LFS experimental, and as such, some issues are to be
expected. It needs to be clearly marked as experimental also.