On 2019/9/30 下午6:57, Qu Wenruo wrote: > > > On 2019/9/30 下午6:23, Andrey Ivanov wrote: >> On 30.09.2019 13:10, Qu Wenruo wrote: >>>> I had built and run it: >>>> >>>> # /home/andrey/devel/src/btrfs/btrfs-progs-dirty_fix/btrfs-corrupt-block >>>> -X /dev/sdc1 >>>> incorrect offsets 15223 15287 >>>> Open ctree failed >>> >>> That branch updated to skip the item offset check completely. >>> >>> But please keep in mind that, that check itself still makes sense, so >>> please use the original "btrfs check" to check the fs. >> >> # /home/andrey/devel/src/btrfs/btrfs-progs-dirty_fix/btrfs-corrupt-block >> -X /dev/sdc1 >> key (613019873280 EXTENT_ITEM 1048576)slot end outside of leaf >> 1073755934 > 16283 >> Open ctree failed > > This means there are more corruptions in just that one leaf. > > It's really hard to fix them one by one manually. > > I'd recommend to go btrfs-restore or use this patchset: > https://patchwork.kernel.org/project/linux-btrfs/list/?series=170715 > > Then mount with ro,rescue=skipbg. > > Either way, the bitflip is way beyond my imagination.
One strange thing hit me, not sure if it's just a coincident. We have another report internally about a similar corruption (multiple bit flips in a single fs), and they are also using VMware, along with VMware guest kernel modules. Would you mind to migrate to KVM based hypervisor to see if the corruption happens again? Thanks, Qu > > Thanks, > Qu > >> >> # btrfs check /dev/sdc1 >> Opening filesystem to check... >> incorrect offsets 15223 15287 >> ERROR: cannot open file system >
signature.asc
Description: OpenPGP digital signature
