add volid to failed csum messages
PATCH 1/1 add volid to failed csum messages
The failed csum messages generated by btrfs mention the inode number, but on filesystems with multiple subvolumes, that's not enough to identify the file. I've added the inode number to the messages so that they're more complete.
I also noticed that the extent/offset information printed for the file isn't always correct. Indeed, when we print an offset that could be fed to inspect-internal logical-resolve, we used the term offset, that doesn't make it clear it's a logical offset, whereas when we print a physical disk offset, as in compression.c, we used the term extent, which incorrectly implied it to be a logical offset. I've renamed them to lofst and phofst, which are hopefully clearer. Ideally, we'd uniformly print logical offsets in these messages, but presumably the information isn't readily available for check_compressed_csum.
I haven't quite tested this beyond building it (I don't have a sure way to trigger csum errors :-), but AFAICT the objectid I've added is the same number that one can pass to mount as subvolid, or look up in the btrfs subvol list table.
--- fs/btrfs/compression.c | 8 +++++--- fs/btrfs/inode.c | 12 ++++++++---- 2 files changed, 13 insertions(+), 7 deletions(-)
fs/btrfs/compression.c +5 -3
@@ -129,9 +129,11 @@ static int check_compressed_csum(struct inode *inode,if (csum != *cb_sum) {btrfs_info (BTRFS_I (inode)->root->fs_info, -"csum failed ino %llu extent %llu csum %u wanted %u mirror %d" , -btrfs_ino (inode), disk_start, csum, *cb_sum, - cb->mirror_num); +"csum failed ino %llu vol %llu phofst %llu csum %u wanted %u mirror %d" , +btrfs_ino (inode), +BTRFS_I (inode)->root->root_key.objectid, + disk_start, csum, *cb_sum, + cb->mirror_num); ret = -EIO ; goto fail; }
fs/btrfs/inode.c +8 -4
@@ -2829,8 +2829,10 @@ good: zeroit:if (__ratelimit (&_rs)) -btrfs_info (root->fs_info,"csum failed ino %llu off %llu csum %u expected csum %u" , -btrfs_ino (page->mapping->host), start, csum, csum_expected); +btrfs_info (root->fs_info,"csum failed ino %llu vol %llu lofst %llu csum %u expected csum %u" , +btrfs_ino (page->mapping->host), + root->root_key.objectid, + start, csum, csum_expected);memset (kaddr + offset,1 , end - start +1 );flush_dcache_page (page);kunmap_atomic (kaddr);
@@ -6981,8 +6983,10 @@ static void btrfs_endio_direct_read(struct bio *bio, int err)flush_dcache_page (bvec->bv_page);if (csum != csums[i]) { -btrfs_err (root->fs_info,"csum failed ino %llu off %llu csum %u expected csum %u" , -btrfs_ino (inode), start, csum, +btrfs_err (root->fs_info,"csum failed ino %llu vol %llu lofst %llu csum %u expected csum %u" , +btrfs_ino (inode), + root->root_key.objectid, + start, csum, csums[i]); err = -EIO ; }
Signature · 4 lines
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Alexandre Oliva posted on Tue, 20 May 2014 12:37:07 -0300 as excerpted:
Quoted 3 lines
The failed csum messages generated by btrfs mention the inode number, but on filesystems with multiple subvolumes, that's not enough to identify the file. I've added the inode number to the messages
?? s/added the inode number/added the volid/ ??
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman