From: Doni Crosby <doni.crosby1995@gmail.com>
To: lists@colorremedies.com
Cc: linux-btrfs@vger.kernel.org
Subject: Re: System unable to mount partition after a power loss
Date: Fri, 7 Dec 2018 01:43:38 -0500 [thread overview]
Message-ID: <CAJkMDByx_H3xjJmN4gO+L0pxpkd7sWLTmTxRfNjUp06r8o3E7w@mail.gmail.com> (raw)
In-Reply-To: <CAJCQCtSiYk4RMRWRoaAFchzvinQ4tq1wC_Ru9d8gJWRsebvbTw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3921 bytes --]
> This is qemu-kvm? What's the cache mode being used? It's possible the
> usual write guarantees are thwarted by VM caching.
Yes it is a proxmox host running the system so it is a qemu vm, I'm
unsure on the caching situation.
> Old version of progs, I suggest upgrading to 4.17.1 and run
I updated the progs to 4.17 and ran the following
btrfs insp dump-s -f /device/:
See attachment
btrfs rescue super -v /device/ (insp rescue super wasn't valid)
All Devices:
Device: id = 1, name = /dev/vda1
Before Recovering:
[All good supers]:
device name = /dev/vda1
superblock bytenr = 65536
device name = /dev/vda1
superblock bytenr = 67108864
device name = /dev/vda1
superblock bytenr = 274877906944
[All bad supers]:
All supers are valid, no need to recover
btrfs check --mode=lowmem /dev/vda1:
parent transid verify failed on 3563224121344 wanted 5184691 found 5184688
parent transid verify failed on 3563224121344 wanted 5184691 found 5184688
parent transid verify failed on 3563221630976 wanted 5184691 found 5184688
parent transid verify failed on 3563221630976 wanted 5184691 found 5184688
parent transid verify failed on 3563223138304 wanted 5184691 found 5184688
parent transid verify failed on 3563223138304 wanted 5184691 found 5184688
parent transid verify failed on 3563224072192 wanted 5184691 found 5184688
parent transid verify failed on 3563224072192 wanted 5184691 found 5184688
parent transid verify failed on 3563225268224 wanted 5184691 found 5184689
parent transid verify failed on 3563225268224 wanted 5184691 found 5184689
parent transid verify failed on 3563227398144 wanted 5184691 found 5184689
parent transid verify failed on 3563227398144 wanted 5184691 found 5184689
parent transid verify failed on 3563229593600 wanted 5184691 found 5184689
parent transid verify failed on 3563229593600 wanted 5184691 found 5184689
parent transid verify failed on 3563229593600 wanted 5184691 found 5184689
parent transid verify failed on 3563229593600 wanted 5184691 found 5184689
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=3563210342400 item=120 parent
level=1 child level=1
ERROR: cannot open file system
mount -o ro,norecovery,usebackuproot /dev/vda1 /mnt:
Same dmesg output as before.
On Fri, Dec 7, 2018 at 12:56 AM Chris Murphy <lists@colorremedies.com> wrote:
>
> On Thu, Dec 6, 2018 at 10:24 PM Doni Crosby <doni.crosby1995@gmail.com> wrote:
> >
> > All,
> >
> > I'm coming to you to see if there is a way to fix or at least recover
> > most of the data I have from a btrfs filesystem. The system went down
> > after both a breaker and the battery backup failed. I cannot currently
> > mount the system, with the following error from dmesg:
> >
> > Note: The vda1 is just the entire disk being passed from the VM host
> > to the VM it's not an actual true virtual block device
>
> This is qemu-kvm? What's the cache mode being used? It's possible the
> usual write guarantees are thwarted by VM caching.
>
>
>
> > btrfs check --recover also ends in a segmentation fault
>
> I'm not familiar with --recover option, the --repair option is flagged
> with a warning in the man page.
> Warning
> Do not use --repair unless you are advised to do so by a
> developer or an experienced user,
>
>
> > btrfs --version:
> > btrfs-progs v4.7.3
>
> Old version of progs, I suggest upgrading to 4.17.1 and run
>
> btrfs insp dump-s -f /device/
> btrfs insp rescue super -v /device/
> btrfs check --mode=lowmem /device/
>
> These are all read only commands. Please post output to the list,
> hopefully a developer will get around to looking at it.
>
> It is safe to try:
>
> mount -o ro,norecovery,usebackuproot /device/ /mnt/
>
> If that works, I suggest updating your backup while it's still
> possible in the meantime.
>
>
> --
> Chris Murphy
[-- Attachment #2: btrfs-insp.txt --]
[-- Type: text/plain, Size: 5349 bytes --]
superblock: bytenr=65536, device=/dev/vda1
---------------------------------------------------------
csum_type 0 (crc32c)
csum_size 4
csum 0xbfa6fd72 [match]
bytenr 65536
flags 0x1
( WRITTEN )
magic _BHRfS_M [match]
fsid 7c76bb05-b3dc-4804-bf56-88d010a214c6
label Array
generation 5184693
root 31801344
sys_array_size 226
chunk_root_generation 5183734
root_level 1
chunk_root 20971520
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 32003947737088
bytes_used 6652776640512
sectorsize 4096
nodesize 16384
leafsize (deprecated) 16384
stripesize 4096
root_dir 6
num_devices 1
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0x161
( MIXED_BACKREF |
BIG_METADATA |
EXTENDED_IREF |
SKINNY_METADATA )
cache_generation 5184691
uuid_tree_generation 5184691
dev_item.uuid e0543326-f76c-4409-98dc-98a782a75490
dev_item.fsid 7c76bb05-b3dc-4804-bf56-88d010a214c6 [match]
dev_item.type 0
dev_item.total_bytes 32003947737088
dev_item.bytes_used 6744210145280
dev_item.io_align 4096
dev_item.io_width 4096
dev_item.sector_size 4096
dev_item.devid 1
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 0)
length 4194304 owner 2 stripe_len 65536 type SYSTEM
io_align 4096 io_width 4096 sector_size 4096
num_stripes 1 sub_stripes 0
stripe 0 devid 1 offset 0
dev_uuid e0543326-f76c-4409-98dc-98a782a75490
item 1 key (FIRST_CHUNK_TREE CHUNK_ITEM 20971520)
length 8388608 owner 2 stripe_len 65536 type SYSTEM|DUP
io_align 65536 io_width 65536 sector_size 4096
num_stripes 2 sub_stripes 0
stripe 0 devid 1 offset 20971520
dev_uuid e0543326-f76c-4409-98dc-98a782a75490
stripe 1 devid 1 offset 29360128
dev_uuid e0543326-f76c-4409-98dc-98a782a75490
backup_roots[4]:
backup 0:
backup_tree_root: 3563189026816 gen: 5184690 level: 1
backup_chunk_root: 20971520 gen: 5183734 level: 1
backup_extent_root: 3563188224000 gen: 5184690 level: 2
backup_fs_root: 3563187421184 gen: 5184690 level: 2
backup_dev_root: 7413296562176 gen: 5183734 level: 1
backup_csum_root: 3563187732480 gen: 5184690 level: 3
backup_total_bytes: 32003947737088
backup_bytes_used: 6652776640512
backup_num_devices: 1
backup 1:
backup_tree_root: 3563196792832 gen: 5184691 level: 1
backup_chunk_root: 20971520 gen: 5183734 level: 1
backup_extent_root: 3563193925632 gen: 5184691 level: 2
backup_fs_root: 3563190501376 gen: 5184691 level: 2
backup_dev_root: 7413296562176 gen: 5183734 level: 1
backup_csum_root: 3563190648832 gen: 5184691 level: 3
backup_total_bytes: 32003947737088
backup_bytes_used: 6652776640512
backup_num_devices: 1
backup 2:
backup_tree_root: 3563187781632 gen: 5184688 level: 1
backup_chunk_root: 20971520 gen: 5183734 level: 1
backup_extent_root: 3563185471488 gen: 5184688 level: 2
backup_fs_root: 3563179261952 gen: 5184688 level: 2
backup_dev_root: 7413296562176 gen: 5183734 level: 1
backup_csum_root: 3563183734784 gen: 5184688 level: 3
backup_total_bytes: 32003947737088
backup_bytes_used: 6652776640512
backup_num_devices: 1
backup 3:
backup_tree_root: 3563187617792 gen: 5184689 level: 1
backup_chunk_root: 20971520 gen: 5183734 level: 1
backup_extent_root: 3563186143232 gen: 5184689 level: 2
backup_fs_root: 3563183833088 gen: 5184689 level: 2
backup_dev_root: 7413296562176 gen: 5183734 level: 1
backup_csum_root: 3563184963584 gen: 5184689 level: 3
backup_total_bytes: 32003947737088
backup_bytes_used: 6652776640512
backup_num_devices: 1
next prev parent reply other threads:[~2018-12-07 6:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-07 5:24 System unable to mount partition after a power loss Doni Crosby
2018-12-07 5:56 ` Chris Murphy
2018-12-07 6:43 ` Doni Crosby [this message]
2018-12-07 12:24 ` Austin S. Hemmelgarn
2018-12-07 16:31 ` Doni Crosby
2018-12-07 7:22 ` Qu Wenruo
[not found] ` <CAJkMDBxD89DFYxV3Nc8EqKDupcxM2+kNGLtTo6QDWaTz-juT6g@mail.gmail.com>
2018-12-07 17:31 ` Doni Crosby
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=CAJkMDByx_H3xjJmN4gO+L0pxpkd7sWLTmTxRfNjUp06r8o3E7w@mail.gmail.com \
--to=doni.crosby1995@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.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).