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