Re: SU+J systems do not fsck themselves

From: Scott Long <scottl_at_samsco.org>
Date: Fri, 30 Dec 2011 00:05:57 -0700
On Dec 29, 2011, at 4:02 PM, David Thiel wrote:

> On Wed, Dec 28, 2011 at 12:57:31AM -0700, Scott Long wrote:
>> So, there's an assumption with SUJ+fsck that SU is keeping the filesystem consistent.  Maybe that's a bad assumption, and I'm not trying to discredit your report.  But the intention with SUJ is to eliminate the need for anything more than a cursory check of the superblocks and a processing of the SUJ intent log.  If either of these fails then fsck reverts to a traditional scan.  In the same vein, ext3 and most other traditional journaling filesystems assume that the journal is correct and is preserving consistency, and don't do anything more than a cursory data structure scan and journal replay as well, but then revert to a full scan if that fails (zfs seems to be an exception here, with there being no actual fsck available for it).
>> 
>> As for the 180 day forced scan on ext3, I have no public comment.  SU has matured nicely over the last 10+ years, and I'm happy with the progress that SUJ has made in the last 2-3 years.  If there are bugs, they need to be exposed and addressed ASAP.
> 
> That clears things up somewhat - thank you for taking the time to 
> explain all that. I've got results from two other users (Cc'd) with a 
> fsck in single user mode using the journal and not using it. One has 
> geli, one does not, and both were with clean shutdown/boot (correct me 
> if I'm wrong, guys). Any thoughts?

Below is the transcript of my simple experiment with an intentional unclean shutdown with an unlinked file held open.  The machine was idle with nothing of any significance installed (it is a driver development box).  I created a file and opened in it vi, meanwhile I deleted it from another vty and then did a power cycle.  Everything looks as correct and normal as I would expect.  The /usr and /var filesystems also checked out normal.

My system sources are from mid-November, maybe earlier.

# fsck /
** /dev/ada0p2

USE JOURNAL? [yn] y

** SU+J Recovering /dev/ada0p2
** Reading 8388608 byte journal from inode 4.

RECOVER? [yn] y

** Building recovery table.
** Resolving unreferenced inode list.
** Processing journal entries.

WRITE CHANGES? [yn] y

** 5 journal records in 2048 bytes for 7.81% utilization
** Freed 1 inodes (0 dirs) 0 blocks, and 0 frags.

***** FILE SYSTEM MARKED CLEAN *****
# fsck /
** /dev/ada0p2

USE JOURNAL? [yn] n

** Skipping journal, falling through to full fsck

** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
676 files, 41820 used, 216107 free (787 frags, 26915 blocks, 0.3% fragmentation)

***** FILE SYSTEM IS CLEAN *****

***** FILE SYSTEM WAS MODIFIED *****
# 
Received on Fri Dec 30 2011 - 06:06:01 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:22 UTC