https://bugzilla.kernel.org/show_bug.cgi?id=200739 Bug ID: 200739 Summary: I/O error on read-ahead inode blocks does not get detected or reported Product: File System Version: 2.5 Kernel Version: 4.17.0-rc3+ Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: ext4 Assignee: fs_ext4@xxxxxxxxxxxxxxxxxxxx Reporter: shehbazjaffer007@xxxxxxxxx Regression: No Created attachment 277693 --> https://bugzilla.kernel.org/attachment.cgi?id=277693&action=edit device mapper code Hello! Background ========== I am checking how ext4 behaves in response to block level I/O injection errors. I observe that ext4 file system reads multiple other inodes during an inode block access. these inodes are read-ahead inodes and their count can be modulated using the inode_readahead_blks parameter. For my experiments, I set this parameter to 2, so 2 additional inodes were read for each primary inode block access. Issue ===== When I inject I/O error on the first inode being accessed, I am able to see an I/O error message in both the user space - for example: stat: cannot stat '/mnt/DZAORDJFHRPGQGRPG7VBLAWNXR61S/BFIE2JB9Q353PQBK/OT8YSP69Q9NI93P8J6UK1WK0DFWSNQ599FHC5DIA0BWW7YIDC6W/U/FULLFILE': Input/output error and the kernel space, for example: EXT4-fs error (device dm-1): __ext4_get_inode_loc:4626: inode #568: block 156: comm stat: unable to read itable block However, if the I/O error takes place on all the subsequent read-ahead inodes, I observe no such error. Steps to Reproduce ================== 1. create a secondary ext2 file system with about 1.5GB space, preferably on QEMU. 2. compile and run dm-io.c using Makefile attached. this is a device mapper target that prints and optionally injects I/O error for a particular block. 3. run printAllBlocks.sh that would generate 2000 nested files and directories. It then mounts ext4 as a dm-io target that runs a "stat" command on one of the files. This also prints all blocks that were accessed in dmsg. We look for 3-4 consecutive blocks being read. For example, on my setup, I get the following blocks: 140 READ 142 READ 141 READ .... 144 READ 146 READ 145 READ .... 157 READ 158 READ 156 READ here, blocks 141,144,156 are primary inodes, and all other adjacent succeeding blocks are read-ahead inodes. 4. run injectError.sh [errBlkNo] script that would rerun the stat command, but this time it would inject I/O error when the erroBlkNo block number is returned back to the file system. I set errBlkNo to any of the inode blocks read. For each primary inode, I get an error. for all read ahead blocks, I do not get any error, either in user space or kernel space, which should be reported. Hence, I believe this is a bug. Please find all related scripts attached for reference. Thanks! -- You are receiving this mail because: You are watching the assignee of the bug.
