If you are running DragonFly-master (i.e. 4.5), and you have a system between these two updates (roughly between November 27th and now), please rebuild your kernel to avoid a TCP bug.
DragonFly has historically performed very well with NFS. I don’t have hard numbers to point at (an interesting exercise if someone wanted it), but in any case: DragonFly now can tune up to a much larger iosize, which means better NFS performance. DragonFly <-> DragonFly NFS performance can now max out a GigE link, or with anything else that can handle the larger iosize. That plus additional readahead, also in that commit, means easier netboots.
I have a huge backlog of things to post, so this is originating from the 17th: Matthew Dillon has been working for some time on hardlinks and Hammer 2. Hardlinks are the same file, presented in multiple places. This can be a problem when your filesystem keeps infinite, writable snapshots. The solution he just commited is called ‘xlink’ and the commit message has details.
Since DragonFly 4.4 has been branched, bleeding-edge DragonFly is now at version 4.5. As John Marino detailed in his post, that means pkg on 4.5 systems will look in a new place for downloads. (“dragonfly:4.6:x86:64”, since it always uses even numbers) To cover for this, set ABI to point at DragonFly 4.4 packages in pkg.conf for now. They’re freshly built and functionally the same, anyway. Once there’s a 4.6 download path, that ABI setting can be removed. Packages for DragonFly-current are available now and probably at the mirrors by the time this posts.
Update: as John Marino pointed out to me, anyone on DragonFly-master who upgrades now will be at version 4.5. This means pkg will get the new (4.5) packages on the next pkg upgrade. That means a mix of old and new packages unless you either reinstall anything (pkg update -f) or hardcode the 4.4 download path until you are ready to switch everything.
So: DragonFly-current users should either hardcode the 4.4 path for now or force an pkg upgrade for everything. DragonFly 4.2-release users are unaffected.
Did you need to use SLIP on DragonFly? Do you remember what SLIP is? Well, it’ll work with a USB modem on DragonFly, even if you are making a face right now and saying, “SLIP? Who uses that?”
The default linker in DragonFly has been switched to gold, the newer version of ld. (get it, go-ld?) It’s faster, cleaner, going by the commit message. It’s possible to switch back to the old one if needed. This predates the recent branch for 4.4, so it will be default in the release, too.
The next release of DragonFly is coming due, since it’s been 6 months. I just tagged 4.4RC, and I’ll have an image built soon. Current estimate is that we’ll have the 4.4-RELEASE at the end of the month.
Imre Vadász fixed top so that hitting ‘c’ filters displayed processes by command name. I am mentioning this not because it’s a huge change, but because I forget about all the interactive elements that are possible with top.
Does that count as alliteration? Anyway, Matthew Dillon has increased the size of the starting window in TCP. If you are on a higher-latency link and/or fetching lots of small files, you should notice better performance.
If you are on bleeding-edge DragonFly (4.3), you will need to rebuild both kernel and world to keep them in sync, after Sepherosa Ziehau’s commit. This won’t affect you at all if you are on 4.2.x.
I don’t think I linked to this anywhere else: Why did I choose the DragonFlyBSD Operating System? By Siju George, at BSD Magazine.
The disk scheduler apparatus in DragonFly has been removed. This may not affect you much, since alternate scheduling setups were never utilized much with it. It may fix some rare Hammer cleanup issues, though, and you may need to adjust your custom kernel config, if you have one.
John Marino sent a helpful link to show the cross-platform work he’s been involved in: He brought the locale work from Illumos into DragonFly over the summer (look for his name on commits), and now it has been brought from DragonFly into FreeBSD, with Baptiste Daroussin reporting on the process. If there’s any OpenBSD/NetBSD developers reading, with an interest in locales, this may be useful..
(someone correct me if that’s not the right Illumos link)
If you are using bleeding-edge DragonFly (4.3) on a machine with Intel video, the i915 module has been renamed. This means you will probably need to rebuild xf86-video-intel from source to have it match. There should be a matching binary package soon.
If you are on DragonFly 4.2, this does not affect you.
Sascha Wildner has brought over support for the Realtek 8168H. This may be useful because at least one low-cost server provider – Kimsufi, I think? – uses them by default in their product line.
If you are using clang with DragonFly, and you want to always run the newest version, you can set options in compilers.conf, and use ‘clangnext‘.
If for some reason you are seeing messages about your CPU overheating – and you know it is not, there’s a solution. Disable coretemp messages.
Note that if your CPU is actually overheating, turning these messages off won’t help. Don’t want anyone to be surprised when their computer melts…