On Tue, Feb 25, 2020 at 3:58 PM Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > > > > On 2020/2/26 上午4:39, Jonathan H wrote: > > Hello everyone, > > > > Previously, I was running an array with six disks all connected via > > USB. I am running raid1c3 for metadata and raid6 for data, kernel > > 5.5.4-arch1-1 and btrfs --version v5.4, and I use bees for > > deduplication. Four of the six drives are stored in a single four-bay > > enclosure. Due to my oversight, TLER was not enabled for any of the > > drives, so when one of them started failing, the enclosure was reset > > and all four drives were disconnected. > > > > After rebooting, the file system was still mountable. I saw some > > transid errors in dmesg, > > This means the fs is already corrupted. > If btrfs check is run before mount, it may provide some pretty good > debugging Here is the output from "btrfs check --check-data-csum": http://ix.io/2cH7 > Also the exact message for the transid error and some context would help > us to determine how serious the corruption is. Unfortunately, I can't reproduce the transid errors, since they seem to have been fixed. However, I do recall that the wanted and found generations numbers differed by less than a hundred? > > I noticed that almost all of the files give an I/O error when read, > > and similar kernel messages are generated, but with positive roots. > > Please give the exact dmesg. > Including all the messages for the same bytenr. Here is the dmesg: http://ix.io/2cH7 > Although I don't believe it's the hardware to blame, but you can still > try to disable write cache on all related devices, as an experiment to > rule out bad disk flush/fua behavior. I've disabled the write cashes for now.
