Cleanup H2 notes for 5.4.1
authordillon <dillon@web>
Mon, 24 Dec 2018 19:54:26 +0000 (19:54 +0000)
committerIkiWiki <ikiwiki.info>
Mon, 24 Dec 2018 19:54:26 +0000 (19:54 +0000)
release54/index.mdwn

index c66c3ee..194001e 100644 (file)
@@ -273,40 +273,11 @@ Don't forget to upgrade your existing packages.  5.4 packages have already been
 
 ### 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).
+* 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).