https://bugzilla.kernel.org/show_bug.cgi?id=200753 Bug ID: 200753 Summary: write I/O error for inode structure leads to operation failure without any warning or error 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 277725 --> https://bugzilla.kernel.org/attachment.cgi?id=277725&action=edit printAllBlocks.sh script that generates block trace of all blocks accessed Hello! Background ========== I am performing block level Write I/O error injection on ext4 file system using device mapper. I try the following commands: truncate, chmod, chown, utimes, symlink, creat. Each of these commands update the inode structure by writing to the inode data structure on one of the inode blocks. Observation =========== If the underlying device returns an EIO error, the operation does not give any warning or error either in the user space or in the logs, however the operation fails to undergo completion. Steps to Reproduce ================== Create 2 identical QEMU disks, each of 1.5GB. in my case these are /dev/sdc (backup disk) and /dev/sdb (primary disk). I create the image on backup disk and record block trace there. I then copy the image from backup to primary (using pv command) and replay the command by injecting block error on a specific inode block. 1. please create 2 qemu images /dev/sdb (primary image) and /dev/sdc (backup image) 2. please install pv command, compile dm-io.c with the Makefile attached. please download all attached files in 1 folder, as some commands are helper commands. 3. please run ./printAllBlocks.sh <cmd> where cmd is truncate, chmod, chown, utimes, symlink, creat. this would print a list of blocks with READ/WRITE operation. choose the inode block WRITE operation that is either the 3rd or 4th last block to be written to disk. the block type can be verified using dumpe2fs or debugfs command. In my disk image 4. now, with the target inode block number, run ./injectError.sh <cmd> <errBlkNo> where cmd is one of the 6 commands mentioned above, and errBlkNo is the inode block obtained in step 3. 5. analyse results: truncate - fails to truncate the file size to 40960 bytes. the original size of the file continues to remain the same, no error is reported in either syslog, fsck or user space. chmod - fails to correctly change the mode of the file to 777. the original mode of the file continues (644 in my case), no error is reported in either syslog, fsck or userspace. chown - fails to correctly change the ownership of the file to shehbaz:shehbaz. the original ownership of the file continues (root:root in my case), no error is reported in either syslog, fsck or userspace. utimes - fails to update last access and modification times to 1979. symlink - while corrupting the target inode, no error is reported (this is okay for the source path but here corrupting target inode leads to an unreported error). a subsiquent ls on the created target says file system structure needs cleaning. creat - fails when parent inode block update encounters a write I/O error. no error is reported in userspace or kernel space. Please find all programs attached for your reference. Please let me know if any other details regarding setup is required to reproduce the issue. Thanks! -- You are receiving this mail because: You are watching the assignee of the bug.
