summaryrefslogtreecommitdiffstats
path: root/fs/ramfs
diff options
context:
space:
mode:
authorZhangXiaoxu <zhangxiaoxu5@huawei.com>2019-08-22 23:00:32 -0400
committerTheodore Ts'o <tytso@mit.edu>2019-08-22 23:00:32 -0400
commit7963e5ac901251c7a3b36fe7c987623a3f309393 (patch)
tree922d0f204bee33b9dfbfcf63cf1662c401e9e473 /fs/ramfs
parente3d550c2c4f2f3dba469bc3c4b83d9332b4e99e1 (diff)
downloadlinux-7963e5ac901251c7a3b36fe7c987623a3f309393.tar.gz
linux-7963e5ac901251c7a3b36fe7c987623a3f309393.tar.bz2
linux-7963e5ac901251c7a3b36fe7c987623a3f309393.zip
ext4: treat buffers with write errors as containing valid data
I got some errors when I repair an ext4 volume which stacked by an iscsi target: Entry 'test60' in / (2) has deleted/unused inode 73750. Clear? It can be reproduced when the network not good enough. When I debug this I found ext4 will read entry buffer from disk and the buffer is marked with write_io_error. If the buffer is marked with write_io_error, it means it already wroten to journal, and not checked out to disk. IOW, the journal is newer than the data in disk. If this journal record 'delete test60', it means the 'test60' still on the disk metadata. In this case, if we read the buffer from disk successfully and create file continue, the new journal record will overwrite the journal which record 'delete test60', then the entry corruptioned. So, use the buffer rather than read from disk if the buffer is marked with write_io_error. Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Diffstat (limited to 'fs/ramfs')
0 files changed, 0 insertions, 0 deletions