The ls(1) command has a lot of options (Look at the man page synopsis!). So much so, that the most recent option added in DragonFly is “_”. That’s to show nanotime as part of the -l output. This will be most useful when you have multiple files being created within the same second of time, and you want to see which came first.
I’m still catching up with the pre-2018, pre-Meltdown commits, so here’s one: Changing the staged packet count in DragonFly changes forwarding rate, for the better – up to a point. There’s probably some specific ratio in the change that makes sense, though I don’t know it.
The commands rcp(1), rlogin(1), rlogind(1), rsh(1) and rshd(1) have been removed from DragonFly. There’s a net/bsdrcmds port if you still need them… though I imagine/hope ssh is filling the void for everyone.
I say “one more” like I know when this saga will end. If you are using the devcpu-data port to update your processors, you’ll need to add
to your /etc/rc.conf, as Sepherosa Ziehau points out.
The regular maintenance scripts for HAMMER1 assume that it’s mounted at the time of cleanup. If you have them unmounted, they won’t go through that regular maintenance, but it’s easy enough to fix.
Matthew Dillon posted a summary of IBRS and IBPB support in DragonFly, and some numbers showing its impact in various configurations of options and CPUs.
Are you tired of hearing about Meltdown/Spectre yet? Doesn’t matter! The two sysctls for controlling mitigation in DragonFly have been renamed:
They go to hopefully sensible defaults, but Matthew Dillon has done some testing to show the effects of each in various combinations. (Update: more changes and tests.) Note that this is not the final mitigation work; compilers (i.e. gcc) are being updated to include workarounds for this, so new gcc -> new compiler in DragonFly -> new defenses. No silver bullet there, though.
One side effect of Meltdown/Spectre are CPU microcode (firmware) updates. For future needs: sysutils/devcpu-data is the port that has the updates for Intel, and cpucontrol(8) is the program you run on DragonFly to add them.
I haven’t used this myself, yet, so I can’t tell you how necessary an immediate update could be – but you will probably want to use it soon.
Update: Newer CPUs might require this sizing change.
It’s turned off and on by the sysctl machdep.isolated_user_pmap – and defaults to on for Intel CPUs. Buildworld tests show about a 4-5% performance hit, but that’s only one form of activity, measured, so there will surely be other effects.
Note that Spectre is not mitigated by this commit series, and as I understand it, cannot be realistically fixed in software.
Update: Matthew Dillon posted a summary to users@.
Update 2: He told us so.
DragonFly has a donation page and a Paypal account. There’s no 501c3 benefit for U.S. residents to donate; DragonFly doesn’t exist as a non-profit. People have still been donating in smaller sums over time. It’s not enough to offset the colocation fees ($4k/year) plus the hardware there, but the money does get used for specific tasks. Matthew Dillon wrote a description of his upcoming plans: more storage, plus some interesting details on how much wear the existing SSD disks have sustained.
If your DragonFly-current system was built between December 6th and 10th, you should upgrade. There’s a memory corruption bug that may bite you otherwise – but it only existed for those 4 days.
You could, if you are running DragonFly-current, create a vkernel using HAMMER2, and try out HAMMER2 even if your underlying disk is HAMMER1. Odd, but useful.