Subject: Re: Nightmare File Corruptions with 1.6Q - FFS?
To: Greywolf <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 04/12/2003 14:02:57
On Sat, 12 Apr 2003, Greywolf wrote:
> 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.
But that's not what kernel versions have been for. They aren't for feature
bumps, etc. They are for LKM compatability. Since adding UFS2 didn't
change how well LKMs do or don't hook into the kernel, there was no need
to bump the version.
Adding a tag might have been good, but since the code had survived a few
weeks of hard testing from Frank, I can see that there didn't seem to be