ext4: don't print scary messages for allocation failures post-abort
PATCH 1/1 ext4: don't print scary messages for allocation failures post-abort
I often get emails containing the "This should not happen!!" message, conveniently trimmed to remove things like:
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 03 13 c9 70 00 00 28 00end_request: I/O error, dev sda, sector 51628400
Aborting journal on device dm-0-8.
EXT4-fs error (device dm-0): ext4_journal_start_sb: Detected aborted journal EXT4-fs (dm-0): Remounting filesystem read-only
I don't think there is any value to the verbosity if the reason is due to a filesystem abort; it just obfuscates the root cause.
---
fs/ext4/inode.c +14 -11
@@ -2221,6 +2221,8 @@ static int mpage_da_map_blocks(struct mpage_da_data *mpd) blks =ext4_map_blocks (handle, mpd->inode, &map, get_blocks_flags);if (blks <0 ) { +struct super_block *sb = mpd->inode->i_sb; + err = blks;/* * If get block returns with error we simply
@@ -2231,7 +2233,7 @@ static int mpage_da_map_blocks(struct mpage_da_data *mpd)return 0 ;if (err == -ENOSPC && -ext4_count_free_blocks (mpd->inode->i_sb)) { +ext4_count_free_blocks (sb)) { mpd->retval = err;return 0 ; }
@@ -2243,16 +2245,17 @@ static int mpage_da_map_blocks(struct mpage_da_data *mpd)* writepage and writepages will again try to write * the same. */ -ext4_msg (mpd->inode->i_sb,KERN_CRIT , -"delayed block allocation failed for inode %lu at " -"logical offset %llu with max blocks %zd with " -"error %d" , mpd->inode->i_ino, - (unsigned long long ) next, - mpd->b_size >> mpd->inode->i_blkbits, err); -printk (KERN_CRIT "This should not happen!! " -"Data will be lost\n" ); -if (err == -ENOSPC ) { -ext4_print_free_blocks (mpd->inode); +if (!(EXT4_SB (sb)->s_mount_flags &EXT4_MF_FS_ABORTED )) { +ext4_msg (sb,KERN_CRIT , +"delayed block allocation failed for inode %lu " +"at logical offset %llu with max blocks %zd " +"with error %d" , mpd->inode->i_ino, + (unsigned long long ) next, + mpd->b_size >> mpd->inode->i_blkbits, err); +ext4_msg (sb,KERN_CRIT , +"This should not happen!! Data will be lost\n" ); +if (err == -ENOSPC ) +ext4_print_free_blocks (mpd->inode); }/* invalidate all the pages */ ext4_da_block_invalidatepages(mpd, next,
fs/ext4/mballoc.c +3 -0
@@ -3889,6 +3889,9 @@ static void ext4_mb_show_ac(struct ext4_allocation_context *ac)struct super_block *sb = ac->ac_sb;ext4_group_t ngroups, i; +if (EXT4_SB (sb)->s_mount_flags &EXT4_MF_FS_ABORTED ) +return ; +printk (KERN_ERR "EXT4-fs: Can't allocate:" " Allocation context details:\n" ); printk(KERN_ERR "EXT4-fs: status %d flags %d\n",
Ted Ts'o
maintainerQuoted 11 lines · Eric Sandeen
I often get emails containing the "This should not happen!!" message, conveniently trimmed to remove things like:
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 03 13 c9 70 00 00 28 00end_request: I/O error, dev sda, sector 51628400
Aborting journal on device dm-0-8.
EXT4-fs error (device dm-0):ext4_journal_start_sb: Detected aborted journal EXT4-fs (dm-0): Remounting filesystem read-only
Quoted 4 lines
I don't think there is any value to the verbosity if the reason is due to a filesystem abort; it just obfuscates the root cause.
Signed-off-by Eric Sandeen <[email protected]>
I've added this patch to the ext4 patch queue, thanks.
- Ted