All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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.