On 2020/5/7 上午2:24, Andrea Gelmini wrote: > Il giorno mer 6 mag 2020 alle ore 07:58 Qu Wenruo > <quwenruo.btrfs@xxxxxxx> ha scritto: >> Thanks for your dump. >> >> Do you still have the initial looping dmesg? > > Yeap, you can find the complete syslog here: > http://mail.gelma.net/btrfs-vm/syslog.txt This helps a lot! > > >> If we're looping on block group 12210667520, then it's possible that > > Oh, well, from the syslog above: > May 3 17:14:25 ubuntu kernel: [ 586.735870] BTRFS info (device > sda1): balance: start -musage=2 -susage=2 > May 3 17:14:25 ubuntu kernel: [ 586.735974] BTRFS info (device > sda1): relocating block group 12479102976 flags system|dup > May 3 17:14:25 ubuntu kernel: [ 586.833331] BTRFS info (device > sda1): relocating block group 12210667520 flags metadata|dup > May 3 17:14:25 ubuntu kernel: [ 586.939172] BTRFS info (device > sda1): found 26 extents > May 3 17:14:25 ubuntu kernel: [ 587.021568] BTRFS info (device > sda1): found 1 extents > (and then repeating lines like this) Exactly, this proved my assumption, something strange is happening for DATA RELOC TREE. That last one tree block is from DATA_RELOC tree, normally we would relocate it by creating reloc tree for it, and swap tree blocks. But we don't need to be that complex for DATA_RELOC tree, as unlike regular subvolume tree, no snapshot can be created for DATA_RELOC tree, thus we can handle it just like extent trees. Although I still don't understand why it doesn't work as usual, I'm working on a POC patch to change the behaivor, hoping to solve the problem. During that time, if you hit similar case, the same dump would provide great help to enhance btrfs. Thanks, Qu > >> (Sorry, not sure if I could convert the vbox format to qcow2 nor how >> to resume it to KVM/qemu, thus I still have to bother you to dump the >> dmesg) > > I guess no way to migrate the saved state of VB to QEMU. > Anyway, I have prepared a minimal Lubuntu 20.04. It starts up, run > VirtualBox and let you to replicate what I see. > It's ~40GB. If you cat it on /dev/usb-stick you can boot up (no way > to run it inside KVM because of VB need to access VT-x). > > I'm uploading it. It takes lot of hours. I tell you know when done. > >> If that's the case, it would be very interesting in how we're handling >> the data reloc tree. >> It would be very worthy digging then. > > Good! > > Ciao, > Gelma >
Attachment:
signature.asc
Description: OpenPGP digital signature
