On Mon, 30 Jul 2001, gabriel rosenkoetter wrote:

# Date: Mon, 30 Jul 2001 14:28:43 -0400
# From: gabriel rosenkoetter <gr@eclipsed.net>
# To: Andrew Gillham <gillham@vaultron.com>
# Cc: tech-kern@netbsd.org
# Subject: Re: LFS frailty vs. datestamping [Was Re: /dev/clock
#     pseudodevice]
#
# 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).

I hadn't meant to suggest it -- I'm all for improvements, and I hadn't
meant to kvetch.  I was observing, was all...

# >     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.)

Well, that one case is very important.  If your machine goes down hard,
you need to _be able to_ check the filesystem.  Period.

# >     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?

That's a hard problem.  Dynamically-linked executables rather depend on
mmap(); are you suggesting that LFS not be used for anything except
data?  That seems kind of absurd.

# >     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?

See my previous reply on this one.

# > 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.

It used to be marked as such.  It ought to be again.

#        ~ g r @ eclipsed.net

				--*greywolf;
--
NetBSD: your basement or mine?