On 4/8/2019 7:11 PM, Jan Kara wrote:
On Sat 06-04-19 15:13:13, ZhangXiaoxu wrote:
When the buffer write failed, 'end_buffer_write_sync' and
'end_buffer_async_write' will clear the uptodate flag. But the
data in the buffer maybe newer than disk. In some case, this
will lead data corruption.
For example: ext4 flush metadata to disk failed, it will clear
the uptodate flag. when a new coming call want the buffer, it will
read it from the disk(because the buffer no uptodate flag). But
the journal not checkpoint now, it will read old data from disk.
If read successfully, ext4 will write the old data to the new
journal, the data will corruption.
So, don't clear the uptodate flag when write the buffer failed.
Signed-off-by: ZhangXiaoxu<zhangxiaoxu5@xxxxxxxxxx>
Thanks for the patch. But what are the chances that after the write has
failed the read will succeed? Also there were places that were using
buffer_uptodate() to detect IO errors. Did you check all those got
converted to using buffer_write_io_error() instead?
Honza
I encountered this situation when using iscsi target as the ext4 volume,
if the network down a while when ext4 write metadata to disk, and maybe
read will success after the network recovered.
In my testcase, just create and delete files, when disconnect the network,
the dir entry maybe corruption. I add some logs when read entry buffer from
disk, the buffer stats maybe buffer_write_io_error() and !buffer_uptodate().
In this case, the ext4 will corruption high probability. Because the buffer
is read from disk, and some newer information just on journal. In this case,
we should not read buffer from the disk.
I don't know any other filesystem how to use the uptodate flag. But I think
uptodate means the buffer is valid and newer than disk, am I right?
I just test ext4 use the xfstest.
Any other idea about my problem?
