Matthew Dillon’s made some improvements to Hammer’s read and write processes. To quantize this, he’s tested Hammer and UFS with blogbench and written up the results. The tl;dr summary: UFS performs well until the system cache runs out, and then it halts. Hammer has some overhead from saving all history, but doesn’t stop working under a much heavier load.
DragonFly’s size_t and ssize_t have been modified. This creates more exact warnings of 64-bit problems when building on 32-bit systems. It may cause trouble with pkgsrc, though, so it will be reverted before the release (on 32-bit) if needed.
Be careful if you’re running bleeding-edge DragonFly. A full buildworld is needed because of this.
I’ve got a number of little items, so more roundup:
- How much disruption happened in DragonFly after introducing a dynamic device system? Surprisingly, very little, as most of pkgsrc still builds. Thanks are due to Hasso Tepper for the corrective work.
- _why makes some very perceptive comments.
- Jordan Gordeev’s been working on the very difficult AMD64 port as part of his Summer of Code work. He says thanks for the help, and others reply in kind. Speaking of which, it’s possible to boot 64-bit DragonFly now, though it’s not production-ready.
I’ve always had trouble updating certain pkgsrc packages that happen to also form the basic tools for pkgsrc – pkg_install, bootstrap, etc. Hasso Tepper has very kindly written up a note describing how to update these packages with newer versions of pkgsrc.
The mpt(4) driver has been updated, thanks to Alexander Polakov. This is useful for anyone using LSI Logic hardware for fibre channel disks, for instance.
Vinum’s been changed to work with devfs, with the advantage that drive labels instead of device paths can now be used. There’s some caveats – read the message for details.
audio/cdparanoia, in pkgsrc, had a major update and now doesn’t work on DragonFly. Hasso Tepper could use a hand fixing it – any takers?
Dear universe, including DragonFly people: stop doing so much stuff. It’s hard to keep up.
- Git in One Hour, an O’Reilly webcast. You need to register (free) and so on, but what the heck. O’Reilly doesn’t show crap.
- Poul Henning-Kamp is suing to recover the cost of Vista on his Lenovo laptop. (He’s installing FreeBSD.) I hope it comes out in his favor, though it will have little legal effect here in the U.S. (via)
- I didn’t realize this until I chimed in on the mailing lists, but one of the best books about file systems is freely available as a PDF.
- Another benefit of Hammer: you can’t run out of inodes, nor is it possible to have too many hardlinks.
- Some notes on pf usage in DragonFly. I know some parts have been mentioned before, but it’s good to sum up.
The amount of swap space usable under DragonFly has gone to a theoretical max of 4 terabytes. The practical limit is probably around 512 gigabytes. As Matthew Dillon writes, this could be interesting when paired with SSDs.
As Hasso Tepper pointed out, having GCC 4.4 in DragonFly is unique to DragonFly. Systems like pkgsrc don’t work due to the changes in headers and etc. between gcc 4.2 and 4.4, and since no other BSD uses gcc 4.4, the fixes would all have to come from DragonFly (and be backward compatible). This is unlikely to change in the near term, since this newer version of gcc is being refused due to the V3 GNU Public License, not a technical issue. It’ll stay in DragonFly for now.
However, you can specifically exclude it and speed up buildworlds with the new NO_GCC44 option. It’s also possible to use NO_GCC34 in make.conf to keep the old version of gcc from building, for those who don’t like to wait.
I totally missed this, but Sascha Wildner reminded me: Alex Hornung now has commit access to DragonFly, due to all the devfs work he’s done.
Matthew Dillon provided a summary of the state of the dynamic device filesystem work, plus a note about the preliminary iSCSI work. He also brings up the notion that iSCSI would eventally allow booting off a drive no matter where it’s physically connected.
Any commits to DragonFly go to the commits@dragonflybsd.org mailing list. The subject format has been reduced to “git: “, branchname, and the first line of the commit message. Keep that in mind when constructing your commit messages, and if you have any filters based on subject line for your mail.
If you’re on DragonFly 2.3.1 or 2.3.2: I’ve uploaded a full pkgsrc build to avalon.dragonflybsd.org based on pkgsrc-2009Q2. It’s possible to use pkg_radd to automatically download and install packages for those systems. (and pkg_search will search the remote repository for you.)
If you’re on DragonFly 2.2.x, I’ve modified the pkg_radd target for that release so that when pkg_radd makes a request, it is redirected to the appropriate place on avalon.dragonflybsd.org instead of attempting (and potentially failing) to find a matching mirror.
I said close to the same thing as the above text on users@; the short form of all this is that pkg_radd should generally work for everyone. Tell me if that’s not your experience.
There’s some more explanations of how disk serial number support is working from Matthew Dillon, plus a warning that a full kernel/world rebuild is needed because of these changes.
If I’m reading it right, serial number support, combined with a dynamic /dev, makes it possible to identify a disk by serial number, assign a name to it, and then refer to that disk directly by name in places like /etc/fstab. Much, much easier than remembering /dev/ad0c or /dev/ad1a, and so on.
DevFS breaks vinum. Will it be fixed? Yes, hopefully very soon.
Preliminary serial number support for drive identification has been added to DragonFly, with /dev/serno listing the appropriate devices and numbers.
DevFS has been added. There’s some issues, each with a workaround. Please test, as it’s certain that a major change like this will cause new problems around video and sound. Once those are fixed, however, device management will be a lot easier.
I published a retention policy for pkgsrc packages. It works out to “current release and last release” for what will be kept as pkgsrc binaries that you can add with pkg_radd. If you need longer-term support, speak up, but I don’t think this will be a problem for anyone.
Want to bring Hammer to Slackware Linux? People want it, and there’s some work already in progress.