Re: Couldn't read tree root BTRFS - SEED
Hello Qu, Thank you very much for the answer. I am sorry to answer late because before bothering more, I decided to perform another cloning test. In this time he has joined the second device correctly. The problem has occurred because they are BCACHE devices, and although the SEED disk does not vary over time, buy the read-write yes, with which I have made sure this time empty the cache before performing the cloning. Now, when inserting the discs I have managed to mount everything correctly: Label: 'SEED_MD2' uuid: 285b16fa-b297-43ed-bb3b-311950729eb6 Total devices 2 FS bytes used 2.00TiB devid1 size 5.44TiB used 1.97TiB path /dev/bcache2 devid2 size 1.80TiB used 122.03GiB path /dev/bcache1 The truth is that the BTRFS-BCACHE-MDADM combination is complex, but the results are really satisfactory and enormous versatility is achieved. To thank the BTRFS team and other responsible people for doing a great job. El jueves, 5 de abril de 2018 20:57:49 (CEST) Qu Wenruo escribió: > On 2018年04月05日 19:27, Senén Vidal Blanco wrote: > > Hello, > > I have a problem when mounting the btrfs system with two units (one in > > SEED > > mode and the other in read-write mode) > > > > Initially it is functioning correctly in production: > > > > btrfs fi sh > > Label: 'SEED_MD2' uuid: 285b16fa-b297-43ed-bb3b-311950729eb6 > > > >Total devices 2 FS bytes used 2.00TiB > >devid1 size 5.44TiB used 1.97TiB path /dev/bcache1 > >devid2 size 1.80TiB used 119.03GiB path /dev/bcache0 > > > > Label: 'BOOT' uuid: ce8fd2ef-975c-417a-b90c-280f8d324c44 > > > >Total devices 1 FS bytes used 536.86MiB > >devid1 size 1.86GiB used 1.15GiB path /dev/md1 > > > > Label: 'SEED_MD2' uuid: 851e4474-d375-4a25-b202-949e51f05877 > > > >Total devices 1 FS bytes used 1.94TiB > >devid1 size 5.44TiB used 1.97TiB path /dev/bcache1 > > > > The bcache0 and bcache1 units are what I mention. > > bcache1 is the SEED > > bcache0 is the read-write > > > > When it comes to mounting the two copy mirror devices that is in > > production I have this result: > > > > parent transid verify failed on 2184045428736 wanted 269593 found 266275 > > parent transid verify failed on 2184045428736 wanted 269593 found 266275 > > It's not the problem that btrfs fails to assemble correct seed/rw > devices list, it's something wrong (metadata corruption) happened. > > > Ignoring transid failure > > So this is btrfs-progs (btrfs check). Kernel doesn't ignore any transid > failure AFAIK. > > > Couldn't map the block 2287467560960 > > No mapping for 2287467560960-2287467577344 > > Couldn't map the block 2287467560960 > > bytenr mismatch, want=2287467560960, have=0 > > Couldn't read tree root > > Label: 'SEED_MD2' uuid: 851e4474-d375-4a25-b202-949e51f05877 > > > >Total devices 1 FS bytes used 1.94TiB > >devid1 size 5.44TiB used 1.97TiB path /dev/bcache1 > > > > Label: 'SEED_MD2' uuid: 285b16fa-b297-43ed-bb3b-311950729eb6 > > > >Total devices 2 FS bytes used 1.98TiB > >devid2 size 1.80TiB used 102.03GiB path /dev/bcache2 > >*** Some devices missing > > > > Would there be any way to tell BTRFS that the missing unit is the one that > > corresponds to the SEED unit so that it correctly rebuilds the file > > system? > > The rw device is corrupted. > > To ensure your seed device is safe, please run "btrfs check device>" to see if there is any problem. > > From current output, it seems that your chunk tree is corrupted, so that > btrfs check can't even map the logical address for your tree root. > > And to further debug the corrupted fs, please attach the following data: > > 1) btrfs inspect dump-super -fa > 2) btrfs inspect dump-tree -t chunk > > Thanks, > Qu > > > Thank you. -- Senén Vidal Blanco - SGISoft S.L. Tlf.: 986413322 - 660923711 GPG ID 466431A8AF01F99A http://www.sgisoft.com/ -- signature.asc Description: This is a digitally signed message part.
Re: Couldn't read tree root BTRFS - SEED
On 2018年04月05日 19:27, Senén Vidal Blanco wrote: > Hello, > I have a problem when mounting the btrfs system with two units (one in SEED > mode and the other in read-write mode) > > Initially it is functioning correctly in production: > > btrfs fi sh > Label: 'SEED_MD2' uuid: 285b16fa-b297-43ed-bb3b-311950729eb6 >Total devices 2 FS bytes used 2.00TiB >devid1 size 5.44TiB used 1.97TiB path /dev/bcache1 >devid2 size 1.80TiB used 119.03GiB path /dev/bcache0 > > Label: 'BOOT' uuid: ce8fd2ef-975c-417a-b90c-280f8d324c44 >Total devices 1 FS bytes used 536.86MiB >devid1 size 1.86GiB used 1.15GiB path /dev/md1 > > Label: 'SEED_MD2' uuid: 851e4474-d375-4a25-b202-949e51f05877 >Total devices 1 FS bytes used 1.94TiB >devid1 size 5.44TiB used 1.97TiB path /dev/bcache1 > > The bcache0 and bcache1 units are what I mention. > bcache1 is the SEED > bcache0 is the read-write > > When it comes to mounting the two copy mirror devices that is in production I > have this result: > > parent transid verify failed on 2184045428736 wanted 269593 found 266275 > parent transid verify failed on 2184045428736 wanted 269593 found 266275 It's not the problem that btrfs fails to assemble correct seed/rw devices list, it's something wrong (metadata corruption) happened. > Ignoring transid failure So this is btrfs-progs (btrfs check). Kernel doesn't ignore any transid failure AFAIK. > Couldn't map the block 2287467560960 > No mapping for 2287467560960-2287467577344 > Couldn't map the block 2287467560960 > bytenr mismatch, want=2287467560960, have=0 > Couldn't read tree root > Label: 'SEED_MD2' uuid: 851e4474-d375-4a25-b202-949e51f05877 >Total devices 1 FS bytes used 1.94TiB >devid1 size 5.44TiB used 1.97TiB path /dev/bcache1 > > Label: 'SEED_MD2' uuid: 285b16fa-b297-43ed-bb3b-311950729eb6 >Total devices 2 FS bytes used 1.98TiB >devid2 size 1.80TiB used 102.03GiB path /dev/bcache2 >*** Some devices missing > > Would there be any way to tell BTRFS that the missing unit is the one that > corresponds to the SEED unit so that it correctly rebuilds the file system? The rw device is corrupted. To ensure your seed device is safe, please run "btrfs check " to see if there is any problem. From current output, it seems that your chunk tree is corrupted, so that btrfs check can't even map the logical address for your tree root. And to further debug the corrupted fs, please attach the following data: 1) btrfs inspect dump-super -fa 2) btrfs inspect dump-tree -t chunk Thanks, Qu > > Thank you. > signature.asc Description: OpenPGP digital signature
Couldn't read tree root BTRFS - SEED
Hello, I have a problem when mounting the btrfs system with two units (one in SEED mode and the other in read-write mode) Initially it is functioning correctly in production: btrfs fi sh Label: 'SEED_MD2' uuid: 285b16fa-b297-43ed-bb3b-311950729eb6 Total devices 2 FS bytes used 2.00TiB devid1 size 5.44TiB used 1.97TiB path /dev/bcache1 devid2 size 1.80TiB used 119.03GiB path /dev/bcache0 Label: 'BOOT' uuid: ce8fd2ef-975c-417a-b90c-280f8d324c44 Total devices 1 FS bytes used 536.86MiB devid1 size 1.86GiB used 1.15GiB path /dev/md1 Label: 'SEED_MD2' uuid: 851e4474-d375-4a25-b202-949e51f05877 Total devices 1 FS bytes used 1.94TiB devid1 size 5.44TiB used 1.97TiB path /dev/bcache1 The bcache0 and bcache1 units are what I mention. bcache1 is the SEED bcache0 is the read-write When it comes to mounting the two copy mirror devices that is in production I have this result: parent transid verify failed on 2184045428736 wanted 269593 found 266275 parent transid verify failed on 2184045428736 wanted 269593 found 266275 Ignoring transid failure Couldn't map the block 2287467560960 No mapping for 2287467560960-2287467577344 Couldn't map the block 2287467560960 bytenr mismatch, want=2287467560960, have=0 Couldn't read tree root Label: 'SEED_MD2' uuid: 851e4474-d375-4a25-b202-949e51f05877 Total devices 1 FS bytes used 1.94TiB devid1 size 5.44TiB used 1.97TiB path /dev/bcache1 Label: 'SEED_MD2' uuid: 285b16fa-b297-43ed-bb3b-311950729eb6 Total devices 2 FS bytes used 1.98TiB devid2 size 1.80TiB used 102.03GiB path /dev/bcache2 *** Some devices missing Would there be any way to tell BTRFS that the missing unit is the one that corresponds to the SEED unit so that it correctly rebuilds the file system? Thank you. signature.asc Description: This is a digitally signed message part.
