From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Chris Murphy <lists@colorremedies.com>, Dmitry Katsubo <dma_k@mail.ru>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Potential to loose data in case of disk failure
Date: Fri, 13 Nov 2015 10:52:58 -0500 [thread overview]
Message-ID: <5646075A.1050606@gmail.com> (raw)
In-Reply-To: <CAJCQCtTFj2dPUw-sxda3B+_G_-9777S1UdNrGkEQMQsPqLxGBQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2376 bytes --]
On 2015-11-13 09:51, Chris Murphy wrote:
> On Thu, Nov 12, 2015 at 12:23 PM, Dmitry Katsubo <dma_k@mail.ru> wrote:
>> If so then I
>> think this is a trap, and mkfs.btrfs should at least warn (or require
>> --force) if two partitions are on the same drive for raid1/raid5/raid10.
>
> Does mdadm warn in the same situation? LVM?
>
> There are some assumptions being made about the end user's
> understanding of the system they're working on, and those assumptions
> aren't unreasonable. But I'm not opposed to an informational message.
LVM doesn't, and I don't think MDADM does. With LVM things are handled
differently from mkfs, you either specify which specific PV's you want
the LV to be on (in which case it's perfectly reasonable to assume you
know what you're doing), or you let LVM try to find optimal placement
(using a similar algorithm to how BTRFS decides what device a new chunk
goes on), and it doesn't check that the PV's are on different disks (and
in fact, even if it did, you could use pvmove to force them onto the
same disk anyway), but either way it refuses to let you have more copies
than you have PV's for a RAID set. I'm not certain about how MDADM
handles things, but I don't think that it warns about having multiple
components for a given RAID set on the same disk.
Regardless of what LVM and MDADM do, it's not unreasonable to assume
that people will make the assumption that BTRFS is smart enough to
balance things properly (too many people don't do any research about a
program before trying to use it, and I must commend Jim for taking the
time to verify whether things would behave like he wanted them to), so I
do think that putting a warning in would be a good idea. This won't be
perfect of course, because people (myself included) use BTRFS on top of
DM (be it LVM, dmcrypt, or something else), MD, and other intervening
block layers, so we can't just try sub-string matching on the device names.
We absolutely should not refuse to let the user do this if they want to
however, as there are people who use RAID1 on a single disk for the
protection against corruption, even though it doesn't protect against
hardware failure (although there is a patch on the ML for using dup
profile for data chunks, so hopefully this practice will become less
common in the near future).
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]
next prev parent reply other threads:[~2015-11-13 15:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-11 17:30 Potential to loose data in case of disk failure Jim Murphy
2015-11-11 20:24 ` Sean Greenslade
2015-11-12 12:47 ` Austin S Hemmelgarn
2015-11-12 17:23 ` Dmitry Katsubo
2015-11-12 17:55 ` Austin S Hemmelgarn
2015-11-13 14:51 ` Chris Murphy
2015-11-13 15:52 ` Austin S Hemmelgarn [this message]
2015-11-11 23:13 ` Chris Murphy
2015-11-12 5:07 ` Duncan
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=5646075A.1050606@gmail.com \
--to=ahferroin7@gmail.com \
--cc=dma_k@mail.ru \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.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 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.