All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Andrei Borzenkov <arvidjaar@gmail.com>,
	Hendrik Friedel <hendrik@friedels.name>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Migration to BTRFS
Date: Mon, 29 Apr 2019 07:43:08 -0400	[thread overview]
Message-ID: <e27cc7ee-4256-0ccc-a9f1-79cd6898e927@gmail.com> (raw)
In-Reply-To: <0f1a1f40-c951-05dc-f9fd-d6de5884f782@gmail.com>

On 2019-04-28 16:14, Andrei Borzenkov wrote:
> 28.04.2019 22:35, Hendrik Friedel пишет:
>> Hello,
>>
>> I intend to move to BTRFS and of course I have some data already.
>> I currently have several single 4TB drives and I would like to move the
>> Data onto new drives (2*8TB). I need no raid, as I prefer a backup.
>> Nevertheless, having raid nice for availability. So why not in the end.
>> I currently use ~6TB, so it may work, but I would be able to remove the
>> redundancy later.
>>
>> So, if I understand correctly, today I want
>> -m raid1 -d raid1
>>
>> whereas later, I want
>> -m raid1 -d single
>>
>> What is very important to me is, that with one failing drive, I have no
>> risk of losing the whole filesystem, but only losing the affected drive.
>> Is that possible with both of these variants?
>>
> 
> With "single" data profile you won't lose filesystem, but you will
> irretrievably lose any data on the missing drive. Also "single" profile
> does not support auto-healing (repairing of bad copy from good copy). If
> this is acceptable to you, then yes, both variants will do what you want.
Actually, it's a bit worse than this potentially.  You may lose 
individual files if you lose one disk with the proposed setup, but you 
may also lose _parts_ of individual files, especially if you have lots 
of large (>1-5GB in size) files.  And on top of this, finding what data 
went missing will essentially require trying to read every byte of every 
file in the volume.
> 
>> Is it possible to move between the two (doing a balance, of course?
> 
> Yes as long as you have sufficient free space for target profile.
> 
>> Any other thoughts/recommendations?
>>
> 
> As of today there is no provision for automatic mounting of incomplete
> multi-device btrfs in degraded mode. Actually, with systemd it is flat
> impossible to mount incomplete btrfs because standard framework only
> proceeds to mount it after all devices have been seen. As long as you do
> not use systemd in initramfs you may be able to boot by passing suitable
> root mount flags on kernel command line.
> 


  reply	other threads:[~2019-04-29 11:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-28 19:35 Migration to BTRFS Hendrik Friedel
2019-04-28 20:14 ` Andrei Borzenkov
2019-04-29 11:43   ` Austin S. Hemmelgarn [this message]
     [not found]     ` <em12ddda3f-4221-4678-aa1c-0854489007e1@ryzen>
2019-04-29 17:20       ` Austin S. Hemmelgarn
2019-04-29 17:31         ` Andrei Borzenkov
2019-04-29 18:25           ` Austin S. Hemmelgarn
2019-04-30  3:27             ` Andrei Borzenkov
2019-04-28 20:46 ` waxhead
2019-05-25 13:21 ` Hendrik Friedel

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=e27cc7ee-4256-0ccc-a9f1-79cd6898e927@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=arvidjaar@gmail.com \
    --cc=hendrik@friedels.name \
    --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.