SU+J systems do not fsck themselves

[David Thiel]

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?

=================
Machine 1, with journal:
=================

Script started on Thu Dec 29 11:26:29 2011
fsck /
** /dev/ada0.eli

USE JOURNAL? [yn] y

** SU+J Recovering /dev/ada0.eli
** Reading 33554432 byte journal from inode 4.

RECOVER? [yn] y

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

WRITE CHANGES? [yn] y

** 108 journal records in 49152 bytes for 7.03% utilization
** Freed 9 inodes (0 dirs) 0 blocks, and 1 frags.

***** FILE SYSTEM MARKED CLEAN *****

Script done on Thu Dec 29 11:26:39 2011

=================
Machine 1, without journal:
=================

Script started on Thu Dec 29 11:26:49 2011
fsck /
** /dev/ada0.eli

USE JOURNAL? [yn] n

** Skipping journal, falling through to full fsck

** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=251177 (8 should be 0)
CORRECT? [yn] y

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
220435 files, 3945055 used, 3666151 free (17503 frags, 456081 blocks, 0.2% fragmentation)

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

***** FILE SYSTEM WAS MODIFIED *****

Script done on Thu Dec 29 11:27:08 2011


=================
Machine 2, with journal:
=================

** /dev/ada0s1a

USE JOURNAL? yes

** SU+J Recovering /dev/ada0s1a
** Reading 33554432 byte journal from inode 4.

RECOVER? yes

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

WRITE CHANGES? yes

** 131 journal records in 11776 bytes for 35.60% utilization
** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags.

***** FILE SYSTEM MARKED CLEAN *****

=================
Machine 2, without journal:
=================

** /dev/ada0s1a
** 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
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? [yn] 
SUMMARY INFORMATION BAD
SALVAGE? [yn] 
BLK(S) MISSING IN BIT MAPS
SALVAGE? [yn] 
670213 files, 19118534 used, 54535063 free (158431 frags, 6797079 blocks, 0.2% fragmentation)

***** FILE SYSTEM MARKED CLEAN *****

***** FILE SYSTEM WAS MODIFIED *****