Date: Thu, 29 Dec 2011 15:02:38 -0800 From: David Thiel <lx@FreeBSD.org> To: freebsd-current@freebsd.org Cc: jsa@freebsd.org, boris@nyi.net Subject: Re: SU+J systems do not fsck themselves Message-ID: <20111229230214.GT45484@redundancy.redundancy.org> In-Reply-To: <9DAD04BE-D330-4DC8-9307-597834EEA2CA@samsco.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 *****
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111229230214.GT45484>