Subject: Re: LFS frailty vs. datestamping [Was Re: /dev/clock pseudodevice]
To: gabriel rosenkoetter <firstname.lastname@example.org>
From: Greywolf <email@example.com>
Date: 07/30/2001 12:13:27
On Mon, 30 Jul 2001, gabriel rosenkoetter wrote:
# Date: Mon, 30 Jul 2001 14:28:43 -0400
# From: gabriel rosenkoetter <firstname.lastname@example.org>
# To: Andrew Gillham <email@example.com>
# Cc: firstname.lastname@example.org
# Subject: Re: LFS frailty vs. datestamping [Was Re: /dev/clock
# 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
NetBSD: your basement or mine?