As part of a larger conversation about security measures, NX bit capability was added to DragonFly. You can turn it on or off, and it’s off by default so it doesn’t cause any surprises. As the first link in this post points out, your installed third-party software is more of a security issue than processor features, in any case.
In my ongoing quest to actually catch up to all the DragonFly commits recently, here’s a recent update to machdep.cpu_idle_hlt. Set this to affect power usage. I’m linking to this list of the different settings because, like RAID levels, nobody can or should remember every one.
Continuing my catchup on recent commits, there’s now a ‘version 7’ internal to HAMMER 1. It changes the CRC code to a faster version, but since this instruction isn’t used (yet), there’s no real world impact. Remember this for next time you want to run ‘hammer version-upgrade’.
If you’re mounting a HAMMER2 filesystem, you can refer to it by label instead of by device.
No, it’s not ready for use yet and I don’t have a date other than “when it’s done”, to preanswer the next questions.
Did you know there’s a randread utility on DragonFly that will report on disk performance? Well, you do now. The very terse comment in the source code will tell you how to compile it and the arguments.
Yes, I know we just released 4.8. This is a rollup release, capturing everything that was committed to the 4.6 branch after 4.6.1 and before 4.8 came out. If you are going to upgrade, it’s worth it to go to 4.8, but this way there’s a clean final version in the 4.6 branch.
(Hat tip to Sascha Wildner for reminding me to do this.)
I am late in mentioning this, because it was added just before the DragonFly 4.8 branch: there’s a new ‘efisetup(8)‘ script added to DragonFly. Use to to perform a complete a UEFI-bootable installation to a given disk.
Odd batch of links this week.
- Not ‘other BSD’, but I didn’t have another good place for it: DragonFly 4.8 release discussion.
- LionBSD. Security-oriented FreeBSD packaging, at first look. (via)
- Changing Send/Receive Bandwidth on FreeBSD.
- Setting the Record Straight: containers vs. Zones vs. Jails vs. VMs. (via)
- The FreeBSD phone link from BSDNow, earlier this week, led me to these two other projects: FreeBSD Robot + Teensy 3.1 and MiniBSD laptop computer.
- *BSD for Dell XPS 13 (9350)
- OPNsense 17.1.4 released.
- vmm(4)/vmd(8) support for seabios and linux guests.
- “Httpd and Relayd Mastery” off to copyedit.
- NetBSD and Summer of Code, FreeBSD and Summer of Code. Deadline is in a few days!
- Upcoming NYCBUG events – next meeting is this Wednesday.
Your BSD-related fiction book of the week (year? decade?) :’git commit murder‘ is out, set at a (fictional) BSD convention.
Now that we’re past the DragonFly 4.8 release, Francois Tigeot has added an update to the i915 driver, bringing it to match what’s in the Linux 4.7.10 kernel. He also committed Peeter Must’s port of the vga_switcheroo module.
DragonFly 4.8 is officially released! Download from your nearest mirror, where it should appear in the next 24 hours. If you’re upgrading your existing install, you can use the generic instructions in the release notes or in my users@ email; whichever you click first. Don’t forget to ‘pkg upgrade’!
An article about a semctl(2) bug on DragonFly, “Make DragonFlyBSD great again!“, has popped up a few times, in comments here, some online forums, and in IRC. I’m linking to it so that I can also say: read all the way to the end and notice the date. The bug was fixed more than 6 months ago. This is not a current security problem, but a (enjoyable) description of how someone in Poland documented it.
Nobody reads anything but headlines, geez.
The last time SSH was updated in DragonFly, a DragonFly-specific customization, “PasswordAuthentication No”, was reverted to the default. This meant password logins through SSH worked on DragonFly – which is normal for perhaps every other UNIX-ish operating system, but DragonFly has traditionally defaulted to requiring a key out-of-the-box.
It has been fixed, and you can change the setting back. This only affected DragonFly-master from August through March. 4.6 users are unaffected.
Sepherosa Ziehau went to AsiaBSDCon 2017 and gave a talk on his work with DragonFly’s networking. He’s published a report of his trip, which comes with a link to his paper, his presentation, and pictures of who he met.
Note that the PDF and the Powerpoint slides links are different; one is the paper, one is the talk. The Powerpoint slides contain the benchmarks linked here in comments, previously.
Matthew Dillon picked up a number of different NVMe SSD drives, and tested them. He wrote up the entire test, but the immediate summary is: buy Samsung.
I always attributed speed issues to writing transaction history, but: Matthew Dillon discovered HAMMER was repeating itself when writing to disk. Fixing that issue doubled write speed. This fix is in 4.6 and the upcoming release.
I tagged the release candidate for DragonFly 4.8 – slightly delayed because of my involuntary time offline – and here’s the resulting automatic changelist. There’s ISO/IMG files uploaded now to the main DragonFly archive, which means they should be available at a mirror near you soon.
In what can be described as perfect timing, Sepherosa Ziehau has produced a document comparing FreeBSD, several different Linux kernels, and DragonFly, for networking. He’s presenting it in the afternoon track of Day 3 for AsiaBSDCon 2017, starting later this week.
He’s published a snippet as a PDF (via), which includes some graphs. The one place Linux outperforms DragonFly seems to be linked to the Linux version of the network card driver being able to access more hardware – so DragonFly should be comparable or better there too, once the powers-of-2 problem is solved. (This already came up in comments to a post last week.)
Those graphs are available standalone, too, which means it’s easier to see the fantastic performance for latency – see the thin blue line – that seems exclusive to DragonFly. That, if anything, is the real takeaway; that DragonFly’s model has benefits not just to plain speed but to the system’s responsiveness under load. “My CPU is maxed out cause I’m doing a lot of work but I hardly notice” is a common comment over the past few years – and now we can see that for network performance, too.
The longstanding practice is to load kernel modules in loader.conf, as early as possible. That’s good, for anything that needs them.
However, that also can be bad. Your machine can be unbootable if there’s a problem with a module or loader.conf is messed up, since that file is read long before the startup process finishes. Enter the new alternative: modules can be loaded in rc.conf, and the only loader.conf modules needed are those required by / to mount.