Subject: Re: LFS frailty vs. datestamping [Was Re: /dev/clock pseudodevice]
To: gabriel rosenkoetter <email@example.com>
From: Andrew Gillham <firstname.lastname@example.org>
Date: 07/30/2001 10:02:23
On Mon, Jul 30, 2001 at 02:28:43PM -0400, gabriel rosenkoetter wrote:
> Yes, but this is a bug that should be fixed, not a reason to leave
> LFS by the wayside (which Greywolf, not you, seemed to be suggesting).
But a serious stability bug IMHO. Anyway, I think LFS is very nice for
things like src or pkgsrc. The untar / rm -fr performance just blows FFS
Don't get me wrong, I like LFS, I just can't feel comfortable using it for
anything besides testing.
> Great. So don't fsck_lfs. ;^>
> (Seriously, you should not have to except in the case of hardware
> failure. The fact that you still do periodically is just a sign
> that we need to fix some stuff.)
Agreed, but it should work if I run it. Or it should very clearly spit out
a message that what it is doing is pointless and won't help. :)
> Hrm. Yes, that does seem wrong, and contrary to what newfs(8) says
> it will do. Perhaps file a PR?
I will test it again and file a PR on it.
> I don't remember what I read to make me think it, but when I started
> using LFS (which, I point out again, has NEVER caused me problems in
> regular use) it seemed pretty clear to me that it was experimental.
> Perhaps adding a comment to the GENERIC config file, especially on
> platforms with the boot block trouble, would be a good idea.
I think the "boot block trouble" is the least of the worries. The same
issue applies to RAIDFrame also. I'm totally fine with booting from a
small FFS partition, a floppy, the network, etc. Anyway, I'll keep testing
LFS, being aware of the limitations now.