lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 07 Aug 2018 02:44:15 +0000
Subject: [Bug 200753] write I/O error for inode structure leads to operation
 failure without any warning or error

--- Comment #8 from Shehbaz ( ---
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.

Powered by blists - more mailing lists