Subject: Re: LFS frailty vs. datestamping [Was Re: /dev/clock pseudodevice]
To: Greywolf <email@example.com>
From: gabriel rosenkoetter <firstname.lastname@example.org>
Date: 07/30/2001 15:28:51
On Mon, Jul 30, 2001 at 12:13:27PM -0700, Greywolf wrote:
> Well, that one case is very important. If your machine goes down hard,
> you need to _be able to_ check the filesystem. Period.
Uh, that's not hardware failure, unless your power supply blew out.
That's exactly the situation in which a log-structured (meaning all
data) or journaled (which seems to have come to imply *only*
metadata) file system should never need to fsck. Because the newest
data is always written to the end of the disk, you're sure that
nothing is corrupt up till the last set of metadata.
Anything after that is chancy, but you can theoretically choose to
use fsck_lfs to roll forward into it. I've never done it (because
I've never had to, because even in power outtages my LFS partition
has never been corrupted), and maybe fsck_lfs can't, but that's
not the impression I had from Andrew's email. It sounded like he
was stressing the limits of the file system (by trying to fill it
all the way up; if you know how LFS works, you can see how that
might cause a problem, though LFS should be fixed to work around
it gracefully) and crapping it out as a result of that.
> 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.
No, I'm saying that any file system that uses the ufs layer needs to
get UBC for free. And it will. In 1.6.
~ g r @ eclipsed.net