Another Google Code-In project arrives: libfsid. It’s used to get the volume label for a given file system. (see man page) It makes me happy to see more Google Code-In projects coming to fruition and getting committed – suggest more, if you have them!
As part of the ongoing work to support a lot of CPUs, Matthew Dillon has made some changes that have the side effect of benefiting virtual kernels. How much? I don’t have a benchmark, yet.
Peter Avalos has updated OpenSSL to 1.0.0c, to fix a recent security problem. The problem doesn’t sound too catastrophic to my untrained ear, at least.
Matthew Dillon has moved CPU support to 63 processors and 512G of RAM. This may cause issues, he warns. It’s also just barely working, so don’t expect to go into production with half a terabyte of RAM in the next few days.
Matthew Dillon has made it possible to boot DragonFly on 24-CPU systems. Also, we’re currently limited to 32G of RAM. Oh, to have such limitations; I was considering myself lucky to have 4 CPUs.
There’s now descriptions for a number of the net.inet.* sysctls, thanks to Taras Klaskovsky as part of Google Code-In.
Another Google Code-In task completed: passwords are now created using SHA256 (PDF link) by default, and libcrypt also now supports SHA512.
Alex Hornung has added the basic work for dmirror, a software RAID-1 implementation into the tree, along with a concept description from Matthew Dillon. It’s not ready for use yet; ready for development, though.
APIC_IO is back as a kernel config option, though it just toggles the sysctl loader tunable default. This is so a kernel config file with that option still set won’t cause an error.
Peter Avalos has committed his speedups for OpenSSL encryption (using assembly), along with a lot of numbers to show performance changes. It’s definitely sped up, but the quantity of values is so large that you’d have to visualize it differently to get a summary I could show here.
Peter Avalos is bringing in OpenSSL 1.0.0b. I’m not sure what the difference between 1.0.0b and 1.0.1 would be. Also, Alex Hornung has updated vn(4) – there’s more updates than the one I linked.
Ilya Dryomov’s work on deduplication for Hammer has been committed to the tree in an early test form. I guess I need to pay up as part of the code bounty. If you’re wondering how much space it will save, but don’t want to try non-production code yet, there’s a ‘hammer dedup-simulate’ command that will estimate the saving ratio.
This is great news – deduplication is so valuable it adds an extra zero onto the price of any storage device that can do it.
DragonFly has shipped with a uniprocessor kernel by default forever. Shipping with a SMP kernel may not work as well for all possible combinations. With some recent changes by Matthew Dillon, both types of kernel are present and can be picked from at boot time – with the LiveCD!
Venkatesh Srinivas has a large writeup describing just how the memory allocator in DragonFly changed from 2.6 to the upcoming 2.8 version. In all that text, you may notice the cheering statistic that it gave a 20% improvement in sysbench results.
Rumko came up with some changes for vkernel(7) that, among other things, made it possible to run them diskless; almost like booting a thin workstation.
OpenSSL on DragonFly can now dynamically load engines (cryptographic support modules) at runtime, thanks to Peter Avalos.
Matt Dillon and Venkatesh Srinivas conspired to fix another nmalloc issue, which should resolve any remaining problems people were having with Firefox, and possibly other applications as well. Due to an oversight of sorts, all locking operations on nmalloc’s depot were ineffective, as if there were no locking at all. Curiously, it worked remarkably well considering such a large race condition was present.
Here’s something: Pratyush Kshirsagar came along, saw the proportional RSS project idea, and did it. It’s nice to have a completed project just sort of fall out of the sky.
I’m linking to this commit message from Matthias Schmidt simply because it has the correct invocation for installing a vkernel, and I know this will come in handy, someday.