quota deadlock on 6.1-RC1
Robert Watson
rwatson at FreeBSD.org
Fri May 5 19:52:16 UTC 2006
On Fri, 5 May 2006, Paul Allen wrote:
> One detail of this has to do with version numbering. The FreeBSD version
> number says a lot more about the userland than it does about the kernel per
> se.
>
> If we were to version the kernel arch, I think it would look more like this:
>
> '94 1.1.5.1 (Last Net/2) Version 0
> Nov '94 2.0.5 (First unencumbered release)
> Aug '96 2.1.5
> Nov '96 2.2 Version 1
> Oct '98 3.0 Major VM changes... Version 2
> Mar '00 4.0 refinement of 3.x
> Jan '03 5.0 Major SMP changes Version 3
> Jul '05 6.0 refinement of 5.x
> ??? 7.0 refinement of 5.x,6.x
One of the "problems" we've had in the last ten years was the piling on of
features during the 5.x release cycle. Because two very large development
projects were going on simultaneously (KSE, SMPng), at the same time as the
dotcom bubble burst, greatly reducing various companies commitments of staff
resources to FreeBSD, the brach for 5-STABLE kept getting deferred. For
better, or sometimes worse, new features kept getting added to avoid stalling
all development while SMPng and KSE stabilized. These new features kept
deferring the branch date, of course :-). I think there is universal
recognition that while the features in FreeBSD 5.x were really great,
trickling them in over a longer period of time, and avoiding the steep
stability surves for them happening simultaneously, would have been better (in
retrospect).
The reason we're now trying to move onto a fixed schedule release cycle is to
try and limit that: instead of saying "Yes, we can defer the release for new
feature <x>", we instead say, "We can't add feature <x> because there isn't
time for it to stabilize before the release". By being a little less feature
agressive in the short term, we can increase stability, and in fact improve
feature delivery in the long term. So there are a variety of new features in
the pipeline for 7.x, but we've actually been focussing almost exclusively on
stability and performance so far.
So what to expect in the future? A slightly less agressive feature schedule
for major releases -- 5.x had UFS2, KSE, SMPng, TrustedBSD, OpenPAM, a new
gcc, etc. 6.x had significant network stack refinements, VFS SMPng work, etc,
but nothing like the feature list of 5.x. The main distinguishing factor for
7.x right now is Audit, which while a good bullet feature, but relatively
non-intrusive. I'd expect to see further UFS and VFS work, etc, possibly
including a move to UFS journalling from the bgfsck model, a Giant-free NFS
client, further refinement of locking in the storage stack, ARM support, and
so on. But by driving feature integration by schedule, things should go more
smoothly. For example, Audit is in 7.x -- we wanted to merge it for 6.1, but
decided that the 6.1 schedule simply didn't allow it, so it will likely appear
in 6.2 and 7.0. That's a lot better than merging it prematurely, deferring
the release 6 months for it to stabilize, and shipping it prematurely anyway.
Robert N M Watson
More information about the freebsd-stable
mailing list