Can btrfs re-sync an out-of-sync RAID1 filesystem?

2014-09-17 Thread Alan Hagge
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?
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Can btrfs re-sync an out-of-sync RAID1 filesystem?

2014-09-17 Thread Piotr Szymaniak
On Wed, Sep 17, 2014 at 10:13:01AM -0700, Alan Hagge wrote:
 I know that sounds weird, but here's my scenario:

There was similar thread [1] few days ago, you should take a look at it.

[1] https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg37144.html


Piotr Szymaniak.
-- 
I ten smród. Diabli wiedzą, co tam gniło, w tym mięsiwie, ale Redowi
wydało się, że sto tysięcy rozbitych cuchnących jaj wylanych na sto
tysięcy cuchnących rybich łbów i zdechłych kotów nie może śmierdzieć
tak, jak śmierdziała ta maź.
 -- Arkadij i Borys Strugaccy, „Piknik na skraju drogi”


signature.asc
Description: Digital signature


Re: Can btrfs re-sync an out-of-sync RAID1 filesystem?

2014-09-17 Thread Duncan
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

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html