xfs
[Top] [All Lists]

Re: Re: Re: Delivered state of DMAPI Event

To: dean.roehrich@xxxxxxx, xfs@xxxxxxxxxxx
Subject: Re: Re: Re: Delivered state of DMAPI Event
From: "Michael Li (Gmail)" <mikore.li@xxxxxxxxx>
Date: Fri, 14 Jul 2006 11:07:40 +0800
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=LFQob0eIsUM0VlFn/ppyscnrKDxoNFMb4DuiOg9AUs9F7IsOz9hRHCbUx5gmo+18keaeEfxWzW6zGMYa+DO97t9ESgTfCB0L/q+/F94DZvdTMSILJiBk9PiYhrwYzS0iATskZtpW3/oeAnn3gb+s8QQBL4tcosv3950IMzTXdCs=
Sender: xfs-bounce@xxxxxxxxxxx
Hi, Dean,

You are right, system will not hang but only the read process, from my
current knowlege of DMAPI

The read process should not run in hang, since the dm_get_events() will not
be called(dm app not exist),

so that the read event message will not be delivered from nq to dq, from my
understanding, it is the only

reason that the read event message's state will be changed to outstanding,
in which state, the read process

will run in a hang. Am I wrong?

From your point of view, can we say: when the read event is generated, it
must be in outstanding state soon, or in other words:

The sync event message must be get/response by dm app, if the dmapi is in
the I/O path, otherwise the related laucher will be hang?

Or: No matther the event is outstanding or not, if it is read event and
DMAPI enabled, it will cause a read process hang although the event will not
be in delivered state(outstanding state)?

Thanks,

Michael



On Fri, Jul 14, 2006 at 01:35:56AM +0800, Michael Li (gmail) wrote:
> Dean:
>
> 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.

So here you insert DMAPI into the I/O path for this file...

> 3.kill the DM application.

At this point you've disabled part of the I/O path for that file...

> 4.read that file.

And this is waiting for that I/O path to be restored.



> Then the system will hang, umount the xfs partition will fail too.

I don't believe that the entire system will hang--the only things hanging
are
reads on that file.  I agree that the filesystem is busy and will not
unmount.

The read process is not holding any XFS locks or linux inode semaphores
(unless there's a new bug), so it's not holding up anyone that way.


> 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...

> token related?

Someone needs to process the DMAPI events.  Restart your DM app.

What did you want your read process to do?  Did you want the read system
call
to fail?

Dean


[[HTML alternate version deleted]]


<Prev in Thread] Current Thread [Next in Thread>