e2fsprogs/tests/f_no_cache_corrupt_inode/expect.2

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
test_filesys: 12/128 files (0.0% non-contiguous), 19/512 blocks
Exit status is 0
libext2fs: don't cache inodes that fail checksum verification If an inode fails checksum verification, don't stuff a copy of it in the inode cache, because this can cause the library to fail to return the "corrupt inode" error code. In general, this happens if ext2fs_read_inode_full() is called twice on an inode with an incorrect checksum. If fs->flags has EXT2_FLAG_IGNORE_CSUM_ERRORS set during the first call and unset during the second call, the cache hit during the second call fails to return EXT2_ET_INODE_CSUM_INVALID as you'd expect. This happens during fsck because the first read_inode call happens as part of check_blocks and the second call happens during inode checksum revalidation. A file system with a slightly corrupt non-extent inode will trigger this. While we're at it, make the inode read function consistent with the rest of libext2fs -- copy the metadata object into the caller's buffer even if it fails checksum verification. This will help e2fsck avoid a double re-read later on down the line. Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> 2014-08-03 06:49:12 +04:00			`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`
			`test_filesys: 12/128 files (0.0% non-contiguous), 19/512 blocks`
			`Exit status is 0`