From: Johannes Hirte <johannes.hirte@datenkhaos.de>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: linux-btrfs@vger.kernel.org, Jens Axboe <axboe@kernel.dk>
Subject: Re: failed to read block groups: Operation not permitted
Date: Thu, 8 Oct 2020 11:24:09 +0200 [thread overview]
Message-ID: <20201008092409.GB387879@latitude> (raw)
In-Reply-To: <9cd7f2d0-4256-7311-483e-b1169e4c3655@gmx.com>
On 2020 Okt 06, Qu Wenruo wrote:
>
>
> On 2020/10/6 下午5:09, Johannes Hirte wrote:
> > I recently encountered filesystem damage on a VM. During normal
> > operation, the filesystem was remounted ro suddenly. Dmesg showed me
> > some errors about parent transid verify failed. I've forced of the VM
> > and tried to mount the image on the host, but failed with:
> >
> > [ 340.702391] BTRFS info (device loop0p1): disk space caching is enabled
> > [ 340.702393] BTRFS info (device loop0p1): has skinny extents
> > [ 341.815890] BTRFS error (device loop0p1): parent transid verify failed on 152064327680 wanted 323984 found 323888
> > [ 341.831183] BTRFS error (device loop0p1): parent transid verify failed on 152064327680 wanted 323984 found 323888
>
> Your extent tree is corrupted. Metadata CoW is broken.
>
> I don't believe only extent tree get corrupted, other part of your fs
> can also be corrupted.
>
> > [ 341.831194] BTRFS error (device loop0p1): failed to read block groups: -5
> > [ 341.851954] BTRFS error (device loop0p1): open_ctree failed
> >
> > A btrfs check resulted in:
> >
> > btrfs check /dev/loop0p1
> > Opening filesystem to check...
> > parent transid verify failed on 152064327680 wanted 323984 found 323888
> > parent transid verify failed on 152064327680 wanted 323984 found 323888
> > parent transid verify failed on 152064327680 wanted 323984 found 323888
> > Ignoring transid failure
> > leaf parent key incorrect 152064327680
> > ERROR: failed to read block groups: Operation not permitted
> > ERROR: cannot open file system
> >
> > The host is running libvirt with kvm, btrfs with RAID1. The VMs are raw
> > images, with btrfs too. I've switche this VM from io=native to
> > io=io_uring, and suspect that this caused the damage. All machines are
> > running kernel 5.8.13.
>
> I'm not sure about the io_uring setup. IIRC as long as you're not using
> cache=unsafe, it should be safe.
>
> Does the io_uring ignores the flush?
Putting someone with more knowledge into cc.
For another VM, I've found several errors in the log of the host machine:
BTRFS warning (device sda1): direct IO failed ino 5988432 rw 1,2131969 sector 0x123ab840 len 32768 err no 10
The VM was remounted ro too, like the first one. But in this case the
filesystem was ok after a check. For the first VM with the heavily
damaged filesystem there aren't any log entries.
--
Regards,
Johannes Hirte
next prev parent reply other threads:[~2020-10-08 9:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-06 9:09 failed to read block groups: Operation not permitted Johannes Hirte
2020-10-06 12:06 ` Qu Wenruo
2020-10-08 9:24 ` Johannes Hirte [this message]
2020-10-08 9:35 ` Johannes Hirte
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=20201008092409.GB387879@latitude \
--to=johannes.hirte@datenkhaos.de \
--cc=axboe@kernel.dk \
--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).