[Bug 200871] F2FS experiences data loss (entry is completely lost) when an I/O failure occurs.

[bugzilla-daemon@bugzilla.kernel.org]

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

--- Comment #2 from Stathis Maneas (smaneas@cs.toronto.edu) ---
1. I am using a device mapper module similar to the existing dm-flakey module:
https://elixir.bootlin.com/linux/v4.18/source/drivers/md/dm-flakey.c

Specifically, an error is introduced to an I/O operation in the same way as
implemented by the dm-flakey module
(https://elixir.bootlin.com/linux/v4.18/source/drivers/md/dm-flakey.c#L348):
...
else if (test_bit(ERROR_WRITES, &fc->flags)) {
        bio_io_error(bio);
        return DM_MAPIO_SUBMITTED;
}
...

In this case, fsync is not able to capture the error and returns as if no error
has taken place.

Here, I would like to mention that using this mechanism to introduce errors
when ext4 is used as the underlying file system, results in fsync returning an
error.

2. Indeed, the problem here is that the corresponding NAT table entry points to
an inode that has never been persisted on disk. However, since fsync does not
report an error, someone would hope that the entry would be there.

Moreover, the problem here is worse, because after invoking fsck, the entry
completely disappears from the file system and cannot be restored in any way.

Had fsync returned with an error, the user would have known that the operation
has failed and thus, they would not have excepted any modifications to have
taken place.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot