https://bugzilla.kernel.org/show_bug.cgi?id=201685 --- Comment #216 from Jukka Santala (donwulff@xxxxxx) --- This time the corrupt inode block came clearly from one of the JPG files I was checksumming (without writing) with rsync at the same time. Poor test because I was checking against BTRFS filesystem, so I don't know which fs the corrupt block came from. Also first time I hit actual corruption with filesystem mounted errors=remount-ro, somehow two blocks of inodes had multiply claimed inodes. To me this suggests that the corrupting block came from another reservation block, the kernel didn't notice that because the data structure was valid and wrote it back. If so, this would indicate it happens inside single filesystem and with metadata blocks as source as well. It seems to me like metadata blocks are remaining linked when evicted due to memory pressure. BTRFS csum errors probably from same source. Steps for reproducing would be causing evictions in large pagecache while re-accessing same inode blocks. Backup scripts do this when same block contains inodes created at different times, ie. for me it happens constantly when reading files in date-specific directories where files from different days are in same inode block so the copy command re-reads the same block after some evictions. Likely some race-condition in block reservation or the like, because otherwise it'd be crashing all the time, but the corrupt block stays in the cache. -- You are receiving this mail because: You are watching the assignee of the bug.
