This may never ever matter if you manage to avoid fdisk your whole life. But if you don’t pull that off, here’s the reminder: label your DragonFly slices with 108.
(Yes, I do in fact have a backlog of two months with DragonFly material. It’s been that constant.)
The callout_* API in DragonFly has been rewritten. This will only affect you if you are doing some very specific programming – but it will be intensely interesting if so. I mentioned it before, but don’t forget debugging.
I’m still playing catchup so it’s as of a few weeks ago, but the version 8 branch of gcc in DragonFly has been updated from 8.1 to 8.3, with backported fixes.
Related: gcc 5 is out.
Matthew Dillon’s committed some performance work for HAMMER2, dealing with write-clustering. I don’t have statistics to note, so here’s the commit message.
Matthew Dillon has committed two changes, both to DragonFly 5.4 and to DragonFly-current. His note to users@ explains the details. I don’t have a date for 5.4.2 being rolled out, but I expect soon.
This is the commit I should have linked to yesterday, and was reminded by an anonymous commenter: git: sys/vfs/fuse: Add initial FUSE support. It’s not complete, and so isn’t built by default; check the commit for details.
Tomohiro Kusumi has committed more work on FUSE support in DragonFly. I am not sure if this is more foundational work or if it makes a user-level difference. At least the commit notes are nice.
DragonFly now has ministat(1), imported from FreeBSD thanks to Aaron LI. Use it on the output from your next run of benchmarking tools.
time_t in DragonFly is now 48-bit. This won’t affect anything you do day-to-day, probably, but it’s neat to see the 9 million year timeframe.
The aforementioned HAMMER2 fix is now in 5.4. You can update using the normal make buildworld/make buildkernel process to get it in place. I plan to roll a 5.4.2 release this weekend.
It’s possible to have data corrupted on a HAMMER2 volume during a specific combination of a bulkfree operation and a lot of writing to disk. Matthew Dillon has a potential fix already. As he announced, it’s scheduled to go into 5.4 this weekend. It’s a rare bug, but if you want to check for it, look for CHECK FAIL entries in /var/log/messages.
And because every cloud has a silver lining: some not-yet-quantified performance improvements.
top(1) is no longer in DragonFly contrib/ directory, for a number of reasons. It’s still present in the system, of course, and I think needs to have someone re-add as a vendor branch – a relatively easy project for a volunteer, hint hint.
There’s some code changes for callout, where the actual lines of code that trigger it are stored in the callout structure. It’s a little thing, but it’s a big thing if you need it.
GCC 5.0 is no longer needed in DragonFly, so it’s not being built, and can be removed on your next ‘make upgrade’. As a bonus, buildworld is a little faster.
Thanks to Aaron LI, you can now (actually, since December) run ifconfig without involuntarily loading associated kernel modules, with the -n option. See his commit message for an example.
I’m finally cleaning out some things I never got to post when new: last October, the DragonFly installer gained the ability to ask for terminal type, when used over a serial cable. Thanks to Diederik de Groot for that one.
(A rare combination… but when you need it, you won’t have an alternative.)
A little thing: Matthew Dillon has made changes to vm_page_list_find2() which should improve performance in low-memory situations, though how much I don’t know. Mentioning it, cause every little bit helps – for knowledge and speed.
Because someone decided years and years ago that the CAM structures should be passed through to userland, smartctl, camcontrol, cdrecord, and some other tools will be broken in DragonFly-master for a few days. If you are on -stable (5.4) this won’t affect you.
Sepherosa Ziehau’s improvements to re(4), bringing it to Realtek’s 1.95 release, have been committed.
(Does Realtek have a public repo for this? A few minutes of Googling did not turn one up for me.)
The system call brk() in DragonFly has been replaced with sbrk(). It won’t affect you from an end-user perspective other than making sure you upgrade everything on the next release – but it is a system call change, so I’m noting it.