Subject: Re: LFS frailty vs. datestamping [Was Re: /dev/clock pseudodevice]
To: Andrew Gillham <firstname.lastname@example.org>
From: gabriel rosenkoetter <email@example.com>
Date: 07/30/2001 14:28:43
On Mon, Jul 30, 2001 at 08:21:26AM -0700, Andrew Gillham wrote:
> 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)
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).
> 2. The current fsck_lfs can't fix anything, requiring me to newfs_lfs.
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.)
> 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.
Same answer as 1. Shouldn the UBC stuff live in ufs anyhow?
> 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, :)
Hrm. Yes, that does seem wrong, and contrary to what newfs(8) says
it will do. Perhaps file a PR?
> I would still consider LFS experimental, and as such, some issues are to be
> expected. It needs to be clearly marked as experimental also.
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.
~ g r @ eclipsed.net