On Tue, Nov 30, 2010 at 2:14 PM, Nataraj <incoming-centos@xxxxxxx> wrote: >> TopRAID1's LVM is likely to be running over a RAID6 set , so I'm not >> depending on the TopRAID mirroring for reliability, just using it for >> the above volume cloning. > > Your raid 1 backups won't mirror any snapshots of your LV's unless you > specifically setup mirroring of the snapshots after they exist. Ah, getting clearer to me, I was thinking I'd be mirroring the LV itself, but you're right, taking a snapshot and mirroring that is a much better idea. So here's a summary of steps, please confirm: - create a snapshot of a given volume - create a new RAID1 mdN between that and a physical partition (blank?) - let that get sync'd up - break the RAID (fail the partition?), remove the drive - delete the snapshot The below is less clear to me, especially if the above is correct: >> If so, would it be possible/better for the host In normal operations >> to mount the underlying LV directly rather than the degraded top-level >> RAID1? > > No, you want to have mdadm assemble the raid volume, even if in degraded > mode with only one drive and then access the LV on top of the md device. > Even if you were able to mount the LV and bypass raid, that would be > pointless because you would not update the bitmap and superblock and the > integrety of the raid set would be lost. During normal operations - when I'm not in the process of taking a RAID-backup of my LV snapshot - it seems to me that the "Top-RAID" mdN doesn't even exist right? It's set up to mirror between a snapshot and a regular partition, both of which don't even exist during these normal operations. Therefore during normal operations the host *is* mounting the LV directly, not via the "Top-RAID"mdN. I wasn't talking about accessing the "Bottom-RAID" which creates the underlying PV - this is transparent to LVM anyway, right? Thanks again for your help (or in advance to anyone else who would like to chime in) -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
