Subject: Re: Nightmare File Corruptions with 1.6Q - FFS?
To: Jaromir Dolecek <firstname.lastname@example.org>
From: Greywolf <email@example.com>
Date: 04/12/2003 01:15:04
Thus spake Jaromir Dolecek ("JD> ") sometime Today...
JD> Date: Sat, 12 Apr 2003 09:46:05 +0200 (CEST)
JD> From: Jaromir Dolecek <firstname.lastname@example.org>
JD> To: Greywolf <email@example.com>
JD> Cc: Simon Burge <firstname.lastname@example.org>, email@example.com
JD> Subject: Re: Nightmare File Corruptions with 1.6Q - FFS?
JD> Greywolf wrote:
JD> > That's a pretty lax call; I'd say that anything which affects kernel
JD> > structures changing AT ALL, let alone on a significant level such as,
JD> > oh, say, FILE SYSTEM STRUCTURE CHANGES, warrants a kernel indicator.
JD> It does not affect general kernel structures. It affects code
JD> for one file system, in that fs specific code. Would we bump kernel
JD> version whenever random filesystem gets improved significantly?
JD> We did not for LFS, and there is no reason to do for FFS/UFSv2, IMHO.
Yes, but I think you're missing the point that ffs is *the primary
filesystem type* for NetBSD. LFS is still "Experimental".
You're comparing apples and crabapples, here.
JD> Very bad thing is that it very difficult to find out when exactly
JD> the problem happens. Apparently most systems aren't affected at all.
Then tag it when a change is made.
Most systems are probably not affected because most people were afraid
of exactly what's happening to the few, the proud, the silly who
ate the upgrade.
Mind you, I'm well aware of the -current mantra ("...it may not run
(correctly) or even compile on any given day.").
NetBSD: the second best thing you can get for free.