Re: Balance loops: what we know so far

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2020/5/5 下午5:10, Andrea Gelmini wrote:
> Il giorno mar 5 mag 2020 alle ore 01:48 Qu Wenruo
> <quwenruo.btrfs@xxxxxxx> ha scritto:
> 
>> I mean, btrfs-image dump of the umounted fs.
>> (btrfs-image can compress the metadata, and won't include data, thus it
>> can be way smaller than the image)
> 
> No problem to give you complete image, data and metadata.

Thanks for your dump.

Do you still have the initial looping dmesg?
The point here is to locate the offending block group.

But anyway, your dump is already very interesting.

- The dump has no reloc tree
  Which means, the balance should already finished and all reloc tree
  already cleaned up.
  In theory, we should be able to continue to next chunk.
  But in reality we're not.

- There is a metadata chunk with data reloc tree leaf
  If we're looping on block group 12210667520, then it's possible that
  we're deadlooping on that block group, with "found 1 extents".
  From the bytenr it indeed looks like the case.
  But still, the initial dead loop dmesg would provide better proof to
  this.
  (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)

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.

Thanks,
Qu

> 
>> At this stage, the image should be pretty small.
>> You can try restart the system and boot into liveCD and dump the image.
> 
> Just to give you more possible info, here¹ you find all the files. I
> guess you figure out how to
> use it without my explain, but anyway, just for the record:
> 
> - video.mkv : show you how I re-up the save-state of vm at the moment
> I saw the loop;
> - Virtualbox-Files.tar.bz2 : contains all the Virtualbox VM files, so
> you can run it up on your own. You can also view the history command I
> did;
> - ubuntu-iso.tar : just to make it easier, it's simply the iso Ubuntu
> I'm using, with the right path, so if you want to replicate my side;
> - sda1.btrfs.dd.bz2 : is the dd of all the BTRFS partition, just after
> the reset of the VM, but without mount it. So, if I mount it, I see
> this:
> 
> [268398.481278] BTRFS: device fsid
> cdbf6911-63f6-410e-9d22-a0376dfcc8ce devid 1 transid 32588 /dev/loop35
> scanned by systemd-udevd (392357)
> [268404.681217] BTRFS info (device loop35): disk space caching is enabled
> [268404.681221] BTRFS info (device loop35): has skinny extents
> [268404.694708] BTRFS info (device loop35): enabling ssd optimizations
> [268404.700398] BTRFS info (device loop35): checking UUID tree
> [268404.722430] BTRFS info (device loop35): balance: resume -musage=2 -susage=2
> [268404.722523] BTRFS info (device loop35): relocating block group
> 12546211840 flags metadata|dup
> [268404.752675] BTRFS info (device loop35): found 21 extents
> [268404.771509] BTRFS info (device loop35): relocating block group
> 12512657408 flags system|dup
> [268404.792802] BTRFS info (device loop35): found 1 extents
> [268404.819137] BTRFS info (device loop35): relocating block group
> 12210667520 flags metadata|dup
> [268404.858634] BTRFS info (device loop35): found 26 extents
> [268404.915321] BTRFS info (device loop35): balance: ended with status: 0
> 
> Just in case:
> 1aced5ec23425845a79966d9a78033aa  sda1.btrfs.dd.bz2
> 93c9a2d50395383090dd031015ca8e89  ubuntu-iso.tar
> e9b3d49439cc41cd34fba078cf99c1b8  video.mkv
> 663b9a55bbfdb51fc8a77569445a9102  Virtualbox-Files.tar.bz2
> 
> Hope it helps,
> Gelma
> 
> ¹ http://mail.gelma.net/btrfs-vm/
> 

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux