From: auxsvr@gmail.com
To: linux-btrfs@vger.kernel.org
Subject: Re: Write time tree block corruption detected
Date: Mon, 07 Jun 2021 14:55:10 +0300 [thread overview]
Message-ID: <3113674.aeNJFYEL58@localhost.localdomain> (raw)
In-Reply-To: <1861574.PYKUYFuaPT@localhost.localdomain>
On Monday, 31 May 2021 00:30:00 EEST auxsvr@gmail.com wrote:
> Hello,
>
> On linux 5.3.18-lp152.75-default (openSUSE 15.2), I got the following error message:
>
> [33573.070335] BTRFS critical (device sda2): corrupt leaf: root=3 block=531135201280 slot=0 devid=1 invalid bytes used: have 64503152640 expect [0, 64424509440]
> [33573.070338] BTRFS error (device sda2): block=531135201280 write time tree block corruption detected
> [33573.071909] BTRFS: error (device sda2) in btrfs_commit_transaction:2264: errno=-5 IO failure (Error while writing out transaction)
> [33573.071911] BTRFS info (device sda2): forced readonly
> [33573.071913] BTRFS warning (device sda2): Skipping commit of aborted transaction.
> [33573.071915] BTRFS: error (device sda2) in cleanup_transaction:1823: errno=-5 IO failure
> [33573.071917] BTRFS info (device sda2): delayed_refs has NO entry
> [33577.283856] BTRFS info (device sda2): delayed_refs has NO entry
After using btrfs check --repair /dev/sda2:
ref mismatch on [184344514560 4096] extent item 1024, found 0
owner ref check failed [184344514560 4096]
repair deleting extent record: key 184344514560 168 4096
Repaired extent references for 184344514560
Dev extent's total-byte(61236838400) is not equal to byte-used(63451430912) in dev[1, 216, 1]
without resolving the issue, as the filesystem would still become read-only, I deleted all snapshots and there hasn't been an issue for a few hours of heavy use. However, btrfs check still returns the error regarding size mismatch and this worries me a bit. Is there an easy way to resolve this or should I recreate the filesystem?
It seems that every time free space is less than 1 GiB and I use zypper, I get a similar corruption message. Thankfully, there hasn't been any data loss so far. There's also a backup of the filesystem right after the first incident, in case it is useful for further investigation.
Regards,
Petros
next prev parent reply other threads:[~2021-06-07 11:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-30 21:30 Write time tree block corruption detected auxsvr
2021-06-07 11:55 ` auxsvr [this message]
2021-06-08 14:45 ` auxsvr
2021-06-08 22:39 ` Qu Wenruo
2021-06-09 1:05 ` Qu Wenruo
2021-06-09 8:04 ` auxsvr
2021-06-09 8:32 ` Qu Wenruo
2021-06-11 19:44 ` auxsvr
-- strict thread matches above, loose matches on Subject: below --
2020-08-12 13:49 Spencer Collyer
2020-08-12 14:15 ` Qu Wenruo
2020-08-13 5:53 ` Spencer Collyer
2020-08-13 5:58 ` Qu Wenruo
2020-01-17 8:21 write " Kenneth Topp
2020-01-17 8:33 ` Qu Wenruo
2020-01-17 8:48 ` Kenneth Topp
2020-01-17 10:09 ` Qu Wenruo
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=3113674.aeNJFYEL58@localhost.localdomain \
--to=auxsvr@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.