Message-ID: <4231B06E.4020706@ocre.cea.fr>
Date: Fri, 11 Mar 2005 15:51:26 +0100
From: Aurelien Degremont - Stagiaire <degremont@ocre.cea.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: Dean Roehrich <roehrich@sgi.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: DMAPI implementation about undeliverable event messages
References: <20050308173802.A408E4FDD1@chewtoy.americas.sgi.com>
In-Reply-To: <20050308173802.A408E4FDD1@chewtoy.americas.sgi.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-xfs-bounce@oss.sgi.com
Errors-to: linux-xfs-bounce@oss.sgi.com
Precedence: bulk
Content-Length: 882
Lines: 26

Dean Roehrich a écrit :
> Well, let's back up.  Why is your HSM application not present?  Why did it
> destroy its sessions, but not unregister the events it had put on the
> filesystem?

Yes, I agree this error occurs only because of algorithm error. The HSM 
app should have unregistered the events before destroying its sessions.
(err... why notification could be persistent in we must always removed 
them ?)

I just wanted to say it will be "better" if DMAPI no not block in this 
particular case.

With all other events, it is still possible to recover when a event is 
raised with no application to catch it. A DM app is still abled to 
register and fetch it later, except for UNMOUNT event.

So, if the code could be fixed to work around this problem, ok, let's do 
it, else that's a pity.


(The issue occured also with the DM_PREUNMOUNT_EVENT, same behaviour)


Aurelien