From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Zoltan <zoltan1980@gmail.com>
Cc: Peter Grandi <pg@btrfs.list.sabi.co.uk>,
Linux fs Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Is it safe to use btrfs on top of different types of devices?
Date: Thu, 19 Oct 2017 11:07:46 -0400 [thread overview]
Message-ID: <c28708f9-e6c4-4918-d4ef-3158dc3c973b@gmail.com> (raw)
In-Reply-To: <CAA-GF5vaP-O+6rBiRVKF_cUnmfWHW9+Qp8a=RzecmizmEcoW1g@mail.gmail.com>
On 2017-10-19 10:42, Zoltan wrote:
> On Thu, Oct 19, 2017 at 4:27 PM, Austin S. Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>
>> and thus when the same device reappears (as it will when the disconnect was
>> due to a transient bus error, which happens a lot), it shows up as a
>> different device node, which gets scanned for filesystems by udev, and BTRFS
>> then gets really confused because it now sees 3 (or more) devices for a 2
>> device filesystem.
>
> And what would happen with a regular, single-device BTRFS volume after
> a reconnect? Isn't this issue just as bad for that case?
No, because the multi-device code only gets used if the filesystem
claims to have more than one device, and it's a bug in the multi-device
code that causes this problem. From a data safety perspective, the
disconnect will look like a power loss event if it was a single device
filesystem, and BTRFS handles that situation fine (though you would
probably need to remount the filesystem).
FWIW, the same bug causes similar data loss problems with block-level
copies of BTRFS filesystems (if you then mount either the original or
the copy while both are visible to the system), and allows you to screw
up multi-device filesystems by connecting a storage device with a
carefully crafted bogus BTRFS filesystem on it. Overall though, it's
not been seen as a high priority bug because:
1. Nobody has come up with a reliable method of handling it that doesn't
break anything or require revising the on-disk layout.
2. It's easy to work around (don't do block level copies and ensure
proper physical security of the system like you should be doing anyway).
next prev parent reply other threads:[~2017-10-19 15:07 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-14 19:00 Is it safe to use btrfs on top of different types of devices? Zoltán Ivánfi
2017-10-15 0:19 ` Peter Grandi
2017-10-15 3:42 ` Duncan
2017-10-15 8:30 ` Zoltán Ivánfi
2017-10-15 12:05 ` Duncan
2017-10-16 11:53 ` Austin S. Hemmelgarn
2017-10-16 16:57 ` Zoltan
2017-10-16 17:27 ` Austin S. Hemmelgarn
2017-10-17 1:14 ` Adam Borowski
2017-10-17 11:26 ` Austin S. Hemmelgarn
2017-10-17 11:42 ` Zoltan
2017-10-17 12:40 ` Austin S. Hemmelgarn
2017-10-17 17:06 ` Adam Borowski
2017-10-17 19:19 ` Austin S. Hemmelgarn
2017-10-17 20:21 ` Adam Borowski
2017-10-17 21:56 ` Zoltán Ivánfi
2017-10-18 4:44 ` Duncan
2017-10-18 14:07 ` Peter Grandi
2017-10-18 11:30 ` Austin S. Hemmelgarn
2017-10-18 11:59 ` Adam Borowski
2017-10-18 14:30 ` Austin S. Hemmelgarn
2017-10-18 4:50 ` Duncan
2017-10-18 13:53 ` Peter Grandi
2017-10-18 14:30 ` Austin S. Hemmelgarn
2017-10-19 11:01 ` Peter Grandi
2017-10-19 12:32 ` Austin S. Hemmelgarn
2017-10-19 18:39 ` Peter Grandi
2017-10-20 11:53 ` Austin S. Hemmelgarn
2017-10-19 13:48 ` Zoltan
2017-10-19 14:27 ` Austin S. Hemmelgarn
2017-10-19 14:42 ` Zoltan
2017-10-19 15:07 ` Austin S. Hemmelgarn [this message]
2017-10-19 18:00 ` Peter Grandi
2017-10-19 17:56 ` Peter Grandi
2017-10-19 18:59 ` Peter Grandi
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=c28708f9-e6c4-4918-d4ef-3158dc3c973b@gmail.com \
--to=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=pg@btrfs.list.sabi.co.uk \
--cc=zoltan1980@gmail.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).