PS: I'm not subscribed, please keep me in CC.
I got the possibility to work on dm-mirror as a final year project at
ULX, the Hungarian distributor of Red Hat.
Get my feet wet, I created two small patches:
1) dm-mirror: allow setting ios count to 0
Always read from the default_mirror in that case.
2) dm-mirror: allow setting the default mirror
These can help in case one data leg of a mirror is a remote (iSCSI) one,
so the default RR aproach is not optimal for reading. (One may set the
ios count to 0, set the default mirror to the local one, and that will
cause a read speedup.)
I do not yet have the right to send those patches (I do this in
university time, so the copyright is not mine), but I hope to be able to
do so - to get them reviewed.
So the final year project's aim is to improve "the fault tolerance and
performance of dm-mirror". We (I and my mentors) have two ideas in that
area, not counting the above patches:
1) Make the currently hardwired RR read approach modular, that would
allow implementing for example a weighted RR algorithm. (In case one
disk is two times faster than the other one, etc.)
2) From our experiments, it seems that in case the dm-mirror looses one
of its legs and there is a write to the mirror, it gets converted to a
linear volume. It would be nice (not sure how easy) to use the mirror
log to mark the dirty blocks, so that the volume would not be converted
to a linear one: once the other leg is back, it could be updated based
on the mirror log.
The question: what do you (who have much more experience with dm-mirror
than me) think - are these reasonable goals? If not, what would you
improve/change/add/remove to the above list?