https://bugzilla.kernel.org/show_bug.cgi?id=200871
--- Comment #2 from Stathis Maneas (sman...@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 _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
