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