On 2019/9/30 下午4:00, Andrey Ivanov wrote: > On 30.09.2019 10:31, Qu Wenruo wrote: >> For this one, I could help you by just reverting that bit, and then you >> may be able to continue mounting the fs or at least run btrfs check on >> it. >> >> Please prepare an environment to compile btrfs-progs (at least >> btrfs-corrupt-block) if you want to try. > > Great, I'm ready to do it. Environment is ready.
Here it is. https://github.com/adam900710/btrfs-progs/tree/dirty_fix To use it: $ ./btrfs-corrupt-block -X /dev/sdc1 But please keep in mind that, the offending tree block has more problems than I originally thought: - Bad item size at slot 20 The original one reported by kernel. - Bad key offset at slot 9 - Bad item size at slot 41 All bitflips. So all 3 bit flips happened in one leaf, it's really too rare. I really don't have any clue how this could happen. Anyway, I don't think the dirty fix is enough considering how many strange things I have found just in one leaf. Thanks, Qu > > >>> I did a memtest earlier. All had passed without errors. I can do a >>> memtest again, >>> but it seems to me that if the memory was faulty, the system would not >>> be stable >>> and often hung, but the system works fine. >> >> Indeed, especially considering that there are already two bitflips in >> one leaf, which should be pretty rare. >> >> Any out-of-tree kernel modules? > > I only have vmware out-of-tree kernel modules. > > >> Or would you like to try v5.2.15 kernel, >> which has a self detection for such problem. > > If I understand correctly, if I install v5.2.15 or later kernel > then I'll fix my /dev/sda4?
signature.asc
Description: OpenPGP digital signature
