5.4.1 release notes
authorjustin <justin@web>
Mon, 24 Dec 2018 14:14:15 +0000 (14:14 +0000)
committerIkiWiki <ikiwiki.info>
Mon, 24 Dec 2018 14:14:15 +0000 (14:14 +0000)
release54/index.mdwn

index 7a445d8..7634231 100644 (file)
@@ -33,15 +33,17 @@ The details of all commits between the 5.2 and 5.4 branches are available in the
 * 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
 
 ## Details
 
 ### Checksums
 
-    MD5 (dfly-x86_64-5.4.0_REL.img) = 7277d7cffc92837c7d1c5dd11a11b98f
-    MD5 (dfly-x86_64-5.4.0_REL.iso) = 6da7abf036fe9267479837b3c3078408
-    MD5 (dfly-x86_64-5.4.0_REL.img.bz2) = a77a072c864f4b72fd56b4250c983ff1
-    MD5 (dfly-x86_64-5.4.0_REL.iso.bz2) = 4dbfec6ccfc1d59c5049455db914d499
+MD5 (dfly-x86_64-5.4.1_REL.img) = 5819175d148e8cfa08c384483b0b25e2
+MD5 (dfly-x86_64-5.4.1_REL.iso) = 8030f4ff31c3308b20ffbeeeb89351ba
+MD5 (dfly-x86_64-5.4.1_REL.img.bz2) = 271c0e5c247479791a35404973e71fcc
+MD5 (dfly-x86_64-5.4.1_REL.iso.bz2) = 9ddb7eabf4aed34a39e188849cd4f36c
 
 ### Upgrading
 
@@ -269,5 +271,42 @@ Don't forget to upgrade your existing packages.  5.4 packages have already been
 * There's a number of options now for running a web browser on DragonFly; check the [browser documentation page](https://www.dragonflybsd.org/docs/docs/howtos/WebBrowsers/) for a full list.
 * wpa_supplicant is installed as a package by default; delete if your system does not use wireless.  The version in base remains as a safety measure in case the dports version is deleted.
 
+### HAMMER2 changes in 5.4.1
+
+* H2 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.
+* The update now under test in master fixes all of these issues and is also
+able to guarantee buffer cache consistency... hence also write() atomicy
+boundaries on snapshot or crash.
+* As an added bonus, most of the front-end stalls that currently occur during a filesystem sync have also been cleaned up.  The frontend.. that is, the filesystem system calls made by programs, is now able to operate concurrently with a filesystem sync.   Previously the front-end stalled on
+any modifying operation made to any inode during a filesystem sync (something I did to try to 'fix' the prior consistency issues, but which
+didn't sufficiently fix the problems).  With the new work, the front-end
+now only stalls on the specific inodes which are in the sync queue, and
+will reorder any inodes it stalls on to the front of the sync queue in
+order to retire their flushes as quickly as possible.  Once the inode is no
+longer on the sync queue, the front-end can proceed with its modifying
+operation concurrent with the continuing filesystem sync.  The result is
+significantly better concurrency and far shorter-duration stalls for those
+situations where a stall is mandatory.   The new code keeps track of and
+handles any dependencies between inodes on the syncq and inodes not on the
+syncq which arise during this operation.
+* The new patch also 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).
+