On Thu, 2011-01-20 at 10:42 +1100, Nick Piggin wrote: > On Thu, Jan 20, 2011 at 10:39 AM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > > > On Jan 19, 2011, at 6:37 PM, Nick Piggin wrote: > > > >> On Thu, Jan 20, 2011 at 10:31 AM, Trond Myklebust > >> <Trond.Myklebust@xxxxxxxxxx> wrote: > >>> On Thu, 2011-01-20 at 10:26 +1100, Nick Piggin wrote: > >>>> On Thu, Jan 20, 2011 at 10:25 AM, Trond Myklebust > >> > >>>>> Also, why is EIO the correct reply when no bytes were read/written? Why > >>>>> shouldn't the VFS aio code be able to cope with a zero byte reply? > >>>> > >>>> What would it do? > >>> > >>> Just return that zero byte reply to userland. > >>> > >>> zero bytes is a valid reply for ordinary read() and write(), so why > >>> should we have to do anything different for aio_read()/aio_write()? > >> > >> It doesn't give userspace much to do. zero reply from read means > >> EOF. Zero reply from write is pretty useless, I don't think we do it > >> in the buffered write path -- we either ensure we write at least > >> something or have a meaningful error to return. > > > > I think in this case, the zero-length requests are already shunted off. No zero-length requests make it down here, IIRC. So we expect that either some bytes are started, or an error occurs. If zero bytes were started and no error occurred, that's just... wrong. > > Right. So in this case you should have an error to return. So, which error??? What is going wrong that ensures that we don't start any I/O. Is it the pages that are failing to fault in, is it the RPC call that is failing to start (if so, why)? I don't like to be returning EIO if a more specific (and useful) error exists. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
