On Aug 13, 2007, at 11:48 AM, Phillip Susi wrote:
Jonathan Brassow wrote:
On a different topic, why are you mirroring the log? Isn't this
somewhat dangerous?
Let's say that the primary copy of the log dies or goes offline.
You continue on because the log device is still "good". If your
machine crashes and the primary log device is "rediscovered" on
bootup, what happens? The contents of the stale side will be
copied - resulting in your log not properly reflecting the state
of your mirror device and maybe even leaving inconsistencies.
This is a problem with any mirror, not just one holding a mirror log.
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.
You might argue that we should update the metadata to exclude the
failed primary at the point of failure. Two things come to mind:
1) log I/O will continue until you take action - leaving you open
to the scenario above
2) it would be simpler to just allocate a new log (since you are
changing metadata anyway) and initialize the log as "in-sync" if
the mirror is already "in-sync".
Yes, once one drive fails, the metadata on the other drive should
indicate that the mirror is broken and this is now the most up to
date copy.
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.
brassow
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
