From: Nigel Kukard <nkukard@LBSD.net>
To: Roman Mamedov <rm@romanrm.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs ontop of LVM ontop of MD RAID1 supported?
Date: Sat, 2 Mar 2024 16:09:42 +0000 [thread overview]
Message-ID: <70c07873-b87b-4e0d-8a2e-e2ac90ec861e@LBSD.net> (raw)
In-Reply-To: <20240302204726.6d2dcd87@nvm>
[-- Attachment #1.1: Type: text/plain, Size: 1935 bytes --]
Hi there Roman,
On 3/2/24 15:47, Roman Mamedov wrote:
> On Sat, 2 Mar 2024 15:01:43 +0000
> Nigel Kukard <nkukard@LBSD.net> wrote:
>
>> I'm wondering if btrfs ontop of LVM ontop of MD RAID1 is supported?
> Should be absolutely supported.
>
>> I've managed to reproduce with 100% accuracy severe data corruption
>> using this configuration on 6.6.19.
>>
>> 2 x 1.92T NVMe's in MD RAID1 configuration
>> LVM volume created ontop of the MD RAID1
>> btrfs filesystem on the LV
>>
>> I then write about 100-200G of data. Create a snapshot. Read/write the
>> file and get these messages...
> Has the MD RAID1 finished its initial sync after creation?
>
> Have you tried waiting until it finishes and only then do thewrites to see if
> the corruption is still observed (of course that's in no way a "workaround",
> just to see what might cause the bug).
Sync completed on all 4 systems I tested on before creating the LVM
volume and filesystem.
>
> Do you know any kernel versions or series where this corruption did not happen?
>
> I assume you're not saying it appeared in 6.6.19 compared to 6.6.18.
Sadly, this is the first time I'm testing this specific setup. These are
production systems, so changing kernel version is a bit tricky.
Let me try reproduce it on another bit of hardware, I'll revert back.
>
> Can you try the 6.1 series? Or maybe also 6.8?
Sure, let me see if I can set something up and reproduce it, then we can
test different kernel versions and start bisecting.
> I made a Btrfs on top of LVM on top of RAID1 myself now, but on consumer SSDs.
> Copying some files to it now, to check. Would be also helpful if you can find
> a precise sequence of commands which can trigger the bug, less vague than
> copy some files to it and see.
Sure thing. Let me see if I can trim things down and get a simple
sequence of commands to make things easier.
-N
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
next prev parent reply other threads:[~2024-03-02 16:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-02 15:01 btrfs ontop of LVM ontop of MD RAID1 supported? Nigel Kukard
2024-03-02 15:47 ` Roman Mamedov
2024-03-02 16:09 ` Nigel Kukard [this message]
2024-03-02 16:19 ` Roman Mamedov
2024-03-19 11:05 ` Nigel Kukard
2024-03-19 13:26 ` Nigel Kukard
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=70c07873-b87b-4e0d-8a2e-e2ac90ec861e@LBSD.net \
--to=nkukard@lbsd.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=rm@romanrm.net \
/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