Re: kernel BUG at fs/btrfs/extent-tree.c:5038 (linux 3.4.7)
Note that this FS still be unmountable with last for-linus branch. Aug 27 10:47:33 backup2 kernel: [987464.600465] device fsid a5dfe512-c8a3-46f0-bc8c-6365b8eccdcb devid 1 transid 110425 /dev/mapper/vg--backupplug-backup Aug 27 10:47:33 backup2 kernel: [987464.601701] btrfs: force zlib compression Aug 27 10:47:33 backup2 kernel: [987464.601709] btrfs: not using ssd allocation scheme Aug 27 10:47:33 backup2 kernel: [987464.691331] parent transid verify failed on 615015833600 wanted 110423 found 110424 Aug 27 10:47:33 backup2 kernel: [987464.699658] parent transid verify failed on 615015833600 wanted 110423 found 110424 Aug 27 10:47:33 backup2 kernel: [987464.700093] btrfs read error corrected: ino 1 off 615015833600 (dev /dev/mapper/vg--backupplug-backup sector 1209083504) Aug 27 10:47:33 backup2 kernel: [987464.700107] Failed to read block groups: -5 Aug 27 10:47:33 backup2 kernel: [987464.720816] btrfs: open_ctree failed On 01/08/2012 21:48, Olivier Bonvalet wrote: Hi, I have some trouble with a btrfs filesystem. As you can see in logs, there is lines which are from btrfs (I supposed), then some warnings at fs/btrfs/extent-tree.c, and finally a kernel BUG at fs/btrfs/extent-tree.c:5038. Do you need more informations ? Aug 1 21:23:10 backup2 kernel: [7.015184] Btrfs loaded Aug 1 21:23:10 backup2 kernel: [7.023314] device fsid a5dfe512-c8a3-46f0-bc8c-6365b8eccdcb devid 1 transid 110423 /dev/mapper/vg--backupplug-backup Aug 1 21:23:10 backup2 kernel: [7.024405] btrfs: force zlib compression Aug 1 21:23:10 backup2 kernel: [7.024414] btrfs: not using ssd allocation scheme Aug 1 21:23:10 backup2 kernel: [ 17.938241] NET: Registered protocol family 10 Aug 1 21:26:53 backup2 kernel: [ 28.880027] eth0: no IPv6 routers present Aug 1 21:33:39 backup2 kernel: [ 435.285128] leaf 615015878656 total ptrs 28 free space 1651 Aug 1 21:33:39 backup2 kernel: [ 435.285146] item 0 key (642867957760 a8 4096) itemoff 3944 itemsize 51 Aug 1 21:33:39 backup2 kernel: [ 435.285153] extent refs 1 gen 108436 flags 2 Aug 1 21:33:39 backup2 kernel: [ 435.285162] tree block key (18446744073709551606 80 1215799304192) level 0 Aug 1 21:33:39 backup2 kernel: [ 435.285171] tree block backref root 7 Aug 1 21:33:39 backup2 kernel: [ 435.285179] item 1 key (642867970048 a8 4096) itemoff 3893 itemsize 51 Aug 1 21:33:39 backup2 kernel: [ 435.285186] extent refs 1 gen 38936 flags 258 Aug 1 21:33:39 backup2 kernel: [ 435.285196] tree block key (401571 54 2912287038) level 0 Aug 1 21:33:39 backup2 kernel: [ 435.285202] shared block backref parent 615081041920 Aug 1 21:33:39 backup2 kernel: [ 435.285208] item 2 key (642867994624 a8 4096) itemoff 3824 itemsize 69 Aug 1 21:33:39 backup2 kernel: [ 435.285214] extent refs 3 gen 38909 flags 258 Aug 1 21:33:39 backup2 kernel: [ 435.285221] tree block key (13092 c 12250) level 0 Aug 1 21:33:39 backup2 kernel: [ 435.285226] shared block backref parent 1306797543424 Aug 1 21:33:39 backup2 kernel: [ 435.285231] shared block backref parent 1306797494272 Aug 1 21:33:39 backup2 kernel: [ 435.285236] shared block backref parent 647007399936 Aug 1 21:33:39 backup2 kernel: [ 435.285242] item 3 key (642868002816 a8 4096) itemoff 3773 itemsize 51 Aug 1 21:33:39 backup2 kernel: [ 435.285248] extent refs 1 gen 44304 flags 2 Aug 1 21:33:39 backup2 kernel: [ 435.285255] tree block key (1824364519424 a8 94208) level 0 Aug 1 21:33:39 backup2 kernel: [ 435.285260] tree block backref root 2 Aug 1 21:33:39 backup2 kernel: [ 435.285265] item 4 key (642868006912 a8 4096) itemoff 3722 itemsize 51 Aug 1 21:33:39 backup2 kernel: [ 435.285271] extent refs 1 gen 44304 flags 2 Aug 1 21:33:39 backup2 kernel: [ 435.285278] tree block key (1824369225728 a8 118784) level 0 Aug 1 21:33:39 backup2 kernel: [ 435.285284] tree block backref root 2 Aug 1 21:33:39 backup2 kernel: [ 435.285289] item 5 key (642868011008 a8 4096) itemoff 3671 itemsize 51 Aug 1 21:33:39 backup2 kernel: [ 435.285295] extent refs 1 gen 101712 flags 258 Aug 1 21:33:39 backup2 kernel: [ 435.285302] tree block key (833 6c 162816000) level 0 Aug 1 21:33:39 backup2 kernel: [ 435.285307] shared block backref parent 617940144128 Aug 1 21:33:39 backup2 kernel: [ 435.285313] item 6 key (642868015104 a8 4096) itemoff 3593 itemsize 78 Aug 1 21:33:39 backup2 kernel: [ 435.285321] extent refs 4 gen 38909 flags 258 Aug 1 21:33:39 backup2 kernel: [ 435.285326] tree block key (17721 60 119) level 0 Aug 1 21:33:39 backup2 kernel: [ 435.285331] shared block backref parent 1314062098432 Aug 1 21:33:39 backup2 kernel: [ 435.285336] shared block backref parent 1314062094336 Aug 1 21:33:39 backup2 kernel: [ 435.285341]
Re: kernel BUG at fs/btrfs/extent-tree.c:5038 (linux 3.4.7)
On Sun, Aug 05, 2012 at 04:11:47PM +0200, Olivier Bonvalet wrote: On 05/08/2012 10:57, Chris Samuel wrote: On 08/04/2012 08:41 AM, Olivier Bonvalet wrote: Is there something I can do to fix that ? (the mount option recovery didn't help here) I've seen someone (perhaps Marc Merlin) report that the 3.5.x kernel was able to mount a filesystem that 3.4.x couldn't, so it might be worth a shot here! Thanks for the idea, but same result : Aug 5 16:10:12 backup2 kernel: [ 58.630481] device fsid a5dfe512-c8a3-46f0-bc8c-6365b8eccdcb devid 1 transid 110425 /dev/mapper/vg--backupplug-backup Aug 5 16:10:12 backup2 kernel: [ 58.631346] btrfs: force zlib compression Aug 5 16:10:12 backup2 kernel: [ 58.631357] btrfs: not using ssd allocation scheme Aug 5 16:10:12 backup2 kernel: [ 58.631366] btrfs: enabling auto recovery Aug 5 16:10:12 backup2 kernel: [ 58.670972] btrfs: no dev_stats entry found for device /dev/mapper/vg--backupplug-backup (devid 1) (OK on first mount after mkfs) Aug 5 16:10:12 backup2 kernel: [ 58.674758] parent transid verify failed on 615015833600 wanted 110423 found 110424 Aug 5 16:10:12 backup2 kernel: [ 58.675090] parent transid verify failed on 615015833600 wanted 110423 found 110424 Aug 5 16:10:12 backup2 kernel: [ 58.675523] btrfs read error corrected: ino 1 off 615015833600 (dev /dev/mapper/vg--backupplug-backup sector 1209083504) This looks strange, the the corrupted block belongs to metadata, I assume you have the DUP profile, so there is a good copy that can be used instead, the error message confirms that, but ... Aug 5 16:10:12 backup2 kernel: [ 58.675536] Failed to read block groups: -5 ... ? -5 means EIO, which is returned when a block cannot be read, so unless there's a different reason for it, this looks like a missed oportunity to fix an error and continue. The same error messages are present in the logs from 3.4 version. Aug 5 16:10:12 backup2 kernel: [ 58.704720] btrfs: open_ctree failed -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG at fs/btrfs/extent-tree.c:5038 (linux 3.4.7)
On Wed, 8 Aug 2012 16:45:57 +0200, David Sterba wrote: On Sun, Aug 05, 2012 at 04:11:47PM +0200, Olivier Bonvalet wrote: Aug 5 16:10:12 backup2 kernel: [ 58.674758] parent transid verify failed on 615015833600 wanted 110423 found 110424 1st mirror fails verify_parent_transid(). Aug 5 16:10:12 backup2 kernel: [ 58.675090] parent transid verify failed on 615015833600 wanted 110423 found 110424 2nd mirror fails verify_parent_transid(). Aug 5 16:10:12 backup2 kernel: [ 58.675523] btrfs read error corrected: ino 1 off 615015833600 (dev /dev/mapper/vg--backupplug-backup sector 1209083504) That's a bug. It is wrong to ignore the previous results from verify_parent_transid() and to call repair_eb_io_failure() which rewrites one mirror and claims to have corrected an error. But it's not a major issue, just a misleading message in the kernel log and a disk write operation which does not repair anything. This looks strange, the the corrupted block belongs to metadata, I assume you have the DUP profile, so there is a good copy that can be used instead, the error message confirms that, but ... Aug 5 16:10:12 backup2 kernel: [ 58.675536] Failed to read block groups: -5 That's correct, because the UPTODATE flag in the extent is not set (verify_parent_transid() clears it when it detects an error). ... ? -5 means EIO, which is returned when a block cannot be read, so unless there's a different reason for it, this looks like a missed oportunity to fix an error and continue. The same error messages are present in the logs from 3.4 version. Aug 5 16:10:12 backup2 kernel: [ 58.704720] btrfs: open_ctree failed The summary is that the block was not correctable, both mirrors had the same old transid. The bug is that the call to repair_io_failure() should not have been done because verify_parent_transid() indicated errors. I'll prepare a patch for it. Changing btree_read_extent_buffer_pages() to set ret to -EIO if verify_parent_transid() fails should fix the issue. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG at fs/btrfs/extent-tree.c:5038 (linux 3.4.7)
On 08/04/2012 08:41 AM, Olivier Bonvalet wrote: Is there something I can do to fix that ? (the mount option recovery didn't help here) I've seen someone (perhaps Marc Merlin) report that the 3.5.x kernel was able to mount a filesystem that 3.4.x couldn't, so it might be worth a shot here! Best of luck, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG at fs/btrfs/extent-tree.c:5038 (linux 3.4.7)
On 05/08/2012 10:57, Chris Samuel wrote: On 08/04/2012 08:41 AM, Olivier Bonvalet wrote: Is there something I can do to fix that ? (the mount option recovery didn't help here) I've seen someone (perhaps Marc Merlin) report that the 3.5.x kernel was able to mount a filesystem that 3.4.x couldn't, so it might be worth a shot here! Best of luck, Chris Thanks for the idea, but same result : Aug 5 16:10:12 backup2 kernel: [ 58.630481] device fsid a5dfe512-c8a3-46f0-bc8c-6365b8eccdcb devid 1 transid 110425 /dev/mapper/vg--backupplug-backup Aug 5 16:10:12 backup2 kernel: [ 58.631346] btrfs: force zlib compression Aug 5 16:10:12 backup2 kernel: [ 58.631357] btrfs: not using ssd allocation scheme Aug 5 16:10:12 backup2 kernel: [ 58.631366] btrfs: enabling auto recovery Aug 5 16:10:12 backup2 kernel: [ 58.670972] btrfs: no dev_stats entry found for device /dev/mapper/vg--backupplug-backup (devid 1) (OK on first mount after mkfs) Aug 5 16:10:12 backup2 kernel: [ 58.674758] parent transid verify failed on 615015833600 wanted 110423 found 110424 Aug 5 16:10:12 backup2 kernel: [ 58.675090] parent transid verify failed on 615015833600 wanted 110423 found 110424 Aug 5 16:10:12 backup2 kernel: [ 58.675523] btrfs read error corrected: ino 1 off 615015833600 (dev /dev/mapper/vg--backupplug-backup sector 1209083504) Aug 5 16:10:12 backup2 kernel: [ 58.675536] Failed to read block groups: -5 Aug 5 16:10:12 backup2 kernel: [ 58.704720] btrfs: open_ctree failed -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG at fs/btrfs/extent-tree.c:5038 (linux 3.4.7)
On 02/08/2012 18:18, Olivier Bonvalet wrote: On 02/08/2012 15:53, David Sterba wrote: On Thu, Aug 02, 2012 at 03:41:03PM +0200, Olivier Bonvalet wrote: Yes... it's a copy from my /var/log/kern.log. Is it really disabled ? I was mistaken, it really is enabled unconditionally in ctree.h:55. Josef says that the V0 extent refs are not used for a long time, so the question is how did they appear in your filesystem. Did you switch to a new kernel from a very old one? david -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html mmm I have upgraded that system every two months, but the first setup is from april 2011 I think. Should I start a scrub on all that systems installed a long time ago ? -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html So after a hard reboot that filesystem is not mountable anymore : Aug 4 00:40:06 backup2 kernel: [ 614.826124] device fsid a5dfe512-c8a3-46f0-bc8c-6365b8eccdcb devid 1 transid 110423 /dev/mapper/vg--backupplug-backup Aug 4 00:40:06 backup2 kernel: [ 614.827934] btrfs: force zlib compression Aug 4 00:40:06 backup2 kernel: [ 614.827943] btrfs: not using ssd allocation scheme Aug 4 00:40:06 backup2 kernel: [ 614.827950] btrfs: enabling auto recoveryparent transid verify failed on 615015833600 wanted 110423 found 110424 Aug 4 00:40:06 backup2 kernel: [ 614.933613] parent transid verify failed on 615015833600 wanted 110423 found 110424 Aug 4 00:40:06 backup2 kernel: [ 614.934700] btrfs read error corrected: ino 1 off 615015833600 (dev /dev/mapper/vg--backupplug-backup sector 1209083504) Aug 4 00:40:06 backup2 kernel: [ 614.934716] Failed to read block groups: -5 Aug 4 00:40:07 backup2 kernel: [ 614.952684] btrfs: open_ctree failed Is there something I can do to fix that ? (the mount option recovery didn't help here) thanks, Olivier -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG at fs/btrfs/extent-tree.c:5038 (linux 3.4.7)
On 04/08/2012 00:41, Olivier Bonvalet wrote: On 02/08/2012 18:18, Olivier Bonvalet wrote: On 02/08/2012 15:53, David Sterba wrote: On Thu, Aug 02, 2012 at 03:41:03PM +0200, Olivier Bonvalet wrote: Yes... it's a copy from my /var/log/kern.log. Is it really disabled ? I was mistaken, it really is enabled unconditionally in ctree.h:55. Josef says that the V0 extent refs are not used for a long time, so the question is how did they appear in your filesystem. Did you switch to a new kernel from a very old one? david -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html mmm I have upgraded that system every two months, but the first setup is from april 2011 I think. Should I start a scrub on all that systems installed a long time ago ? -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html So after a hard reboot that filesystem is not mountable anymore : Aug 4 00:40:06 backup2 kernel: [ 614.826124] device fsid a5dfe512-c8a3-46f0-bc8c-6365b8eccdcb devid 1 transid 110423 /dev/mapper/vg--backupplug-backup Aug 4 00:40:06 backup2 kernel: [ 614.827934] btrfs: force zlib compression Aug 4 00:40:06 backup2 kernel: [ 614.827943] btrfs: not using ssd allocation scheme Aug 4 00:40:06 backup2 kernel: [ 614.827950] btrfs: enabling auto recoveryparent transid verify failed on 615015833600 wanted 110423 found 110424 Aug 4 00:40:06 backup2 kernel: [ 614.933613] parent transid verify failed on 615015833600 wanted 110423 found 110424 Aug 4 00:40:06 backup2 kernel: [ 614.934700] btrfs read error corrected: ino 1 off 615015833600 (dev /dev/mapper/vg--backupplug-backup sector 1209083504) Aug 4 00:40:06 backup2 kernel: [ 614.934716] Failed to read block groups: -5 Aug 4 00:40:07 backup2 kernel: [ 614.952684] btrfs: open_ctree failed Is there something I can do to fix that ? (the mount option recovery didn't help here) thanks, Olivier -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html and btrfsck doesn't help : # btrfsck /dev/vg-backupplug/backup parent transid verify failed on 615015833600 wanted 110423 found 110424 Ignoring transid failure checking extents Extent back ref already exists for 615015841792 parent 0 root 2 bad block 615015841792 parent transid verify failed on 615015833600 wanted 110423 found 110424 Ignoring transid failure parent transid verify failed on 615015833600 wanted 110423 found 110424 Ignoring transid failure [...] parent transid verify failed on 615015866368 wanted 110423 found 110424 Ignoring transid failure leaf parent key incorrect 615015849984 bad block 615015849984 leaf parent key incorrect 615015858176 bad block 615015858176 parent transid verify failed on 615015833600 wanted 110423 found 110424 Ignoring transid failure [...] parent transid verify failed on 615015866368 wanted 110423 found 110424 Ignoring transid failure leaf parent key incorrect 615015866368 bad block 615015866368 parent transid verify failed on 615015833600 wanted 110423 found 110424 Ignoring transid failure btrfsck: disk-io.c:441: find_and_setup_root: Assertion `!(ret)' failed. Abandon # Data can be restored thanks to btrfs-restore tool ; but is there really no way to fix the filesystem ? (I also tried btrfs-zero-log) Olivier -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG at fs/btrfs/extent-tree.c:5038 (linux 3.4.7)
On 02/08/2012 15:22, David Sterba wrote:
On Wed, Aug 01, 2012 at 09:48:15PM +0200, Olivier Bonvalet wrote:
I have some trouble with a btrfs filesystem.
As you can see in logs, there is lines which are from btrfs (I
supposed), then some warnings at fs/btrfs/extent-tree.c, and finally a
kernel BUG at fs/btrfs/extent-tree.c:5038.
Did you really see this BUG ? It comes from some unused and disabled code:
5036 #ifdef BTRFS_COMPAT_EXTENT_TREE_V0
5037 if (item_size sizeof(*ei)) {
5038 BUG_ON(found_extent || extent_slot != path-slots[0]);
5039 ret = convert_extent_item_v0(trans, extent_root, path,
5040 owner_objectid, 0);
5041 if (ret 0)
5042 goto abort;
5043
5044 btrfs_release_path(path);
5045 path-leave_spinning = 1;
5046
5047 key.objectid = bytenr;
5048 key.type = BTRFS_EXTENT_ITEM_KEY;
5049 key.offset = num_bytes;
5050
5051 ret = btrfs_search_slot(trans, extent_root,key, path,
5052 -1, 1);
5053 if (ret) {
5054 printk(KERN_ERR umm, got %d back from search
5055, was looking for %llu\n, ret,
5056(unsigned long long)bytenr);
5057 btrfs_print_leaf(extent_root, path-nodes[0]);
5058 }
5059 if (ret 0)
5060 goto abort;
5061 extent_slot = path-slots[0];
5062 leaf = path-nodes[0];
5063 item_size = btrfs_item_size_nr(leaf, extent_slot);
5064 }
5065 #endif
david
Yes... it's a copy from my /var/log/kern.log. Is it really disabled ?
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG at fs/btrfs/extent-tree.c:5038 (linux 3.4.7)
On Thu, Aug 02, 2012 at 03:41:03PM +0200, Olivier Bonvalet wrote: Yes... it's a copy from my /var/log/kern.log. Is it really disabled ? I was mistaken, it really is enabled unconditionally in ctree.h:55. Josef says that the V0 extent refs are not used for a long time, so the question is how did they appear in your filesystem. Did you switch to a new kernel from a very old one? david -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG at fs/btrfs/extent-tree.c:5038 (linux 3.4.7)
On 02/08/2012 15:53, David Sterba wrote: On Thu, Aug 02, 2012 at 03:41:03PM +0200, Olivier Bonvalet wrote: Yes... it's a copy from my /var/log/kern.log. Is it really disabled ? I was mistaken, it really is enabled unconditionally in ctree.h:55. Josef says that the V0 extent refs are not used for a long time, so the question is how did they appear in your filesystem. Did you switch to a new kernel from a very old one? david -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html mmm I have upgraded that system every two months, but the first setup is from april 2011 I think. Should I start a scrub on all that systems installed a long time ago ? -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
kernel BUG at fs/btrfs/extent-tree.c:5038 (linux 3.4.7)
Hi, I have some trouble with a btrfs filesystem. As you can see in logs, there is lines which are from btrfs (I supposed), then some warnings at fs/btrfs/extent-tree.c, and finally a kernel BUG at fs/btrfs/extent-tree.c:5038. Do you need more informations ? Aug 1 21:23:10 backup2 kernel: [7.015184] Btrfs loaded Aug 1 21:23:10 backup2 kernel: [7.023314] device fsid a5dfe512-c8a3-46f0-bc8c-6365b8eccdcb devid 1 transid 110423 /dev/mapper/vg--backupplug-backup Aug 1 21:23:10 backup2 kernel: [7.024405] btrfs: force zlib compression Aug 1 21:23:10 backup2 kernel: [7.024414] btrfs: not using ssd allocation scheme Aug 1 21:23:10 backup2 kernel: [ 17.938241] NET: Registered protocol family 10 Aug 1 21:26:53 backup2 kernel: [ 28.880027] eth0: no IPv6 routers present Aug 1 21:33:39 backup2 kernel: [ 435.285128] leaf 615015878656 total ptrs 28 free space 1651 Aug 1 21:33:39 backup2 kernel: [ 435.285146] item 0 key (642867957760 a8 4096) itemoff 3944 itemsize 51 Aug 1 21:33:39 backup2 kernel: [ 435.285153] extent refs 1 gen 108436 flags 2 Aug 1 21:33:39 backup2 kernel: [ 435.285162] tree block key (18446744073709551606 80 1215799304192) level 0 Aug 1 21:33:39 backup2 kernel: [ 435.285171] tree block backref root 7 Aug 1 21:33:39 backup2 kernel: [ 435.285179] item 1 key (642867970048 a8 4096) itemoff 3893 itemsize 51 Aug 1 21:33:39 backup2 kernel: [ 435.285186] extent refs 1 gen 38936 flags 258 Aug 1 21:33:39 backup2 kernel: [ 435.285196] tree block key (401571 54 2912287038) level 0 Aug 1 21:33:39 backup2 kernel: [ 435.285202] shared block backref parent 615081041920 Aug 1 21:33:39 backup2 kernel: [ 435.285208] item 2 key (642867994624 a8 4096) itemoff 3824 itemsize 69 Aug 1 21:33:39 backup2 kernel: [ 435.285214] extent refs 3 gen 38909 flags 258 Aug 1 21:33:39 backup2 kernel: [ 435.285221] tree block key (13092 c 12250) level 0 Aug 1 21:33:39 backup2 kernel: [ 435.285226] shared block backref parent 1306797543424 Aug 1 21:33:39 backup2 kernel: [ 435.285231] shared block backref parent 1306797494272 Aug 1 21:33:39 backup2 kernel: [ 435.285236] shared block backref parent 647007399936 Aug 1 21:33:39 backup2 kernel: [ 435.285242] item 3 key (642868002816 a8 4096) itemoff 3773 itemsize 51 Aug 1 21:33:39 backup2 kernel: [ 435.285248] extent refs 1 gen 44304 flags 2 Aug 1 21:33:39 backup2 kernel: [ 435.285255] tree block key (1824364519424 a8 94208) level 0 Aug 1 21:33:39 backup2 kernel: [ 435.285260] tree block backref root 2 Aug 1 21:33:39 backup2 kernel: [ 435.285265] item 4 key (642868006912 a8 4096) itemoff 3722 itemsize 51 Aug 1 21:33:39 backup2 kernel: [ 435.285271] extent refs 1 gen 44304 flags 2 Aug 1 21:33:39 backup2 kernel: [ 435.285278] tree block key (1824369225728 a8 118784) level 0 Aug 1 21:33:39 backup2 kernel: [ 435.285284] tree block backref root 2 Aug 1 21:33:39 backup2 kernel: [ 435.285289] item 5 key (642868011008 a8 4096) itemoff 3671 itemsize 51 Aug 1 21:33:39 backup2 kernel: [ 435.285295] extent refs 1 gen 101712 flags 258 Aug 1 21:33:39 backup2 kernel: [ 435.285302] tree block key (833 6c 162816000) level 0 Aug 1 21:33:39 backup2 kernel: [ 435.285307] shared block backref parent 617940144128 Aug 1 21:33:39 backup2 kernel: [ 435.285313] item 6 key (642868015104 a8 4096) itemoff 3593 itemsize 78 Aug 1 21:33:39 backup2 kernel: [ 435.285321] extent refs 4 gen 38909 flags 258 Aug 1 21:33:39 backup2 kernel: [ 435.285326] tree block key (17721 60 119) level 0 Aug 1 21:33:39 backup2 kernel: [ 435.285331] shared block backref parent 1314062098432 Aug 1 21:33:39 backup2 kernel: [ 435.285336] shared block backref parent 1314062094336 Aug 1 21:33:39 backup2 kernel: [ 435.285341] shared block backref parent 1312740683776 Aug 1 21:33:39 backup2 kernel: [ 435.285348] shared block backref parent 1312740675584 Aug 1 21:33:39 backup2 kernel: [ 435.285354] item 7 key (642868019200 a8 4096) itemoff 3542 itemsize 51 Aug 1 21:33:39 backup2 kernel: [ 435.285360] extent refs 1 gen 44307 flags 2 Aug 1 21:33:39 backup2 kernel: [ 435.285365] tree block key (18446744073709551606 80 1825532395520) level 0 Aug 1 21:33:39 backup2 kernel: [ 435.285373] tree block backref root 7 Aug 1 21:33:39 backup2 kernel: [ 435.285378] item 8 key (642868023296 a8 4096) itemoff 3491 itemsize 51 Aug 1 21:33:39 backup2 kernel: [ 435.285384] extent refs 1 gen 101712 flags 258 Aug 1 21:33:39 backup2 kernel: [ 435.285389] tree block key (833 6c 161284096) level 0 Aug 1 21:33:39 backup2 kernel: [ 435.285396] shared block backref parent 617940144128 Aug 1 21:33:39 backup2 kernel: [ 435.285402] item
