git: 0929a153fc5c - main - Add a description of soft updates journaling to newfs(8).

From: Kirk McKusick <>
Date: Fri, 21 Oct 2022 17:57:48 UTC
The branch main has been updated by mckusick:


commit 0929a153fc5cfe35f7390ab5870a36daed19b0ce
Author:     Kirk McKusick <>
AuthorDate: 2022-10-21 17:56:20 +0000
Commit:     Kirk McKusick <>
CommitDate: 2022-10-21 17:57:31 +0000

    Add a description of soft updates journaling to newfs(8).
    Add a descrition to the newfs(8) -j (journal enablement) flag
    that explains what soft updates journaling does, the tradeoffs
    to using it, and the limitations that it imposes. Copied from
    the description in tunefs(8).
    PR:           261944
    Sponsored by: The FreeBSD Foundation
 sbin/newfs/newfs.8 | 42 +++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/sbin/newfs/newfs.8 b/sbin/newfs/newfs.8
index a5b850c54675..a065563f86d1 100644
--- a/sbin/newfs/newfs.8
+++ b/sbin/newfs/newfs.8
@@ -28,7 +28,7 @@
 .\"     @(#)newfs.8	8.6 (Berkeley) 5/3/95
 .\" $FreeBSD$
-.Dd April 17, 2021
+.Dd October 21, 2022
 .Dt NEWFS 8
@@ -169,6 +169,46 @@ This flag is implemented by running the
 .Xr tunefs 8
 utility found in the user's
 .Dv $PATH .
+Enabling journaling reduces the time spent by
+.Xr fsck_ffs 8
+cleaning up a filesystem after a crash to a few seconds from minutes to hours.
+Without journaling, the time to recover after a crash is a function
+of the number of files in the filesystem and the size of the filesystem.
+With journaling, the time to recover after a crash is a function of the
+amount of activity in the filesystem in the minute before the crash.
+Journaled recovery time is usually only a few seconds and never
+exceeds a minute.
+The drawback to using journaling is that the writes to its log adds
+an extra write load to the media containing the filesystem.
+Thus a write-intensive workload will have reduced throughput on a
+filesystem running with journaling.
+Like all journaling filesystems, the journal recovery will only fix
+issues known to the journal.
+Specifically if a media error occurs,
+the journal will not know about it and hence will not fix it.
+Thus when using journaling, it is still necessary to run a full fsck
+every few months or after a filesystem panic to check for and fix
+any errors brought on by media failure.
+A full fsck can be done by running a background fsck on a live
+filesystem or by running with the
+.Fl f
+flag on an unmounted filesystem.
+When running
+.Xr fsck_ffs 8
+in background on a live filesystem the filesystem performance
+will be about half of normal during the time that the background
+.Xr fsck_ffs 8
+is running.
+Running a full fsck on a UFS filesystem is the equivalent of
+running a scrub on a ZFS filesystem.
+Presently it is not possible to take a snapshot on a UFS filesystem
+running with journaled soft updates.
+Thus it is not possible to reliably dump mounted filesystems or
+to run background fsck on filesystems enabled for journaling.
 .It Fl k Ar held-for-metadata-blocks
 Set the amount of space to be held for metadata blocks in each cylinder group.
 When set, the file system preference routines will try to save