Hi! On Wed 18-03-20 09:17:51, Aneesh Kumar K.V wrote: > With new vm install I am finding corruption with the vm image if I > follow up the install with echo 3 > /proc/sys/vm/drop_caches > > The file system reports below error. > > Begin: Running /scripts/local-bottom ... done. > Begin: Running /scripts/init-bottom ... > [ 4.916017] EXT4-fs error (device vda2): ext4_lookup:1700: inode #787185: comm sh: iget: checksum invalid > done. > [ 5.244312] EXT4-fs error (device vda2): ext4_lookup:1700: inode #917954: comm init: iget: checksum invalid > [ 5.257246] EXT4-fs error (device vda2): ext4_lookup:1700: inode #917954: comm init: iget: checksum invalid > /sbin/init: error while loading shared libraries: libc.so.6: cannot open shared object file: Error 74 > [ 5.271207] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 > > And debugfs reports > > debugfs: stat <917954> > Inode: 917954 Type: bad type Mode: 0000 Flags: 0x0 > Generation: 0 Version: 0x00000000 > User: 0 Group: 0 Size: 0 > File ACL: 0 > Links: 0 Blockcount: 0 > Fragment: Address: 0 Number: 0 Size: 0 > ctime: 0x00000000 -- Wed Dec 31 18:00:00 1969 > atime: 0x00000000 -- Wed Dec 31 18:00:00 1969 > mtime: 0x00000000 -- Wed Dec 31 18:00:00 1969 > Size of extra inode fields: 0 > Inode checksum: 0x00000000 > BLOCKS: > debugfs: > > Bisecting this finds > Commit 244adf6426ee31a83f397b700d964cff12a247d3("ext4: make > dioread_nolock the default") as bad. If I revert the same on top of linus > upstream(fb33c6510d5595144d585aa194d377cf74d31911) I don't hit the > corrupttion anymore. Thanks for report and the bisection! Is this guest or host kernel that you were bisecting? I presume host but I want to make sure. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR