Re: parent transid verify failed / ERROR: could not setup extent tree
On Tue, Mar 23, 2021 at 12:50 AM Dave T wrote: > > > d. Just skip the testing and try usebackuproot with a read-write > > mount. It might make things worse, but at least it's fast to test. If > > it messes things up, you'll have to recreate this backup from scratch. > > I took this approach. My command was simply: > > mount -o usebackuproot /dev/mapper/xzy /backup > > It appears to have succeeded because it mounted without errors. I > completed a new incremental backup (with btrbk) and it finished > without errors. > I'll be pleased if my backup history is preserved, as appears to be the case. > > I will run some checks on those backup subvolumes tomorrow. Are there > specific checks you would recommend? It will have replaced all the root nodes and super blocks within a minute, or immediately upon umount. So you can just do a 'btrfs check' and see if that comes up clean now. It's basically a kind of rollback and if it worked, there will be no inconsistencies found by btrfs check. -- Chris Murphy
Re: parent transid verify failed / ERROR: could not setup extent tree
On Mon, Mar 22, 2021 at 3:49 PM Chris Murphy wrote: > > On Mon, Mar 22, 2021 at 12:32 AM Dave T wrote: > > > > On Sun, Mar 21, 2021 at 2:03 PM Chris Murphy > > wrote: > > > > > > On Sat, Mar 20, 2021 at 11:54 PM Dave T wrote: > > > > > > > > # btrfs check -r 2853787942912 /dev/mapper/xyz > > > > Opening filesystem to check... > > > > parent transid verify failed on 2853787942912 wanted 29436 found 29433 > > > > parent transid verify failed on 2853787942912 wanted 29436 found 29433 > > > > parent transid verify failed on 2853787942912 wanted 29436 found 29433 > > > > Ignoring transid failure > > > > parent transid verify failed on 2853827723264 wanted 29433 found 29435 > > > > parent transid verify failed on 2853827723264 wanted 29433 found 29435 > > > > parent transid verify failed on 2853827723264 wanted 29433 found 29435 > > > > Ignoring transid failure > > > > leaf parent key incorrect 2853827723264 > > > > ERROR: could not setup extent tree > > > > ERROR: cannot open file system > > > > > > btrfs insp dump-t -t 2853827723264 /dev/ > > > > # btrfs insp dump-t -t 2853827723264 /dev/mapper/xzy > > btrfs-progs v5.11 > > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > > Ignoring transid failure > > leaf parent key incorrect 2853827608576 > > WARNING: could not setup extent tree, skipping it > > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > > Ignoring transid failure > > leaf parent key incorrect 2853827608576 > > Couldn't setup device tree > > ERROR: unable to open /dev/mapper/xzy > > > > # btrfs insp dump-t -t 2853787942912 /dev/mapper/xzy > > btrfs-progs v5.11 > > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > > Ignoring transid failure > > leaf parent key incorrect 2853827608576 > > WARNING: could not setup extent tree, skipping it > > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > > Ignoring transid failure > > leaf parent key incorrect 2853827608576 > > Couldn't setup device tree > > ERROR: unable to open /dev/mapper/xzy > > > > # btrfs insp dump-t -t 2853827608576 /dev/mapper/xzy > > btrfs-progs v5.11 > > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > > Ignoring transid failure > > leaf parent key incorrect 2853827608576 > > WARNING: could not setup extent tree, skipping it > > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > > Ignoring transid failure > > leaf parent key incorrect 2853827608576 > > Couldn't setup device tree > > ERROR: unable to open /dev/mapper/xzy > > That does not look promising. I don't know whether a read-write mount > with usebackuproot will recover, or end up with problems. > > Options: > > a. btrfs check --repair > This probably fails on the same problem, it can't setup the extent tree. > > b. btrfs check --init-extent-tree > This is a heavy hammer, it might succeed, but takes a long time. On 5T > it might take double digit hours or even single digit days. It's > generally faster to just wipe the drive and restore from backups than > use init-extent-tree (I understand this *is* your backup). > > c. Setup an overlay file on device mapper, to redirect the writes from > a read-write mount with usebackup root. I think it's sufficient to > just mount, optionally write some files (empty or not), and umount. > Then do a btrfs check to see if the current tree is healthy. > https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID#Making_the_harddisks_read-only_using_an_overlay_file > > That guide is a bit complex to deal with many drives with mdadm raid, > so you can simplify it for just one drive. The gist is no writes go to > the drive itself, it's treated as read-only by device-mapper (in fact > you can optionally add a pre-step with the blockdev command and > --setro to make sure the entire drive is read-only; just make sure to > make it rw once you're done testing). All the writes with this overlay > go into a loop mounted file which you intentionally just throw away > after testing. > > d. Just skip the testing and try usebackuproot with a read-write > mount. It might make things worse, but at least it's fast to test. If > it messes things up, you'll have to recreate this backup from scratch. I took this approach. My command was simply: mount -o usebackuproot /dev/mapper/xzy /backup It appears to have succeeded because it mounted without errors. I completed a new incremental backup (with btrbk) and it finished without errors. I'll be pleased if my backup hist
Re: parent transid verify failed / ERROR: could not setup extent tree
On Mon, Mar 22, 2021 at 12:32 AM Dave T wrote: > > On Sun, Mar 21, 2021 at 2:03 PM Chris Murphy wrote: > > > > On Sat, Mar 20, 2021 at 11:54 PM Dave T wrote: > > > > > > # btrfs check -r 2853787942912 /dev/mapper/xyz > > > Opening filesystem to check... > > > parent transid verify failed on 2853787942912 wanted 29436 found 29433 > > > parent transid verify failed on 2853787942912 wanted 29436 found 29433 > > > parent transid verify failed on 2853787942912 wanted 29436 found 29433 > > > Ignoring transid failure > > > parent transid verify failed on 2853827723264 wanted 29433 found 29435 > > > parent transid verify failed on 2853827723264 wanted 29433 found 29435 > > > parent transid verify failed on 2853827723264 wanted 29433 found 29435 > > > Ignoring transid failure > > > leaf parent key incorrect 2853827723264 > > > ERROR: could not setup extent tree > > > ERROR: cannot open file system > > > > btrfs insp dump-t -t 2853827723264 /dev/ > > # btrfs insp dump-t -t 2853827723264 /dev/mapper/xzy > btrfs-progs v5.11 > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > Ignoring transid failure > leaf parent key incorrect 2853827608576 > WARNING: could not setup extent tree, skipping it > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > Ignoring transid failure > leaf parent key incorrect 2853827608576 > Couldn't setup device tree > ERROR: unable to open /dev/mapper/xzy > > # btrfs insp dump-t -t 2853787942912 /dev/mapper/xzy > btrfs-progs v5.11 > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > Ignoring transid failure > leaf parent key incorrect 2853827608576 > WARNING: could not setup extent tree, skipping it > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > Ignoring transid failure > leaf parent key incorrect 2853827608576 > Couldn't setup device tree > ERROR: unable to open /dev/mapper/xzy > > # btrfs insp dump-t -t 2853827608576 /dev/mapper/xzy > btrfs-progs v5.11 > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > Ignoring transid failure > leaf parent key incorrect 2853827608576 > WARNING: could not setup extent tree, skipping it > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > Ignoring transid failure > leaf parent key incorrect 2853827608576 > Couldn't setup device tree > ERROR: unable to open /dev/mapper/xzy That does not look promising. I don't know whether a read-write mount with usebackuproot will recover, or end up with problems. Options: a. btrfs check --repair This probably fails on the same problem, it can't setup the extent tree. b. btrfs check --init-extent-tree This is a heavy hammer, it might succeed, but takes a long time. On 5T it might take double digit hours or even single digit days. It's generally faster to just wipe the drive and restore from backups than use init-extent-tree (I understand this *is* your backup). c. Setup an overlay file on device mapper, to redirect the writes from a read-write mount with usebackup root. I think it's sufficient to just mount, optionally write some files (empty or not), and umount. Then do a btrfs check to see if the current tree is healthy. https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID#Making_the_harddisks_read-only_using_an_overlay_file That guide is a bit complex to deal with many drives with mdadm raid, so you can simplify it for just one drive. The gist is no writes go to the drive itself, it's treated as read-only by device-mapper (in fact you can optionally add a pre-step with the blockdev command and --setro to make sure the entire drive is read-only; just make sure to make it rw once you're done testing). All the writes with this overlay go into a loop mounted file which you intentionally just throw away after testing. d. Just skip the testing and try usebackuproot with a read-write mount. It might make things worse, but at least it's fast to test. If it messes things up, you'll have to recreate this backup from scratch. As for how to prevent this? I'm not sure. About the best we can do is disable the drive write cache with a udev rule, and/or raid1 with another make/model drive, and let Btrfs detect occasional corruption and self heal from the good copy. Another obvious way to avoid the problem is, stop having power failures, crashes, and accidental USB cable disconnections :) It's not any one thing that's the problem. It's a sequence of problems happening in just the right (or wrong) order that causes the problem. Bugs + mistake +
Re: parent transid verify failed / ERROR: could not setup extent tree
On Sun, Mar 21, 2021 at 2:03 PM Chris Murphy wrote: > > On Sat, Mar 20, 2021 at 11:54 PM Dave T wrote: > > > > # btrfs check -r 2853787942912 /dev/mapper/xyz > > Opening filesystem to check... > > parent transid verify failed on 2853787942912 wanted 29436 found 29433 > > parent transid verify failed on 2853787942912 wanted 29436 found 29433 > > parent transid verify failed on 2853787942912 wanted 29436 found 29433 > > Ignoring transid failure > > parent transid verify failed on 2853827723264 wanted 29433 found 29435 > > parent transid verify failed on 2853827723264 wanted 29433 found 29435 > > parent transid verify failed on 2853827723264 wanted 29433 found 29435 > > Ignoring transid failure > > leaf parent key incorrect 2853827723264 > > ERROR: could not setup extent tree > > ERROR: cannot open file system > > btrfs insp dump-t -t 2853827723264 /dev/ # btrfs insp dump-t -t 2853827723264 /dev/mapper/xzy btrfs-progs v5.11 parent transid verify failed on 2853827608576 wanted 29436 found 29433 parent transid verify failed on 2853827608576 wanted 29436 found 29433 parent transid verify failed on 2853827608576 wanted 29436 found 29433 Ignoring transid failure leaf parent key incorrect 2853827608576 WARNING: could not setup extent tree, skipping it parent transid verify failed on 2853827608576 wanted 29436 found 29433 Ignoring transid failure leaf parent key incorrect 2853827608576 Couldn't setup device tree ERROR: unable to open /dev/mapper/xzy # btrfs insp dump-t -t 2853787942912 /dev/mapper/xzy btrfs-progs v5.11 parent transid verify failed on 2853827608576 wanted 29436 found 29433 parent transid verify failed on 2853827608576 wanted 29436 found 29433 parent transid verify failed on 2853827608576 wanted 29436 found 29433 Ignoring transid failure leaf parent key incorrect 2853827608576 WARNING: could not setup extent tree, skipping it parent transid verify failed on 2853827608576 wanted 29436 found 29433 Ignoring transid failure leaf parent key incorrect 2853827608576 Couldn't setup device tree ERROR: unable to open /dev/mapper/xzy # btrfs insp dump-t -t 2853827608576 /dev/mapper/xzy btrfs-progs v5.11 parent transid verify failed on 2853827608576 wanted 29436 found 29433 parent transid verify failed on 2853827608576 wanted 29436 found 29433 parent transid verify failed on 2853827608576 wanted 29436 found 29433 Ignoring transid failure leaf parent key incorrect 2853827608576 WARNING: could not setup extent tree, skipping it parent transid verify failed on 2853827608576 wanted 29436 found 29433 Ignoring transid failure leaf parent key incorrect 2853827608576 Couldn't setup device tree ERROR: unable to open /dev/mapper/xzy > > > It appears the backup root is already stale. > > I'm not sure. If you can post the contents of that leaf (I don't think > it will contain filenames but double check) Qu might have an idea if > it's safe to try a read-write mount with -o usebackuproot without > causing problems later. > > > > What you eventually need to look at is what precipitated the transid > > > failures, and avoid it. > > > > The USB drive was disconnected by the user (an accident). I have other > > devices with the same hardware that have never experienced this issue. > > > > Do you have further ideas or suggestions I can try? Thank you for your > > time and for sharing your expertise. > > The drive could be getting write ordering wrong all the time, and it > only turns into a problem with a crash, power fail, or accidental > disconnect. More common is the write ordering is only sometimes > wrong, and a crash or powerfail is usually survivable, but leads to a > false sense of security about the drive. > > The simple theory of write order is data->metadata->sync->super->sync. > It shouldn't ever be the case that a newer superblock generation is on > stable media before the metadata it points to. > The drive is a Western Digital Elements 5TB. I searched a bit on write order under Linux, but I did not find any helpful articles regarding any configuration changes I could make. Is this purely a hardware issue, or are there steps I can take to ensure the correct write ordering? Thank you!
Re: parent transid verify failed / ERROR: could not setup extent tree
On Sat, Mar 20, 2021 at 11:54 PM Dave T wrote: > > # btrfs check -r 2853787942912 /dev/mapper/xyz > Opening filesystem to check... > parent transid verify failed on 2853787942912 wanted 29436 found 29433 > parent transid verify failed on 2853787942912 wanted 29436 found 29433 > parent transid verify failed on 2853787942912 wanted 29436 found 29433 > Ignoring transid failure > parent transid verify failed on 2853827723264 wanted 29433 found 29435 > parent transid verify failed on 2853827723264 wanted 29433 found 29435 > parent transid verify failed on 2853827723264 wanted 29433 found 29435 > Ignoring transid failure > leaf parent key incorrect 2853827723264 > ERROR: could not setup extent tree > ERROR: cannot open file system btrfs insp dump-t -t 2853827723264 /dev/ > It appears the backup root is already stale. I'm not sure. If you can post the contents of that leaf (I don't think it will contain filenames but double check) Qu might have an idea if it's safe to try a read-write mount with -o usebackuproot without causing problems later. > > What you eventually need to look at is what precipitated the transid > > failures, and avoid it. > > The USB drive was disconnected by the user (an accident). I have other > devices with the same hardware that have never experienced this issue. > > Do you have further ideas or suggestions I can try? Thank you for your > time and for sharing your expertise. The drive could be getting write ordering wrong all the time, and it only turns into a problem with a crash, power fail, or accidental disconnect. More common is the write ordering is only sometimes wrong, and a crash or powerfail is usually survivable, but leads to a false sense of security about the drive. The simple theory of write order is data->metadata->sync->super->sync. It shouldn't ever be the case that a newer superblock generation is on stable media before the metadata it points to. -- Chris Murphy
RE: parent transid verify failed / ERROR: could not setup extent tree
On Sat, Mar 20, 2021 at 10:04 PM Chris Murphy wrote: > > On Sat, Mar 20, 2021 at 5:15 AM Dave T wrote: > > > > I hope to get some expert advice before I proceed. I don't want to > > make things worse. Here's my situation now: > > > > This problem is with an external USB drive and it is encrypted. > > cryptsetup open succeeds. But mount fails.k > > > > mount /backup > > mount: /backup: wrong fs type, bad option, bad superblock on > > /dev/mapper/xusbluks, missing codepage or helper program, or other > > error. > > > > Next the following command succeeds: > > > > mount -o ro,recovery /dev/mapper/xusbluks /backup > > > > This is my backup disk (5TB), and I don't have another 5TB disk to > > copy all the data to. I hope I can fix the issue without losing my > > backups. > > > > Next step I did: > > > > # btrfs check /dev/mapper/xyz > > Opening filesystem to check... > > parent transid verify failed on 2853827608576 wanted 29436 found > > 29433 > > parent transid verify failed on 2853827608576 wanted 29436 found > > 29433 > > parent transid verify failed on 2853827608576 wanted 29436 found > > 29433 > > Ignoring transid failure > > leaf parent key incorrect 2853827608576 > > ERROR: could not setup extent tree > > ERROR: cannot open file system > > > From your superblock: > > backup 2: > backup_tree_root: 2853787942912 gen: 29433 > level: 1 > > Do this: > > btrfs check -r 2853787942912 /dev/xyz > > If it comes up clean it's safe to do: mount -o usebackuproot, without > needing to use ro. And in that case it'll self recover. You will lose > some data, between the commits. It is possible there's partial loss, > so it's not enough to just do a scrub, you'll want to freshen the > backups as well - if that's what was happening at the time that the > trouble happened (the trouble causing the subsequent transid > failures). > > Sometimes backup roots are already stale and inconsistent due to > overwrites, so the btrfs check might find problems with that older > root. # btrfs check -r 2853787942912 /dev/mapper/xyz Opening filesystem to check... parent transid verify failed on 2853787942912 wanted 29436 found 29433 parent transid verify failed on 2853787942912 wanted 29436 found 29433 parent transid verify failed on 2853787942912 wanted 29436 found 29433 Ignoring transid failure parent transid verify failed on 2853827723264 wanted 29433 found 29435 parent transid verify failed on 2853827723264 wanted 29433 found 29435 parent transid verify failed on 2853827723264 wanted 29433 found 29435 Ignoring transid failure leaf parent key incorrect 2853827723264 ERROR: could not setup extent tree ERROR: cannot open file system It appears the backup root is already stale. > > What you eventually need to look at is what precipitated the transid > failures, and avoid it. The USB drive was disconnected by the user (an accident). I have other devices with the same hardware that have never experienced this issue. Do you have further ideas or suggestions I can try? Thank you for your time and for sharing your expertise.
Re: parent transid verify failed / ERROR: could not setup extent tree
On Sat, Mar 20, 2021 at 5:15 AM Dave T wrote: > > I hope to get some expert advice before I proceed. I don't want to > make things worse. Here's my situation now: > > This problem is with an external USB drive and it is encrypted. > cryptsetup open succeeds. But mount fails.k > > mount /backup > mount: /backup: wrong fs type, bad option, bad superblock on > /dev/mapper/xusbluks, missing codepage or helper program, or other > error. > > Next the following command succeeds: > > mount -o ro,recovery /dev/mapper/xusbluks /backup > > This is my backup disk (5TB), and I don't have another 5TB disk to > copy all the data to. I hope I can fix the issue without losing my > backups. > > Next step I did: > > # btrfs check /dev/mapper/xyz > Opening filesystem to check... > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > Ignoring transid failure > leaf parent key incorrect 2853827608576 > ERROR: could not setup extent tree > ERROR: cannot open file system >From your superblock: backup 2: backup_tree_root: 2853787942912 gen: 29433 level: 1 Do this: btrfs check -r 2853787942912 /dev/xyz If it comes up clean it's safe to do: mount -o usebackuproot, without needing to use ro. And in that case it'll self recover. You will lose some data, between the commits. It is possible there's partial loss, so it's not enough to just do a scrub, you'll want to freshen the backups as well - if that's what was happening at the time that the trouble happened (the trouble causing the subsequent transid failures). Sometimes backup roots are already stale and inconsistent due to overwrites, so the btrfs check might find problems with that older root. What you eventually need to look at is what precipitated the transid failures, and avoid it. Typical is a drive firmware bug where it gets write ordering wrong and then there's a crash or power fail. Possibly one way to work around the bug is disabling the drive's write cache (use a udev rule to make sure it's always applied). Another way is add a different make/model drive to it, and convert to raid1 profile. And hopefully they won't have overlapping firmware bugs. -- Chris Murphy
Re: parent transid verify failed / ERROR: could not setup extent tree
On Sat, Mar 20, 2021 at 2:33 AM Dave T wrote: > > I hope to get some expert advice before I proceed. I don't want to > make things worse. Here's my situation now: > > This problem is with an external USB drive and it is encrypted. > cryptsetup open succeeds. But mount fails.k > > mount /backup > mount: /backup: wrong fs type, bad option, bad superblock on > /dev/mapper/xusbluks, missing codepage or helper program, or other > error. > > Next the following command succeeds: > > mount -o ro,recovery /dev/mapper/xusbluks /backup > > This is my backup disk (5TB), and I don't have another 5TB disk to > copy all the data to. I hope I can fix the issue without losing my > backups. > > Next step I did: > > # btrfs check /dev/mapper/xyz > Opening filesystem to check... > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > parent transid verify failed on 2853827608576 wanted 29436 found 29433 > Ignoring transid failure > leaf parent key incorrect 2853827608576 > ERROR: could not setup extent tree > ERROR: cannot open file system > > BTW, this command returns no result: > > which btrfs-zero-log > > I don't have that script/application installed. I'm running Arch Linux. I have > > core/btrfs-progs 5.11-1 > llinux 5.11.7-arch1-1 I'm following up my own post with additional data. I read some other threads that requested this, so I thought I could proactively include it. # btrfs insp dump-s /dev/mapper/xzy superblock: bytenr=65536, device=/dev/mapper/xzy - csum_type 0 (crc32c) csum_size 4 csum0x44b6abfd [match] bytenr 65536 flags 0x1 ( WRITTEN ) magic _BHRfS_M [match] fside23b0b43-0c36-4c7d-b9e1-e821acb259be metadata_uuid e23b0b43-0c36-4c7d-b9e1-e821acb259be label usb_backup generation 29436 root2853792677888 sys_array_size 129 chunk_root_generation 29396 root_level 1 chunk_root 22052864 chunk_root_level1 log_root0 log_root_transid0 log_root_level 0 total_bytes 5000928428032 bytes_used 2822988496896 sectorsize 4096 nodesize16384 leafsize (deprecated) 16384 stripesize 4096 root_dir6 num_devices 1 compat_flags0x0 compat_ro_flags 0x0 incompat_flags 0x169 ( MIXED_BACKREF | COMPRESS_LZO | BIG_METADATA | EXTENDED_IREF | SKINNY_METADATA ) cache_generation29436 uuid_tree_generation29436 dev_item.uuid b98c68ff-2e12-41c4-97d3-81d488175dcd dev_item.fsid e23b0b43-0c36-4c7d-b9e1-e821acb259be [match] dev_item.type 0 dev_item.total_bytes5000928428032 dev_item.bytes_used 2848662224896 dev_item.io_align 4096 dev_item.io_width 4096 dev_item.sector_size4096 dev_item.devid 1 dev_item.dev_group 0 dev_item.seek_speed 0 dev_item.bandwidth 0 dev_item.generation 0 # btrfs inspect-internal dump-super --full /dev/mapper/xzy superblock: bytenr=65536, device=/dev/mapper/xzy - csum_type 0 (crc32c) csum_size 4 csum0x44b6abfd [match] bytenr 65536 flags 0x1 ( WRITTEN ) magic _BHRfS_M [match] fside23b0b43-0c36-4c7d-b9e1-e821acb259be metadata_uuid e23b0b43-0c36-4c7d-b9e1-e821acb259be label usb_backup generation 29436 root2853792677888 sys_array_size 129 chunk_root_generation 29396 root_level 1 chunk_root 22052864 chunk_root_level1 log_root0 log_root_transid0 log_root_level 0 total_bytes 5000928428032 bytes_used 2822988496896 sectorsize 4096 nodesize16384 leafsize (deprecated) 16384 stripesize 4096 root_dir6 num_devices 1 compat_flags0x0 compat_ro_flags 0x0 incompat_flags 0x169 ( MIXED_BACKREF | COMPRESS_LZO | BIG_METADATA | EXTENDED_IREF | SKINNY_METADATA ) cache_generation29436 uuid_tree_generation29436 dev_item.uuid b98c68ff-2e12-41c4-97d3-81d488175dcd dev_item.fsid e23b0b43-0c36-
