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
|