Download DragonFly BSD 5.4.2

With a BSD operating system, most people think of one of the three variants FreeBSD, OpenBSD or NetBSD. However, there are several other BSD versions, such as TrueOS and DragonFly BSD. The latter is a fork of FreeBSD 4.8, which came into existence around June 2003. This happened because Matthew Dillon, the project leader of DragonFly BSD, at the time disagree was aware of the chosen development strategy and focus areas of FreeBSD 5. For an overview of DragonFly BSD developments since then, see this page go through. Version 5.4.2 has recently become available, with the following changes:

DragonFly BSD 5.4

DragonFly version 5.4 brings a new system compiler in GCC 8, improved NUMA support, a large number of network and virtual machine driver updates, and updates to video support. This release is 64-bit only, as with previous releases.

DragonFly version 5.4.1 has significant HAMMER2 improvements (meta-consistency protection for snapshots and crashes, better on-media topology)better WLAN interface handling, and improved WLAN connection with dhcpcd(8).

DragonFly 5.4.2 has a fix for a rare potential HAMMER2 corruption problem. Other minor 5.4.2 changes are marked in the full notes below.

The details of all commits between the 5.2 and 5.4 branches are available in the associated commit messages for 5.4.0rc, 5.4.0, 5.4.1and 5.4.2.

Big ticket items

• Much better support for asymmetric NUMA (Non-Uniform Memory Access) configurations. In particular, both the memory subsystem and the scheduler now understand the Threadripper 2990WX’s architecture. The scheduler will prioritize CPU nodes with direct-attached memory and the memory subsystem will normalize memory queues for CPU nodes without direct-attached memory (which improves cache locality on those CPUs).
• Incremental performance work. DragonFly as a whole is very SMP friendly. The type of performance work we are doing now mostly revolves around improving fairness for shared-vs-exclusive lock clashes, reducing cache ping-ponging due to non-contending SMP locks (ie massive use of shared locks on shared resources), and so forth .
• Major updates to dports brings us to within a week or two of FreeBSD’s ports as of this writing, in particular major updates to chromium, and making the whole mess work with gcc-8.
• Major rewriting of the tty clist code and the tty locking code, significantly improving concurrency across multiple ttys and ptys.

GCC 8

• DragonFly now ships with GCC 8.0, and runs as the default compiler. It is also now used for building dports.
• GCC 4.7.4 and GCC 5.4.1 are still installed. 4.7.4 is our backup compiler, and 5.4.1 is still there to ensure a smooth transition, but should generally not be used. buildworld builds all three by default to ensure maximum compatibility.
• Many passes through world sources were made to address various warnings and errors the new GCC brought with it.

HAMMER2

• HAMMER2 is recommended as the default root filesystem in non-clustered mode.
• Clustered support is not yet available.
• Increased bulkfree cache to reduce the number of iterations required.
• Fixed numerous bugs.
• Improved support on low-memory machines.
• Significant pre-work on the XOP API to help support future networked operations.
• (in 5.4.1) HAMMER2 filesystem meta-consistency protection for snapshots and crashes has been improved, as has speed of snapshot generation. See full notes at the end of the document

HAMMER2 changes in 5.4.1

• The HAMMER2 filesystem now has meta-consistency protection for snapshots and crashes. This is on top of the lower-level radix tree protections it already had. The coherency protection handles directory-entry-vs-inode dependencies which prior to this patch could sometimes get broken by a crash, causing the nlinks count on the inode to not match the number of directory entries referencing it, sometimes putting directory entry flushes and the related inode flushes in different sync groups, and often causing snapshot operations to ‘cut’ the filesystem while it is in an inconsistent state, when made in the midst of modifying activity. Some people have noticed these issues recently, and while they can be cleaned up with manual hammer2 directives after the fact, it was really annoying to have to deal with.
• Files should now be completely consistent at write() boundaries on crash or snapshot.
• As an added bonus, concurrency between frontend filesystem calls and backend flushes is now much, much better than it was before. Instead of having to wait for most of the flush to complete, modifying system calls (create/delete/write/truncate/etc) are now able to run concurrently in most situations. In situations where concurrency is not possible, frontend operations reorder the flush sequence that is underway in the background to retire the stalled inodes as quickly as possible. The kernel’s buffer cache operations also run more smoothly, improving read-to-write concurrency.
• The new patch significantly improves snapshot operation, and adds a new directive called ‘snapshot-debug’ (which I will probably rename) which foregoes the standard sync-before-snapshot that the primary ‘snapshot’ directive implements. Both directives will snapshot a fully consistent filesystem, the only difference is that snapshot-debug might not get changes made just prior to issuing the command (it uses a recorded blockmap from the most recent sync instead of forcing a new sync).

HAMMER2 changes in 5.4.2
A HAMMER2 corruption issue has been found: it can ONLY occur during heavy write activity during a bulkfree operation, typically when heavy manipulation of directory entries or inodes occurs. This problem is fixed in 5.4.2. HAMMER2 now has immediate (async) flush follow-through when the operating system requests it, with write-clustering support at the device level if enabled. This, plus other changes have improved concurrent filesystem ops and I/O and sequential filesystem write I/O.