From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: "Swâmi Petaramesh" <swami@petaramesh.org>, linux-btrfs@vger.kernel.org
Cc: Christoph Anton Mitterer <calestyo@scientia.net>
Subject: Re: Massive filesystem corruption since kernel 5.2 (ARCH)
Date: Tue, 27 Aug 2019 14:21:41 +0800 [thread overview]
Message-ID: <370697f1-24c9-c8bd-01a7-c2885a7ece05@gmx.com> (raw)
In-Reply-To: <4bd70aa2-7ad0-d5c6-bc1f-22340afaac60@petaramesh.org>
On 2019/8/27 下午2:13, Swâmi Petaramesh wrote:
> Le 27/08/2019 à 07:06, Swâmi Petaramesh a écrit :
>>
>> Now the machine looks stable so far with a 5.2, albeit more recent, Arch
>> kernel : 5.2.9-arch1-1-ARCH.
>
> As my 1st machine looks fairly stable now, I just upgraded to 5.2
> another one that had always been running <= 5.1 before.
>
> So I keep an eye on the syslog.
>
> Right after reboot in 5.2 I see :
>
> kernel: BTRFS warning (device dm-1): block
> group 34390147072 has wrong amount of free space
> kernel: BTRFS warning (device dm-1):
> failed to load free space cache for block group 34390147072, rebuilding
> it now
>
> So it seems that the 5.2 kernel finds and tries to fix minor
> inconsistencies that were unnoticed in previous kernel versions ?
It means something wrong is already done in previous kernel.
V1 space cache use regular-file-like internal structures to record used
space. V1 space cache doesn't use btrfs' regular csum tree, but uses its
own inline csum to protect its content.
If free space cache is invalid but passes its csum check, it's
completely *possible* to break metadata CoW, thus leads to transid mismatch.
You can go v2 space cache which uses metadata CoW to protect its space
cache, thus in theory it should be a little safer than V1 space cache.
Or you can just disable space cache using nospace_cache mount option, as
it's just an optimization. It's also recommended to clean existing cache
by using "btrfs check --clear-space-cache v1".
I'd prefer to do a "btrfs check --readonly" anyway (which also checks
free space cache), then go nospace_cache if you're concerned.
Thanks,
Qu
>
> I wonder if such things could be the cause of the corruption issues I
> got : finding some inconsistencies with new checks right after a kernel
> upgrade, trying to fix them and creating a mess instead ?
>
> (This 2nd machine has been rebooted twice after this and still looks
> happy...)
>
> Kind regards.
>
> ॐ
>
next prev parent reply other threads:[~2019-08-27 6:21 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-24 17:44 Massive filesystem corruption since kernel 5.2 (ARCH) Christoph Anton Mitterer
2019-08-25 10:00 ` Swâmi Petaramesh
2019-08-27 0:00 ` Christoph Anton Mitterer
2019-08-27 5:06 ` Swâmi Petaramesh
2019-08-27 6:13 ` Swâmi Petaramesh
2019-08-27 6:21 ` Qu Wenruo [this message]
2019-08-27 6:34 ` Swâmi Petaramesh
2019-08-27 6:52 ` Qu Wenruo
2019-08-27 9:14 ` Swâmi Petaramesh
2019-08-27 12:40 ` Hans van Kranenburg
2019-08-29 12:46 ` Oliver Freyermuth
2019-08-29 13:08 ` Christoph Anton Mitterer
2019-08-29 13:09 ` Swâmi Petaramesh
2019-08-29 13:11 ` Qu Wenruo
2019-08-29 13:17 ` Oliver Freyermuth
2019-08-29 17:40 ` Oliver Freyermuth
[not found] ` <-z770dp-y45icx-naspi1dhhf7m-b1jjq3853x22lswnef-p5g363n8kd2f-vdijlg-jk4z4q-raec5-em5djr-et1h33i4xib8jxzw1zxyza74-miq3zn-e4azxaaeyo3abtrf6zj8nb18-hbhrrmnr1ww1.1566894946135@email.android.com>
2019-08-27 12:34 ` Re : " Qu Wenruo
2019-08-27 10:59 ` Swâmi Petaramesh
2019-08-27 11:11 ` Alberto Bursi
2019-08-27 11:20 ` Swâmi Petaramesh
2019-08-27 11:29 ` Alberto Bursi
2019-08-27 11:45 ` Swâmi Petaramesh
2019-08-27 17:49 ` Swâmi Petaramesh
2019-08-27 22:10 ` Chris Murphy
2019-08-27 12:52 ` Michal Soltys
2019-09-12 7:50 ` Filipe Manana
2019-09-12 8:24 ` James Harvey
2019-09-12 9:06 ` Filipe Manana
2019-09-12 9:09 ` Holger Hoffstätte
2019-09-12 10:53 ` Swâmi Petaramesh
2019-09-12 12:58 ` Christoph Anton Mitterer
2019-10-14 4:00 ` Nicholas D Steeves
2019-09-12 8:48 ` Swâmi Petaramesh
2019-09-12 13:09 ` Christoph Anton Mitterer
2019-09-12 14:28 ` Filipe Manana
2019-09-12 14:39 ` Christoph Anton Mitterer
2019-09-12 14:57 ` Swâmi Petaramesh
2019-09-12 16:21 ` Zdenek Kaspar
2019-09-12 18:52 ` Swâmi Petaramesh
2019-09-13 18:50 ` Pete
[not found] ` <CACzgC9gvhGwyQAKm5J1smZZjim-ecEix62ZQCY-wwJYVzMmJ3Q@mail.gmail.com>
2019-10-14 2:07 ` Adam Bahe
2019-10-14 2:19 ` Qu Wenruo
2019-10-14 17:54 ` Chris Murphy
-- strict thread matches above, loose matches on Subject: below --
2019-07-29 12:32 Swâmi Petaramesh
2019-07-29 13:02 ` Swâmi Petaramesh
2019-07-29 13:35 ` Qu Wenruo
2019-07-29 13:42 ` Swâmi Petaramesh
2019-07-29 13:47 ` Qu Wenruo
2019-07-29 13:52 ` Swâmi Petaramesh
2019-07-29 13:59 ` Qu Wenruo
2019-07-29 14:01 ` Swâmi Petaramesh
2019-07-29 14:08 ` Qu Wenruo
2019-07-29 14:21 ` Swâmi Petaramesh
2019-07-29 14:27 ` Qu Wenruo
2019-07-29 14:34 ` Swâmi Petaramesh
2019-07-29 14:40 ` Qu Wenruo
2019-07-29 14:46 ` Swâmi Petaramesh
2019-07-29 14:51 ` Qu Wenruo
2019-07-29 14:55 ` Swâmi Petaramesh
2019-07-29 15:05 ` Swâmi Petaramesh
2019-07-29 19:20 ` Chris Murphy
2019-07-30 6:47 ` Swâmi Petaramesh
2019-07-29 19:10 ` Chris Murphy
2019-07-30 8:09 ` Swâmi Petaramesh
2019-07-30 20:15 ` Chris Murphy
2019-07-30 22:44 ` Swâmi Petaramesh
2019-07-30 23:13 ` Graham Cobb
2019-07-30 23:24 ` Chris Murphy
[not found] ` <f8b08aec-2c43-9545-906e-7e41953d9ed4@bouton.name>
2019-07-29 13:35 ` Swâmi Petaramesh
2019-07-30 8:04 ` Henk Slager
2019-07-30 8:17 ` Swâmi Petaramesh
2019-07-29 13:39 ` Lionel Bouton
2019-07-29 13:45 ` Swâmi Petaramesh
[not found] ` <d8c571e4-718e-1241-66ab-176d091d6b48@bouton.name>
2019-07-29 14:04 ` Swâmi Petaramesh
2019-08-01 4:50 ` Anand Jain
2019-08-01 6:07 ` Swâmi Petaramesh
2019-08-01 6:36 ` Qu Wenruo
2019-08-01 8:07 ` Swâmi Petaramesh
2019-08-01 8:43 ` Qu Wenruo
2019-08-01 13:46 ` Anand Jain
2019-08-01 18:56 ` Swâmi Petaramesh
2019-08-08 8:46 ` Qu Wenruo
2019-08-08 9:55 ` Swâmi Petaramesh
2019-08-08 10:12 ` 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=370697f1-24c9-c8bd-01a7-c2885a7ece05@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=calestyo@scientia.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=swami@petaramesh.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 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).