"Stuart D. Gathman" <stuart@bmsi.com> writes: > The current LVM strategy could work, just use the option to store the > mirror log on the same PV as one of the mirrors. If you lose the PV > without the log - no problem. If you lose the PV *with* the log, it > reverts to an in-core log, which is not a problem with the single remaining > leg. The drawback to this is performance. The main reason to put the > mirror log on a 3rd device is so the 3 writes occasioned by every write > to the LV can be done in parallel. Yes, (write) performance is a concern. Otherwise, what you describe is perfectly valid and achievable with LVM. > I don't know how LVM handles issues of PVs that are not permanently dead > and come back on line again later. The md driver uses a generation count in > the super block to determine which is newer. (How is that updated without loss > of efficiency?) LVM has a generation counter as well. It's only updated on metadata writes though, so it doesn't cost anything. (Log is not part of metadata in this sense.) When you lose a leg (and use dmeventd), the metadata on the remaining PVs is updated to say that. The leg is also yanked from the mirror. You can add it as a fresh image (with full resync) if it ever comes back. If you yank disks out of mirrors often (and plug them back afterwards), you should maybe use replication instead of mirroring. Yours, Petr. _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
