linux-ext4 - [Bug 200753] write I/O error for inode structure leads to operation failure without any warning or error

lists.openwall.net		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 linux-hardening linux-cve-announce 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 03:36:25 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...nel.org
Subject: [Bug 200753] write I/O error for inode structure leads to operation
 failure without any warning or error

https://bugzilla.kernel.org/show_bug.cgi?id=200753

--- Comment #10 from Eric Sandeen (sandeen@...deen.net) ---
(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.