From owner-freebsd-current@FreeBSD.ORG Fri Dec 30 07:06:01 2011 Return-Path: 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 123841065670 for ; Fri, 30 Dec 2011 07:06:01 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id D6D0F8FC12 for ; Fri, 30 Dec 2011 07:06:00 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id pBU75vDi057262; Fri, 30 Dec 2011 00:05:57 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <20111229230214.GT45484@redundancy.redundancy.org> Date: Fri, 30 Dec 2011 00:05:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <07D71DC4-0C3F-4995-A75A-AEBAF3EEA318@samsco.org> References: <20111227215330.GI45484@redundancy.redundancy.org> <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> <20111229230214.GT45484@redundancy.redundancy.org> To: David Thiel X-Mailer: Apple Mail (2.1251.1) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: jsa@FreeBSD.org, boris@nyi.net, freebsd-current@FreeBSD.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 07:06:01 -0000 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). >>=20 >> 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. >=20 > That clears things up somewhat - thank you for taking the time to=20 > explain all that. I've got results from two other users (Cc'd) with a=20= > fsck in single user mode using the journal and not using it. One has=20= > geli, one does not, and both were with clean shutdown/boot (correct me=20= > 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 ***** #=20