Release engineering for 2.2 coming up - UPDATE1
dillon at apollo.backplane.com
Fri Jan 30 22:13:00 PST 2009
We are still working on a few installer and nrelease build issues. I
hope to be able to branch 2.2 this weekend or early next week, and the
actual release will occur about 2 weeks after we branch.
We are going to have a mini-freeze of the current development branch
during the release engineering cycle this time to make it easier to
merge work into the release branch.
The 2.2 release cycle will feature our conversion over to the GIT
source control system, with git support binaries included on the CD
(built from pkgsrc of course), and the release of a new DVD ISO image
containing all sorts of pre-built packages in addition to the
bare-bones CD ISO that we always release.
A great deal of work has gone into this release, I haven't organized
a list yet but the high points include many bug fixes, scheduler
improvements, network driver and protocol improvements, more wireless
work, improved SATA support, improved pkgsrc compatibility,
a very stable HAMMER filesystem, and many other things.
HAMMER will be very stable in the 2.2 release and the installer will
have a HAMMER option for new installations. HAMMER has been running
in production on several heavily-used dragonfly boxes since around last
July with no media corruption. Heavier and heavier testing regimens
are being used to squeeze out remaining bugs. Currently there are
two known bugs remaining of which one will be fixed for this release.
The last bug is a very rare assertion in the B-Tree code which has
not yet been tracked down. None of the bugs found since the 2.0
release corrupt the media.
I had a bit of writer's block and didn't finish the hammer fsck
utility. I really wanted to get it done but certain worldwide events
have been eating a lot of my time since October, and will continue to
do so for the next few months. The work load should trail off as time
progresses and I hope to have the hammer fsck utility done in the first
half of this year.
There is also a minor performance issue with very large directory
scans which I originally thought was due to the way the directory
hash worked, and I had hoped to fix it for this release. The problem
turns out to be more complex, related not so much to the directory
hash but instead to a lack of correlation between the directory scan
order and inode numbers which cause extra I/O's due to reduced locality
of reference. Simon and I are running through some ideas on how to
improve it for 2.4.
<dillon at backplane.com>
More information about the Users