linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: Chris Murphy <lists@colorremedies.com>
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: [bug] btrfs check clear-space-cache v1 corrupted file system
Date: Fri, 1 Mar 2019 19:54:53 -0700	[thread overview]
Message-ID: <CAJCQCtQvi77SZbL4_fK1B5jNRpYhWOHBQOKvZ2Pdr8AoJDBXBg@mail.gmail.com> (raw)
In-Reply-To: <CAJCQCtT+VnSp_8i-QWT6iwCv9yaqQv2XfsVtsdvQmoG70aQZ7w@mail.gmail.com>

OK this is screwy. The super has a totally different generation for
the root tree than any of the backup roots.

$ sudo btrfs rescue super -v /dev/mapper/sdd
All Devices:
    Device: id = 1, name = /dev/mapper/sdc
    Device: id = 2, name = /dev/mapper/sdd

Before Recovering:
    [All good supers]:
        device name = /dev/mapper/sdc
        superblock bytenr = 65536

        device name = /dev/mapper/sdc
        superblock bytenr = 67108864

        device name = /dev/mapper/sdc
        superblock bytenr = 274877906944

        device name = /dev/mapper/sdd
        superblock bytenr = 65536

        device name = /dev/mapper/sdd
        superblock bytenr = 67108864

        device name = /dev/mapper/sdd
        superblock bytenr = 274877906944

    [All bad supers]:

All supers are valid, no need to recover

$ sudo btrfs insp dump-s -f /dev/mapper/sdd
superblock: bytenr=65536, device=/dev/mapper/sdd
---------------------------------------------------------
csum_type        0 (crc32c)
csum_size        4
csum            0x312a8b5e [match]
bytenr            65536
flags            0x1
            ( WRITTEN )
magic            _BHRfS_M [match]
fsid            f5adc913-bbea-4340-8b5f-3411e2cda642
label            second
generation        4514
root            29392896
sys_array_size        258
chunk_root_generation    3823
root_level        1
chunk_root        822549151744
chunk_root_level    1
log_root        0
log_root_transid    0
log_root_level        0
total_bytes        1500308553728
bytes_used        735327125504
sectorsize        4096
nodesize        16384
leafsize (deprecated)        16384
stripesize        4096
root_dir        6
num_devices        2
compat_flags        0x0
compat_ro_flags        0x0
incompat_flags        0x161
            ( MIXED_BACKREF |
              BIG_METADATA |
              EXTENDED_IREF |
              SKINNY_METADATA )
cache_generation    4076
uuid_tree_generation    4076
dev_item.uuid        2fbaa023-7cf8-4f48-b4ed-c6e18c99d2bd
dev_item.fsid        f5adc913-bbea-4340-8b5f-3411e2cda642 [match]
dev_item.type        0
dev_item.total_bytes    750154276864
dev_item.bytes_used    737702576128
dev_item.io_align    4096
dev_item.io_width    4096
dev_item.sector_size    4096
dev_item.devid        2
dev_item.dev_group    0
dev_item.seek_speed    0
dev_item.bandwidth    0
dev_item.generation    0
sys_chunk_array[2048]:
    item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 20971520)
        length 8388608 owner 2 stripe_len 65536 type SYSTEM|RAID1
        io_align 65536 io_width 65536 sector_size 4096
        num_stripes 2 sub_stripes 0
            stripe 0 devid 2 offset 1048576
            dev_uuid 2fbaa023-7cf8-4f48-b4ed-c6e18c99d2bd
            stripe 1 devid 1 offset 20971520
            dev_uuid d071b0ca-1d27-48cb-826e-63c5e9972339
    item 1 key (FIRST_CHUNK_TREE CHUNK_ITEM 822549151744)
        length 33554432 owner 2 stripe_len 65536 type SYSTEM|RAID1
        io_align 65536 io_width 65536 sector_size 4096
        num_stripes 2 sub_stripes 1
            stripe 0 devid 2 offset 737670070272
            dev_uuid 2fbaa023-7cf8-4f48-b4ed-c6e18c99d2bd
            stripe 1 devid 1 offset 737689993216
            dev_uuid d071b0ca-1d27-48cb-826e-63c5e9972339
backup_roots[4]:
    backup 0:
        backup_tree_root:    931053568    gen: 4075    level: 1
        backup_chunk_root:    822549151744    gen: 3823    level: 1
        backup_extent_root:    931086336    gen: 4075    level: 2
        backup_fs_root:        537116672    gen: 3806    level: 0
        backup_dev_root:    721174528    gen: 3823    level: 1
        backup_csum_root:    932249600    gen: 4075    level: 2
        backup_total_bytes:    1500308553728
        backup_bytes_used:    735441764352
        backup_num_devices:    2

    backup 1:
        backup_tree_root:    930086912    gen: 4076    level: 1
        backup_chunk_root:    822549151744    gen: 3823    level: 1
        backup_extent_root:    930447360    gen: 4076    level: 2
        backup_fs_root:        537116672    gen: 3806    level: 0
        backup_dev_root:    930856960    gen: 4076    level: 1
        backup_csum_root:    932118528    gen: 4076    level: 2
        backup_total_bytes:    1500308553728
        backup_bytes_used:    735441764352
        backup_num_devices:    2

    backup 2:
        backup_tree_root:    930070528    gen: 4073    level: 1
        backup_chunk_root:    822549151744    gen: 3823    level: 1
        backup_extent_root:    930365440    gen: 4073    level: 2
        backup_fs_root:        537116672    gen: 3806    level: 0
        backup_dev_root:    721174528    gen: 3823    level: 1
        backup_csum_root:    931086336    gen: 4073    level: 2
        backup_total_bytes:    1500308553728
        backup_bytes_used:    735441764352
        backup_num_devices:    2

    backup 3:
        backup_tree_root:    930086912    gen: 4074    level: 1
        backup_chunk_root:    822549151744    gen: 3823    level: 1
        backup_extent_root:    930447360    gen: 4074    level: 2
        backup_fs_root:        537116672    gen: 3806    level: 0
        backup_dev_root:    721174528    gen: 3823    level: 1
        backup_csum_root:    932052992    gen: 4074    level: 2
        backup_total_bytes:    1500308553728
        backup_bytes_used:    735441764352
        backup_num_devices:    2
