Date: Fri, 30 Dec 2011 00:05:57 -0700 From: Scott Long <scottl@samsco.org> To: David Thiel <lx@FreeBSD.org> Cc: jsa@FreeBSD.org, boris@nyi.net, freebsd-current@FreeBSD.org Subject: Re: SU+J systems do not fsck themselves Message-ID: <07D71DC4-0C3F-4995-A75A-AEBAF3EEA318@samsco.org> In-Reply-To: <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> <20111229230214.GT45484@redundancy.redundancy.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?07D71DC4-0C3F-4995-A75A-AEBAF3EEA318>