From owner-freebsd-current@FreeBSD.ORG Thu Dec 29 23:02:15 2011
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id 6DDD01065670
for <freebsd-current@freebsd.org>; Thu, 29 Dec 2011 23:02:15 +0000 (UTC)
(envelope-from lx@redundancy.redundancy.org)
Received: from redundancy.redundancy.org (75-101-96-57.dsl.static.sonic.net
[75.101.96.57]) by mx1.freebsd.org (Postfix) with SMTP id 2CA598FC12
for <freebsd-current@freebsd.org>; Thu, 29 Dec 2011 23:02:14 +0000 (UTC)
Received: (qmail 3182 invoked by uid 1001); 29 Dec 2011 23:02:38 -0000
Date: Thu, 29 Dec 2011 15:02:38 -0800
From: David Thiel <lx@FreeBSD.org>
To: freebsd-current@freebsd.org
Message-ID: <20111229230214.GT45484@redundancy.redundancy.org>
References: <20111227215330.GI45484@redundancy.redundancy.org>
<CAGMYy3t3Rv006qvBCHr4kdbM86andkr5mRkvaGYw5CETO1XHkg@mail.gmail.com>
<20111227223638.GK45484@redundancy.redundancy.org>
<4EFA4B4E.201@delphij.net>
<20111228051404.GL45484@redundancy.redundancy.org>
<6F3ACDEE-B656-46D0-AB11-FF1B23E70A27@samsco.org>
<20111228073442.GM45484@redundancy.redundancy.org>
<9DAD04BE-D330-4DC8-9307-597834EEA2CA@samsco.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9DAD04BE-D330-4DC8-9307-597834EEA2CA@samsco.org>
X-OpenPGP-Key-fingerprint: 482A 8C46 C844 7E7C 8CBC 2313 96EE BEE5 1F4B CA13
X-OpenPGP-Key-available: http://redundancy.redundancy.org/lx.gpg
X-Face: %H~{$1~NOw1y#%mM6{|4:/<p]y9X%E+4%:1wo-M!re,
zl.qH~yzbL-MWhtp$3QuKP&di/a{FOctD[FuX.\n4U*,
M{TJg$oYp663.NyX!%H~~Tw$eR9xZU5W?1BM#t"a@'27^2x
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: jsa@freebsd.org, boris@nyi.net
Subject: Re: SU+J systems do not fsck themselves
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Dec 2011 23:02:15 -0000
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 *****