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.
Matthew Dillon picked up more NVMe M.2 hardware, tested it, and updated his report to match. Definitely a good read if you will be buying this hardware any time soon, and it’s not necessarily DragonFly-specific.
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.
Matthew Dillon has been doing a significant amount of work on cache lines, and I haven’t been linking to it because it’s hard to point at single commits with such a technical subject. However, he’s summarized it all, along with news on NUMA handling and vkernel improvements.
Matthew Dillon moved some locks and exec() performance jumped up significantly – 50% or more. This is a single system call, so I don’t know how much translates through to real performance change, but it’s interesting to see.
There’s the DragonFly syntax for loader hints, and there’s the FreeBSD syntax. If you happen to use the FreeBSD syntax on DragonFly, it’ll still work.
Thanks to Imre Vadasz, the virtio driver in DragonFly now has PCI MSI-X support. This should help with virtual performance, though I say that on principle, not with any actual numbers to back it up.
Here’s one of the reasons to have your own permanent server: The New York Times has a daily feature called, not surprisingly, “The Daily“. It’s a short 15-20 minute news segment, ready by 6 AM. It’s available through Google Play Music or iTunes, but I leave for work by 6:15, and I don’t want to use up cell data downloading something that should arrive on my phone just before I leave the house. Of course, there’s no obvious way to tell Google Play, “I know it’s there; go get it right now”. I don’t know the iPhone experience, but I imagine it’s the same. I want to download on my time, not on Google or Apple’s schedule.
Luckily, there’s an RSS feed for this podcast. That, plus this simple script on my DragonFly system, means I can pull it down whenever I’m ready:
fetch -o – http://feeds.podtrac.com/zKq6WZZLTlbM | grep enclosure | cut -d ‘”‘ -f2 | xargs fetch -m
So, it’s a matter of running that script, and syncing off my own local storage, on my own schedule. FolderSync Lite will happily sync back to my phone using sftp.
Are you on DragonFly-master? Are you using a Realtek network device? Sepherosa Ziehau has an update he would like you to test.
There was some issues with the DPorts repo, so you may need to reset your local copy. This only applies if you pulled down a copy in the last 48 hours or so. (update: or less, based on John’s comment) Otherwise, you are fine.
Rimvydas Jasinskas posted an extended description of what’s happening with dports. There’s a significant xorg reformatting coming in ports, which is going to be absorbed into dports, but it may take some time. There’s also an odd loss of commit rights for John Marino, who commits (frequently!) to both DragonFly and FreeBSD. (His followup) This all translates to some upcoming transition time for dports to accommodate these changes.
Note that if you are using dports binaries, especially on DragonFly 4.6 release, this won’t really affect you; the way dports is set up, binary sets always work. It is interesting to hear about future work, in any case.
This recent CPU frequency change will make your Skylake-using laptop much easier to deal with. Apparently this is a common problem with Skylake? (links via EFNet #dragonflybsd)
The vkernel(7) code has been going through a lot of changes, and instead of linking to the many smaller commits, I’ll point at Matthew Dillon’s latest change since it’s detailed. What’s the performance difference? I don’t know yet if this is for performance or for stability.
Apparently there’s a quirk to the way Ricoh cameras format memory cards that made them unreadable on DragonFly. They’re readable now. I link this not because I think it affects many people, but because it’s such a strangely specific problem.