For future edification: If you have HAMMER2 installed, the bulkfree operation will create console/dmesg activity even when nothing is wrong, to show operations are happening.
If you happen to be using DragonFly from a network location that only allows http/https as outbound traffic, you won’t be able to update /usr/src using defaults. /usr/Makefile pulls DragonFly source using a git:// URL.
The fix is to use the read-only Github mirror. You can set origin manually or just change GITHOST in /usr/Makefile (or GITURL_SRC if you are on DragonFly-master) to “https://github.com/DragonFlyBSD/DragonFlyBSD”.
(Guess what I did today? Updated to note it’s different on -master. Thanks tuxillo for reminding me of this whole thing.)
DragonFly has an automated installer, called PFI, for “pre-flight installer”. It’s not well-known, and there isn’t a man page to link to for it that I can find. Because of that, I jump at any chance I can get to link documentation or example configs.
There’s a fix for memory contention in NUMA (meaning Threadripper in this case) configurations on DragonFly; the commit has before-and-after numbers. They are somewhat context-free, so I can’t easily translate to what this means for performance.
The performance page on dragonflybsd.org has been updated with numbers on symmetric multiprocessing performance. (Scroll to the 2018 section.)
If you were looking to install DragonFly into part of your already-in-use hard drive, here’s some conversation about the process.
Matthew Dillon’s moved tty_token from a global to per-CPU token in most cases in DragonFly. This is good for performance as with any global->local shift, but I can’t tell you what aspect it improves.
Did you use the digi(4), rp(4) and si(4) serial device drivers in DragonFly? I don’t think so, but you definitely can’t now.
Matthew Dillon recently fixed a TRIM bug, where a TRIM command was being issued unconditionally, regardless of the mount flag, and duplicating the action if it was set normally. It’s fixed now. This would only have any significant slowdown on UFS, which means it would only affect installworld – the rest of your mounted volumes are HAMMER, right?
To add to my ongoing slow fiddle with DragonFly: I’ve noted how to install in Hyper-V, and how to use Cygwin to connect to run X. Here’s another step: if you are using PuTTY/Pageant, as I am, and want to connect, Cygwin/X needs to be told to listen on TCP. Find your /usr/bin/startxwin file in Cygwin and change serverargs to:
And then in PuTTY, under Connection -> Session -> X11, check “Enable X11 forwarding”, set X display location to “:0.0”, and locate your .Xauthority file. It will be in your user’s Cygwin home directory. (tips found here)
plink can be used to create shortcuts – open an xterm directly into your DragonFly VM from your Windows desktop, for instance, with a shortcut that runs ‘plink <sessionname> xterm’.
If you are running a slightly newer version of Windows and aren’t trying to accommodate a ‘legacy’ PuTTY install, using Windows Subsystem for Linux may work better; I have not yet tried.
For the future edification of others: I mentioned I installed DragonFly under Hyper-V on a Windows 10 laptop. I wanted to be able to open a terminal on DragonFly while in my Windows environment. I have that now; here’s what I did:
- Installed DragonFly in Hyper-V (see my prior install notes)
- Installed xorg on DragonFly. (pkg install xorg)
- Installed Cygwin/X on Windows 10 – specifically, the xauth, xorg, xterm, xclock, cygutils-x11, and openssh packages.
- In DragonFly, set these items in /etc/ssh/sshd_config :
- X11Forwarding Yes
- X11DisplayOffset 0
- XAuthLocation /usr/local/bin/xauth
- Run XWin Server on Windows 10.
- Run CygWin64 Terminal on Windows 10
- export DISPLAY=:0.0
- ssh -Y (address of DragonFly host)
- Once logged in, type ‘xterm’.
At this point, a terminal window should pop up on your Windows machine, showing your DragonFly username@hostname as the prompt. You are set!
Next steps – getting this working with PuTTY, Pageant, and Plink.
If your kernel panics, the current state of memory can show why. That memory dump needs to be saved somewhere. ‘dumpon’ is the command to specify the device that will keep it. If you want to turn it off, you end up using the odd syntax ‘dumpon off’. Thanks to Aaron Li, there’s now a linguistically-sane command: ‘dumpoff’.