Re: [PATCH linux-2.6.1-rc1-mm1] aiodio_fallback_bio_count.patch

[Suparna Bhattacharya]

On Thu, Jan 01, 2004 at 11:46:34PM -0800, Andrew Morton wrote:
> Suparna Bhattacharya <suparna@xxxxxxxxxx> wrote:
> >
> >  Does the following sound better as complete description ?
> 
> It does, thanks.  But it does not shed a lot of light on the filemap.c
> changes - what's going on there?
> 
> What is the significance of `written > count' in there, and of `dio->result
> > dio->size' in finished_one_bio()?  How can these states come about?
> 

Both of these are checks to determine whether all or only a part of
the request was serviced by DIO, leaving the rest to be serviced by
falling back to buffered I/O.

Earlier, we would decide this based on whether dio->result == -ENOTBLK
and written == -ENOTBLK respectively. However, now that we also need the 
result to indicate how much actually got written even in -ENOTBLK case, 
so that we can issue buffered i/o only for the remaining part of the request,
dio->result and written had to be modified to reflect the number of bytes 
transferred by DIO even for the fallback to buffered i/o case. 
So we need checks like this to find out whether there is some i/o left
to be issued via buffered i/o.

If dio->result == dio->size, then the entire request has been handled
by DIO and we don't have to bother about falling back to buffered i/o.
Otherwise, even for AIO, need to force a wait for the part of the
request already issued.

If written == count, then the entire request has been handled by DIO;
otherwise, if written < count, it means that we need to fallthrough to
buffered i/o for the remaining bytes.

What about short writes ? Most real errors during DIO write are 
reflected in the return value directly, so we should be OK (Worst case 
we'd end up with an additional but harmless attempt via buffered i/o,  
however, I didn't spot a case where that would actually occur).

Regards
Suparna

-- 
Suparna Bhattacharya (suparna@xxxxxxxxxx)
Linux Technology Center
IBM Software Lab, India

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/