Re: I can't mount image

[Chris Murphy <lists@colorremedies.com>]

On Wed, May 20, 2020 at 3:12 PM Jiří Lisický <jiri_lisicky@seznam.cz> wrote:
>
>
> btrfs insp dump-s -fa /dev/loop4
>
> superblock: bytenr=65536, device=/dev/loop4
> ---------------------------------------------------------
> csum_type               0 (crc32c)
> csum_size               4
> csum                    0xdc2c003a [match]
> bytenr                  65536
> flags                   0x1
>                         ( WRITTEN )
> magic                   _BHRfS_M [match]
> fsid                    86180ca0-d351-4551-b262-22b49e1adf47
> metadata_uuid           86180ca0-d351-4551-b262-22b49e1adf47
> label                   sailfish
> generation              2727499
> root                    30703616
> sys_array_size          226
> chunk_root_generation   2342945
> root_level              1
> chunk_root              20971520
> chunk_root_level        0
> log_root                94920704

There's a log tree being referenced, but in an earlier step you zero'd
the log. There might be some data loss for whatever was being written
at the time it was last rw mounted.



> log_root_transid        0
> log_root_level          0
> total_bytes             14761832448
> bytes_used              5075300352
> sectorsize              4096
> nodesize                4096
> leafsize (deprecated)   4096
> stripesize              4096
> root_dir                6
> num_devices             1
> compat_flags            0x0
> compat_ro_flags         0x0
> incompat_flags          0x3
>                         ( MIXED_BACKREF |
>                           DEFAULT_SUBVOL )

Must be a very early btrfs-progs. Default these days is 0x161.


> / # uname -a
> Linux (none) 3.4.108.20190506.1 #1 SMP PREEMPT Sat Nov 30 21:25:45 UTC
> 2019 armv7l GNU/Linux
> / # btrfs --version
> Btrfs v3.16

To attempt a repair, you need something much newer. I suggest 5.6 or
5.6.1 since they're recent. Arch and Fedora Rawhide images will have
one of those. I'm not certain v3.16 can reliably tell us what's wrong
with the file system, in particular since quotas are enabled. Please
update and then repost 'btrfs check' without options.

This is promising though:

>parent transid verify failed on 94920704 wanted 2727500 found 2727499

Weird - why does it want that generation when the super block says the
root tree generation is 2727499? Can you also include output from:

# btrfs rescue super -v /dev/

It might be as simple as 'mount -o ro,recovery' with that older kernel
if it can roll back to the previous transid. If not, then a more
recent btrfs progs might be able to confirm whether the older state
can be repaired. That looks like this:

# btrfs check /dev/
# btrfs check -r 48250880 /dev/
# btrfs check -r 114339840 /dev/
# btrfs check -r 102043648 /dev/
# btrfs check -r 90173440 /dev/


The first two are most likely to succeed. All of these are still read
only, gathering information. There are no repairs yet even though
you're working on a backup image (good idea).

-- 
Chris Murphy