https://bugzilla.kernel.org/show_bug.cgi?id=200753 --- Comment #8 from Shehbaz (shehbazjaffer007@xxxxxxxxx) --- Hello Eric and Theodore, I apologize for filing bug reports before describing what I am trying to do. The purpose of my study is to determine how block-level read and write I/O errors are handled by different file systems. In order to simulate this, I created a device mapper target that intercepts all blocks that are read and written by a file system. I use a combination of dumpe2fs, code documentation and debugfs to determine different data structures on the file system. For each run of a command, multiple blocks are accessed from the device. I systematically return an I/O error from the device mapper instead of the actual block, one block at a time and check how file system either detects or recovers from this error. Specifically, for inode read operations (eg. access, chdir), an I/O error during the read of an inode leads to an error message in user space and an error message in kernel space. Also, the read operation fails. For error during a write of an inode (which mostly happens when I unmount the device, which is when all blocks are flushed to disk), I observe that if I return an EIO error, this is not acknowledged by the file system in any way. I do not see a log message that the EIO was detected by the file system while flushing blocks to disk. e2fsck also does not report that a certain inode write operation did not successfully get flushed to disk. The updated values in the inode do not get reflected once I remount the file system and I see the older file system image. I would like to ask if such failed operations, due to the failure of the underlying device should be detected and reported at the file system level? I think since the file system would be responsible for persisting writes to disk, if the disk returns back an I/O error during a write operation, this should be reported to either the user or atleast logged as a warning or error message notifying the user that the operation did not succeed as the disk never recorded the updated write. Once again, I apologize for submitting the bug reports without validating them. I would like to understand your view of this problem and if this form of error should be handled at the file system layer. Thank you, -- You are receiving this mail because: You are watching the assignee of the bug.
