Re: Removable mirror disks?

[Phil Turmel <philip@turmel.org>]

Good morning Ethan,

On 10/12/2013 02:15 PM, Ethan Tira-Thompson wrote:
> Hi all,
> 
> I’m setting up a raid mirror with two disks.  Ideally, I’d like to do
> this in such a way that I could stop the array, remove a drive, mount
> it directly on another machine as read-only (no RAID setup), and then
> put it back in the RAID and re-assemble as if nothing happened.  (Or
> I could put a new drive in and keep the old one as a snapshot
> backup.)  It’s a maintenance option, not something I intend to do a
> lot.
> 
> Can I do this?  I’ve tried creating a raid from the root block device
> (e.g. sdb) and then partitioning and formatting within the RAID, as
> well as the opposite, partitioning the block device and making a raid
> of the partition.  Neither of these seems happy if I pull a drive and
> try to use it directly.  Is that due to the mdadm metadata
> overwriting/offsetting the filesystem?  Would something like DDF
> containers solve this?  Or if I shrink the filesystem on a partition
> (leaving unused space on the partition) and then use metadata version
> 1.0? (not sure I can do that, everything I’ve seen resizes the
> partition too)

It is theoretically possible to do this, and even convenient to leave
the main system running by appropriate use of a write-intent bitmap.
However, you can't use mdadm to access the pulled drive, as it will bump
the event count and cause 'split-brain'.

If you use metadata 0.9 or 1.0, you can mount the underlying device
directly.  This is hazardous, even with a read-only mount, as
filesystems generally do a mini-fsck on any mount (journal replay, etc).
 That makes the copy unusable in the original array.  The original array
has no way to figure out at re-insertion that this type of corruption
has happened.

So the practical answer is *no*, once you access the data on the pulled
drive.

> An unrelated question: I’ve heard some implementations RAID-1
> mirroring will load balance reads between the disks at the process
> level but not striping of reads within a thread?  How does linux raid
> handle this?  Seems like the kernel could stripe the read requests
> regardless of being single threaded, but maybe there’s some
> complication of guaranteeing coherency with writes to each drive?

Raid 1 just passes complete read requests through the block layer to one
of the underlying devices, and write requests to all of the underlying
devices.  So the load balancing happens at the level of complete
requests.  If a process is multi-threaded and submitting multiple
simultaneous requests, those will load balance.

HTH,

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