Date: Tue, 02 Aug 2022 19:24:53 +0000 From: bugzilla-noreply@freebsd.org To: doc@FreeBSD.org Subject: [Bug 261944] FFS/UFS: explain soft update journaling (SUJ) in documentation and in tunefs(8) Message-ID: <bug-261944-9-VFfD8qR0kJ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-261944-9@https.bugs.freebsd.org/bugzilla/> References: <bug-261944-9@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261944 Kirk McKusick <mckusick@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress --- Comment #9 from Kirk McKusick <mckusick@FreeBSD.org> --- (In reply to Graham Perrin from comment #8) Here is an expanded explanation of journaled soft updates: I will leave it to you / others to figure out where it should go. My take is that all but the last paragraph should at least be added to tunefs(8). =3D-=3D-=3D Soft updates can add journaling that reduces the time spent by fsck_ffs(8) cleaning up a filesystem after a crash to a few seconds from minutes to hou= rs. It is possible to run fsck_ffs(8) in background on a live filesystem though= the filesystem performance will be about half of normal during the time that the background fsck_ffs(8) is running. 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 recov= ery 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 journali= ng. 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 p= anic to check for and fix any errors brought on by media failure. A full fsck ca= n be done by running a background fsck on a live filesystem or by running with t= he -f flag on an unmounted filesystem. 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 mount= ed filesystems or to run background fsck on them. The FreeBSD Foundation has sponsored me to make snapshots possible on journaled filesystems. I anticip= ate having that project completed by July 2023. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-261944-9-VFfD8qR0kJ>