Jonathan Brassow wrote:
It is a special problem with the mirror log.
Mirrors will recover themselves and become consistent upon a reboot. In
the case of a mirror that holds a file system, if you lost some of your
most recent writes, journaling/fsck will take care of it. In the case
of a mirror that holds another mirror's log, you wind up with a log that
does not contain recent data - and could spell coherency issues for the
top level mirror.
Having a filesystem that is consistent is still not correct if it is
older data, at least not when the newer data is available.
There is no metadata on the other drive, that's part of the problem. We
must discern between metadata that is made by LVM (or other userspace
app) and meta-data areas that are known to the device mapper target.
Currently, the mirroring target only has the log device - which I
contend is insufficient.
LVM needs to update its metadata to indicate that the other drive failed
and this one now contains more up to date information going forward.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
