Hammer will perform daily housekeeping tasks each night. If you’re up late enough, it may kick off while you are working. If you want to stop the process after it’s already started (since it’s disk-intensive), John Marino has added the ‘abort-cleanup‘ command.
Experimental automatic crypting of swap is now available in DragonFly-master. Recently added, though it may have been possible another way.
Sepherosa Ziehau has introduced a new sysctl:
net.link.ether.inet.log_arp_creation_failure
Set this to zero and you won’t get endless ARP events from networks you aren’t on. For example, I’m hooked up to a cable modem. I only get a public routable IP address, but the network used for the cable modem network itself bleeds ARP packets out where my DragonFly machine can see it. Since it’s on a different network segment than the address I receive through DHCP, it always fails and the system logs it. For example:
May 11 05:20:52 www kernel: arplookup 100.68.112.145 failed: host is not on local network
I can’t do much about it since that layer 2 leakiness is going to happen, but I can shut it up with this sysctl – and thank goodness, cause I’ve been seeing these messages since first using a DOCSIS modem in… 2001 or so?
Tomohiro Kusumi has been quietly making a lot of commits to Hammer. I haven’t been linking them because they don’t necessarily equate to new features, but here’s an recent exception: the -A argument will make your Hammer command run on every PFS. It only affects reblocking/rebalancing – for now.
You can now export Hammer slave volumes as NFS mounts – but since slave volumes are updated from master, you’re mounting a snapshot of that point in time. That may actually be an advantage.
DragonFly builds two compilers by default. If you weren’t interesting in building both, there were switches to build only the default, like NO_GCC47. This changed with every compiler update.
With the switch to GCC 5, the new switch is “NO_ALTCOMPILER”. That will last through compiler changes. I’m mentioning this now because sooner or later, you’ll want to gain back some time on a buildworld.
The most recent (well, this is the mostest recent) update of ACPICA for DragonFly, by Sascha Wildner, is different from the usual import: it happens to include actual upstream support for DragonFly
I haven’t been drawing enough attention to it, but there’s been a bunch of HAMMER filesystem activity lately: First, Tomohiro Kusumi has been working on HAMMER – these posts are a small subset of his commits. Second, Matthew Dillon has been working full steam ahead on HAMMER2. The HAMMER2 design document has been updated (read this!), and he’s already accomplished master->slave disk syncing.
It’s not ready for production, of course, which you may already realize, so don’t install it unless you want to work on the code.
Do you use info pages? Yeah, me neither. John Marino’s removed or converted the various info pages already in DragonFly, and removed texinfo since it’s no longer required. (I’ve linked to a few examples, but there were a number more commits than this.)
The default .cshrc in DragonFly has had some changes, which shouldn’t be anything but handy… assuming you are using tcsh. Also: the loader menu defaults to a blue Fred, now.
In the process of committing binutils 2.25 to DragonFly, John Marino also broke its build into parallel parts and removed the build of the gold linker. Buildworlds should be noticeably faster now, though I don’t have a before/after.
Bill Yuan’s work on a new ipfw has been committed, and for clarity, called “ipfw3“.
Matthew Dillon pulled in a new USB update from FreeBSD to DragonFly. What does it change? I’m not completely sure, but he did it to get apcupsd working, so that may be a hint.
DragonFly 4.0.3 has been tagged; you can look at the tagging message for details, but the major reason for doing so is to include OpenSSL-1.0.1l. I will have images up soon.
DragonFly no longer has SCTP. Nobody minds, I think – I had to look up what it is.
The CAM layer in DragonFly has had its big lock removed/been marked MPSAFE, so you will notice a performance increase when using multiple disks. (assuming you aren’t throughput-limited, of course.)
Sepherosa Ziehau has posted a note that V4-mapped addressing is no longer supported in DragonFly. You will need to do a full buildworld/buildkernel if you are running master. Also, TCP MTU path discovery is on by default. Also also, he’s added a SOL_SOCKET/SO_CPUINT socket option for use to reduce load in heavy network activity. As usual, I don’t quite comprehend.
It’s possible, if you are several releases (years) behind, to end up with a DragonFly system that can’t compile and install the current release, due to incremental changes over time. It’s rare, but it could happen now between, say, version 3.4 and 4.0. The usual solution would be to incrementally upgrade in order, which is a lot of building and updating. The alternative is the new installworld-force option from Matthew Dillon that forces a new set of binaries into place. Use as a last resort.
The DragonFly boot menu has been cleaned up a bit, and Fred, the dragonfly drawn on DragonFly, is now in better color. In fact, there’s even an option to turn him blue.
Update: I wanted to see what this looked like, and I realized screenshots might help everyone else.
In an effort to reduce my backlog of DragonFly things to post about, here’s quick notes:
- The path to xauth is now configurable, though correct by default. (that’s bit me in the past)
- There’s a new callout*() implementation.
- cpuctl(4) has been imported to allow CPU microcode updates.
- libm has been updated with math functions from FreeBSD and NetBSD, which because of library versioning support, won’t cause compatibility problems for older vs. newer DragonFly versions.
- C++11 support is also now available.