On Thu, 03 Feb 2005 17:50:29 -0600, Ben Myers <dative@xxxxxxxxxxx> wrote:
> On Thu, 2005-02-03 at 14:25 -0600, Dean Roehrich wrote:
> > The dm_read_invis will see what was written by the write(2), provided the
> > write has occured. The write(2) won't actually happen until sometime after
> > your call to dm_respond_event.
> >
> > Your data migration app cannot know when the write(2) (that goes with the
> > DM_EVENT_WRITE) is finished. There's nothing in the DMAPI spec, anyway,
> > that
> > would provide for this--there's no such thing as DM_EVENT_POSTWRITE.
>
> Pity. DM_EVENT_POSTWRITE is exactly what I'm looking for. How about
> dm_sync_by_handle()? If I respond with DM_RESP_CONTINUE and then
> immediately sync that file, won't I block until the write is finished?
>
> > If mirroring or snapshotting is what you want, then maybe a volume manager
> > would be a better solution?
>
> I'm hoping for something more along the lines of logging.
>
If you can live with getting your log at the block level, then maybe
you could look at how drbd does dirty block logging.
IIRC, protocol-c ensures the log is built in the order that the blocks
are written. This is particularily important if a database is using
the disk. ie. a replay is transactionally valid at any point
including a partial log reply.
FYI: If you don't know, drbd ships the activity log to another
computer which replays it. That way if the first computer/disk dies,
the second computer can take over.
Greg
--
Greg Freemyer
|