All of lore.kernel.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Potential to loose data in case of disk failure
Date: Thu, 12 Nov 2015 05:07:41 +0000 (UTC)	[thread overview]
Message-ID: <pan$7387e$355c1b46$cb8e309e$12e649f4@cox.net> (raw)
In-Reply-To: CAJCQCtTCzCOfdrvjNF2rs_VuHqVA4nU3jsgxKpkADd-+v7GtMA@mail.gmail.com

Chris Murphy posted on Wed, 11 Nov 2015 18:13:22 -0500 as excerpted:

> On Wed, Nov 11, 2015 at 12:30 PM, Jim Murphy <srlinuxadmin@gmail.com>
> wrote:
>> Hi all,
>>
>> What am I missing or misunderstanding?  I have a newly purchased laptop
>> I want/need to multi boot different OSs on.  As a result after
>> partitioning I have ended up with two partitions on each of the two
>> internal drives(sda3, sda8, sdb3 and sdb8).  FWIW, sda3 and sdb3 are
>> the same size and sda8 and sdb8 are the same size.  As an end result I
>> want one btrfs raid1 filesystem.  For lack of better terms,
>> sda3 and sda8 "concatenated" together, sdb3 and sdb8 "concatenated"
>> together and then mirroring "sda" to "sdb" using only btrfs.  So far
>> have found no use-case to cover this.

There isn't any... using ONLY btrfs (as the OP specified).  You need 
either mdraid or lvm to concatenate the two logical devices (partitions) 
on a single physical device into one, so then btrfs will see only two 
devices and put a raid1 copy on each.

This is because (reordering a bit of your quote from further below)...

> btrfs works strictly at the block device level, and considers different
> partitions different block devices, it doesn't grok the underlying
> physical device relationship.

[end of reordered bit]

> I'm going to assume that mkfs.btrfs -mraid1 -draid1 command is pointed
> at the two resulting /dev/mapper/X devices resulting from the linear
> concat.

Except, under the conditions he specified, there will be no such linear 
concat mapper device available.

>> If I create a raid1 btrfs volume using all 4 "devices" as I understand
>> it I would loose data if I were to loose a drive because two mirror
>> possibilities would be:
>>
>> sda3 mirrored to sda8 sdb3 mirrored to sdb8
> 
> Well you don't actually know how the mirroring will allocate is the
> problem with the arrangement. But yes, it's possible some chunks on sda3
> will be mirrored to sda8, which is not what you'd want so the linear
> concat idea is fine using either the md driver or lvm.
> 
>> Is what I want to do possible without using MD-RAID and/or LVM?
> 
> Yes, either are suitable for this purpose. The decision comes down to
> the user space tools, use the tool that you're most comfortable with.

It's not possible /without/ using them, no.  Using them, yes, but that's 
not the question that was asked.


As for the explanation, that's the part that I reordered above, btrfs 
only sees block devices.  It doesn't know nor care what they're from.


One workaround would be as Sean Greenslade's, using either a partitioning 
tool that can safely move partitions around without destroying the data 
in them, or simply copying off to backup, deleting the partitions and 
recreating them in a more workable layout, then restoring from backup to 
the new partitions, combining the two partitions on each physical device 
into one.

Another workaround would be putting btrfs on top of an mdraid or lvm 
setup as above, thereby using software to overcome the hardware layout 
limitations.

Yet another, the one I'd almost certainly use here unless the use-case 
made it too inconvenient or not even possible (one big file too big for 
either one alone), would be to simply create two entirely separate btrfs 
raid1 filesystems, each one composed of the two partitions of similar 
size.  I'm already a strong booster of using partitioning to avoid 
putting all my data eggs in one basket, and already use multiple separate 
btrfs raid1s on partitions of the same two physical devices, here, so 
this wouldn't even be beyond what I'm already doing, here.  And if the 
OP's already dealing with that many partitions, it sounds like he'd be 
able to handle it fairly well too.  After all there's always symlinks and 
bind-mounts available to make parts of one filesystem available in 
arbitrary locations on another, if the location of the directories 
themselves is hard-coded to such an extent that you can't simply move 
them and point everything that was pointed at the old location to the new 
one, instead.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


      reply	other threads:[~2015-11-12  5:07 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
2015-11-11 23:13 ` Chris Murphy
2015-11-12  5:07   ` Duncan [this message]

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='pan$7387e$355c1b46$cb8e309e$12e649f4@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.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 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.