linux-ext4 - Re: fsck.ext4 returning false positives

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 28 Feb 2013 09:49:36 -0600
From:	Bryan Mesich <bryan.mesich@...u.edu>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: fsck.ext4 returning false positives

On Wed, Feb 27, 2013 at 04:47:35PM -0500, Theodore Ts'o wrote:
> On Wed, Feb 27, 2013 at 03:16:22PM -0600, Bryan Mesich wrote:

[snip...]

> > e2fsck 1.42.6 (21-Sep-2012)
> > Pass 1: Checking inodes, blocks, and sizes
> > Pass 2: Checking directory structure
> > Pass 3: Checking directory connectivity
> > Pass 4: Checking reference counts
> > Pass 5: Checking group summary information
> > Free blocks count wrong (133413770, counted=133413835).
> > Fix? no
> > 
> > Free inodes count wrong (118244509, counted=118244510).
> > Fix? no
> > 
> > /dev/sanvg2/bbcontent_snap: 2554723/120799232 files (0.5% non-contiguous),
> > 349770870/483184640 blocks
> 
> Yes, these "errors" are not important.  We've changed e2fsprogs to
> suppress these errors when in preen (-p) mode, but in -n or in -y the
> messages are printed.  That's because it's "good" to update the global
> free counts, since some people do assume that the values reported by
> dumpe2fs are accurate, but it's not strictly necessary from the
> kernel's point of view.
> 
> We should probably suppress these errors in -n mode as well.

I think suppressing the "errors" in -n mode would desirable.  It was a
bit confusing having fsck.ext4 return 0 on exit, but indicate errors
were found in the output.  My instinct was to trust the return, but I
wanted to know for sure.  

So, by running fsck with no modes (i.e. fsck.ext4 -f /dev/vg/lv), does 
-p mode get "defaulted" to?  My thinking here is that if so, the errors
I was seeing when running in -n mode would not be present when forcing
fsck to check the origin volume.

If -p mode is not defaulted to, what is causing the free block and inode
counts to be incorrect when checking the snapshot?  My understanding was
that the VFS provides functionality to quiesce a file system, which LVM
takes advantage of when taking a snapshot.  This plus replaying the
journal should leave file system (located on the snap volume) in a
consistent state.

Bryan 

> Regards,
> 
> 					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html