$


Super says root tree generation 4514; but the most recent backup says
4076. What?

# btrfs insp dump-t -b 930086912 /dev/mapper/sdd
btrfs-progs v4.19.1
node 930086912 level 1 items 19 free 474 generation 4076 owner ROOT_TREE
fs uuid f5adc913-bbea-4340-8b5f-3411e2cda642
chunk uuid 4af0d265-00fa-4a2b-9ea9-59c06a372284
    key (EXTENT_TREE ROOT_ITEM 0) block 931102720 gen 4076
    key (279 INODE_ITEM 0) block 535216128 gen 3802
    key (307 INODE_ITEM 0) block 715111579648 gen 3511
    key (368 EXTENT_DATA 0) block 715103928320 gen 3510
    key (430 INODE_ITEM 0) block 715111612416 gen 3511
    key (491 EXTENT_DATA 0) block 715111677952 gen 3511
    key (553 INODE_ITEM 0) block 715111841792 gen 3511
    key (652 EXTENT_DATA 0) block 714560716800 gen 3523
    key (711 INODE_ITEM 0) block 934019072 gen 4076
    key (773 INODE_ITEM 0) block 934887424 gen 4076
    key (829 INODE_ITEM 0) block 671989760 gen 3808
    key (884 INODE_ITEM 0) block 714619404288 gen 3525
    key (939 ROOT_ITEM 1889) block 715035377664 gen 3506
    key (981 ROOT_ITEM 3330) block 933658624 gen 4067
    key (1034 INODE_ITEM 0) block 172621824 gen 3546
    key (1095 EXTENT_DATA 0) block 934232064 gen 4076
    key (FREE_SPACE UNTYPED 11840520192) block 934248448 gen 4076
    key (FREE_SPACE UNTYPED 275981008896) block 934658048 gen 4076
    key (FREE_SPACE UNTYPED 568038785024) block 933724160 gen 4067
# btrfs insp dump-t -b 29392896 /dev/mapper/sdd
btrfs-progs v4.19.1
node 29392896 level 1 items 10 free 483 generation 4514 owner ROOT_TREE
fs uuid f5adc913-bbea-4340-8b5f-3411e2cda642
chunk uuid 4af0d265-00fa-4a2b-9ea9-59c06a372284
    key (EXTENT_TREE ROOT_ITEM 0) block 712994078720 gen 4514
    key (773 INODE_ITEM 0) block 29442048 gen 4470
    key (829 INODE_ITEM 0) block 671989760 gen 3808
    key (884 INODE_ITEM 0) block 714619404288 gen 3525
    key (939 ROOT_ITEM 1889) block 715035377664 gen 3506
    key (981 ROOT_ITEM 3330) block 933658624 gen 4067
    key (1034 INODE_ITEM 0) block 172621824 gen 3546
    key (1095 EXTENT_DATA 0) block 29409280 gen 4514
    key (FREE_SPACE UNTYPED 559448850432) block 29376512 gen 4483
    key (FREE_SPACE UNTYPED 568038785024) block 933724160 gen 4067
#

I guess I don't understand why 'btrfs check' would have successfully
written six updated copies of the super, when the operation hadn't yet
succeeded. I guess this isn't an atomic operation, and perhaps it
can't be.

---
Chris Murphy

  reply	other threads:[~2019-03-02  2:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-02  0:20 [bug] btrfs check clear-space-cache v1 corrupted file system Chris Murphy
2019-03-02  1:05 ` Qu Wenruo
2019-03-02  2:29   ` Chris Murphy
2019-03-02  2:54     ` Chris Murphy [this message]
     [not found]       ` <CAJCQCtQaQ0XFUGFdWfgwmTSPTUShrZgXmsh55c-reS9iS+WpFg@mail.gmail.com>
2019-03-02  3:22         ` Chris Murphy
2019-03-02  4:14     ` Qu Wenruo
     [not found]       ` <CAJCQCtRyStqPLOXHVWkcha3GkA7wt2u00qSH7DfUyL_ift5ppQ@mail.gmail.com>
2019-03-10 23:20         ` Chris Murphy
2019-08-12  4:24           ` Chris Murphy
2019-08-12  4:54             ` Qu Wenruo
2019-08-12  5:04               ` Chris Murphy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJCQCtQvi77SZbL4_fK1B5jNRpYhWOHBQOKvZ2Pdr8AoJDBXBg@mail.gmail.com \
    --to=lists@colorremedies.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).