linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Can btrfs re-sync an out-of-sync RAID1 filesystem?
Date: Wed, 17 Sep 2014 19:48:54 +0000 (UTC)	[thread overview]
Message-ID: <pan$e6d2e$8bcdb8e4$ee7c1dd5$85ffb88a@cox.net> (raw)
In-Reply-To: 5419C11D.1080803@gmail.com

Alan Hagge posted on Wed, 17 Sep 2014 10:13:01 -0700 as excerpted:

> I know that sounds weird, but here's my scenario:
> 
> - Create a RAID1 filesystem (both data and metadata) using 2 same-sized
> external USB drives - Copy data (backup of other filesystem) onto this
> new filesystem - Dismount the filesystem - Split up the drives (keep one
> at home, move one to offsite backup)
> 
> This way if I need to recover a file, I can mount the one drive I have
> with "-o ro,degraded" to recover data.  If there's a read error on the
> backup drive during the copy, I can go to the offsite location, bring
> back the 2nd drive and mount both and have RAID1 protection.
> 
> BUT...if I accidentally (because I forgot to use "ro" when mounting) or
> purposely write data to the single drive in degraded mode,  is it
> possible to later mount both drives in RAID1 mode and "resync" them (as
> opposed to having to do a "replace" operation on the out-of-sync drive,
> which would force it to be completely rewritten)?  If so, how would
> btrfs know which drive is the "master" (ie. the updated one)?
> 
> Or is it not possible to write to a btrfs volume mounted in "degraded"
> mode?

In general this works.  However, as the thread linked in Piotr's reply 
mentions, don't expect it to work for NOCOW files.  (But you have to make 
files nocow, so if you haven't, that shouldn't be an issue.)

Additionally, the "newest version" detection is based on file generation, 
so you want to be SURE you don't separately mount first one device 
writable and then the other, so they diverge not only from each other but 
from the point of separation.  If you split them, make SURE only the one 
is mounted writable, so it'll be very clear which one has the updated 
content.  If you DO accidentally separately mount both of them writable, 
I'd suggest using wipefs (or dd) to kill the btrfs magic on one of them 
so there's no possibility of btrfs getting mixed up which is newer, and 
then doing a btrfs replace to replace it with a new, current copy.

Meanwhile, again as noted in the Piotr's linked thread, the detection and 
update isn't automatic.  Once split with one mounted writable, when 
rejoined you'll want to do a btrfs scrub to bring the other one current.

-- 
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


      parent reply	other threads:[~2014-09-17 19:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-17 17:13 Can btrfs re-sync an out-of-sync RAID1 filesystem? Alan Hagge
2014-09-17 18:33 ` Piotr Szymaniak
2014-09-17 19:48 ` 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$e6d2e$8bcdb8e4$ee7c1dd5$85ffb88a@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 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).