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 devid 1 size 5.44TiB used 1.97TiB path /dev/bcache2 devid 2 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 > > devid 1 size 5.44TiB used 1.97TiB path /dev/bcache1 > > devid 2 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 > > devid 1 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 > > devid 1 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 > > devid 1 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 > > devid 2 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 <SEED > 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 <seed> > 2) btrfs inspect dump-tree -t chunk <seed> > > Thanks, > Qu > > > Thank you. -- Senén Vidal Blanco - SGISoft S.L. Tlf.: 986413322 - 660923711 GPG ID 466431A8AF01F99A http://www.sgisoft.com/ --
Description: This is a digitally signed message part.