Agreed dirty region logging will be handled directly by the in kernel
mirror target, in the same way that the snapshot exception table is
handled by the snapshot target.
I guess when I think of metadata I'm really thinking of the mappings
that describe whole volumes, rather than any internal data that a
particular target may use. I think this is an appropriate divide,
presumably EVMS stores the dirty bitmap for a mirror in the same way
irrespective of whether the volume group metadata is in AIX or LVM1
> On the facility used to notify userland processes of events, how
> are the userland programs notified?
There are 2 ioctls, one which gets the status for all the targets in a
device, and another that blocks until that status changes. It is up
to the target implementor to decide what is returned in the status,
and to declare when this status has changed.
So you will need a daemon if you are waiting for an event. For
instance pvmove needs no additional kernel code to be implemented,
instead it just uses a mirror target to keep the old and new mappings
in sync. When the mirrors initial sync has been completed pvmove
notices the change in status, removes the mirror and updates the
device to use the new mapping.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/