It is a perfect answer for my questions, more than I have expected.
However, we met a strange thing for our DM application:
Our simple DM application running on Linux/XFS. Its task is to monitor
the file read event.
In the experience:
1.start the DM application.
2.set READ region for a file.
3.kill the DM application.
4.read that file.
Then the system will hang, umount the xfs partition will fail too.
In above exercise, after the DM app is killed, no thread will take the role doing dm_get_event().
So that the read event will not be in delivered state. But it does hang our read process.
What's that, is there other issue result to this, like bad mount option...
On Wed, Jul 12, 2006 at 10:22:09PM +0800, Michael Li (gmail) wrote:
> Hi, all,
> As I know, DMAPI event can be in 2 states:
> 1) enqueued, undelivered
This is sitting on sn_newq.
> 2) delivered and awaiting a response from the DM application.
This is sitting on sn_delq.
> The 2nd state also know as outstanding state for synchronous event
> message. I'd like to know the exact meaning of "delivered",
> Does "delivered" means the DM application had call dm_get_event() on the
Yes, delivered means the HSM has retrieved it with dm_get_events(). This is
the only place you should see a dm_unlink_event(sn_newq) and a matching
dm_link_event(sn_delq). It doesn't go onto sn_delq unless it's a sync
as determined by looking at the ev_token field and you can see that's set in
dm_enqueue() only for sync events.
> Can an event message automatically change state from 1 to 2 when it is
> Is there a list of the events that will always change state to
> delievered state after it is enqueued?
The "user" event, DM_EVENT_USER. Ug. This is how an HSM can drop a marker
directly into the "delivered" queue. A user event never enters sn_newq. I
supposed an HSM would have multiple sessions, and would be moving events
around between sessions for something...er other. Don't ask me how this
Of course, dm_move_event() can pull an event off one session's delq and
to another session's delq.