Re: patch to head and 2.4 for diskd

From: Adrian Chadd <adrian@dont-contact.us>
Date: Sat, 25 Nov 2000 22:44:51 +0800

On Fri, Nov 24, 2000, Andres Kroonmaa wrote:
> On 25 Nov 2000, at 2:58, Adrian Chadd <adrian@creative.net.au> wrote:
>
> > Here is a patch against HEAD. If you assert() on the close_request with
> > this patch inside storeDiskdReadDone() to die if close_request is 1,
> > I can reliably triugger it by ctrl-C'ing a polyclt during a polygraph
> > run.
> >
> > Can someone check my logic here? We only have a single op on an FS
> > (read or write) scheduled on one sio at a time, so we can implement
> > a cancel based on close_request ..
>
> I'm not familiar with diskd, (aufs also not too well), but it seems
> to me that we cannot safely issue close request until we have dequeued
> pending read. And as this happens from callback checks, we can't really
> do much other than flag pending read for cancel. We can do that at
> close_request, but we shouldn't callback handlers if any disk op is
> pending. We should relay on checkcallbacks to call done handlers, who
> check for flags.close_request and do what we need.

Thats basically what I do! I've found that if the callback isn't valid
then the sio is part of a client abort, hence why that assert is there.
I'm more interested to see whether that assertion gets triggered
inside the if (valid) { } statement block.

And yes, I agree that we can't issue a Close until the last read comes back,
but this would require changing the store client abort sequence to wait for
the pending read to complete before the store client finally goes away,
and I don't think the sequence needs to be hanged right now.

(This will be one more failure condition I'll take into account in this
storage manager..)

Has anyone else got any comments on this patch? I'd like to commit it
tonight and then look at aufs a little closer..

Adrian

-- 
Adrian Chadd			"God: Damn! I left pot everywhere!
<adrian@creative.net.au>	  Now I'll have to create Republicans!"
				    - Bill Hicks
Received on Sat Nov 25 2000 - 07:44:58 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:00 MST