https://bugzilla.kernel.org/show_bug.cgi?id=200753 --- Comment #10 from Eric Sandeen (sandeen@xxxxxxxxxxx) --- (In reply to Shehbaz from comment #8) <ted beat me to the reply but I'll send this anyway> > 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. So, a few things. It might be worth reading https://lwn.net/Articles/457667/ for data persistence guarantees and best practices. For some operations, failures will simply not be seen by userspace unless data persistence calls are made. For example a buffered write failure won't be seen by the application unless it i.e. calls fsync on the write. I think some of your "failures to report to userspace" may fall into this class. And again, e2fsck is not expected to see any error. The whole point of a journaling filesystem like ext4 is to ensure that the metadata stays consistent even in the face of a failure. e2fsck not seeing any corruption after EIO is a /good/ thing. Now, I probably would expect to see some errors in dmesg if for example inode flushing fails at unmount time, though. It's not strictly a bug to not log an error at the filesystem level, but it's probably desirable. Ted can probably speak to this better than I can. > 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 The filesystem is responsible for maintaining metadata consistency (because it is a journaling filesystem), and for honoring syscalls it receives. But to be pedantic about it, the filesystem is only responsible for persisting writes if you explicitly tell it to do so via syscalls such as fsync. For example write(2): > A successful return from write() does not make any guarantee that data has > been committed to disk. It looks like none of your operations make any data persistence calls, so you're not /asking/ for a return of success or failure of persistence. -Eric -- You are receiving this mail because: You are watching the assignee of the bug.
