>From: Ben Myers <dative@xxxxxxxxxxx>
>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, tha
>t
>> 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?
There's a user thread in the kernel, attempting to execute a write(2). That
thread was temporarily caught in the dmapi queues, and you've now released it
with dm_respond_event. Now that thread is going to continue on to the
filesystem where some I/O will occur. This isn't about getting the data
sync'd--it's about waiting long enough for that thread to back itself out of
the dmapi queues and reacquire locks and get back into the filesystem to do
some I/O.
>> 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.
Logging of the contents of every write?
Dean
|