On Tue, 12 Feb 2008 19:13:03 -0500
Trond Myklebust <[email protected]> wrote:
>
> On Tue, 2008-02-12 at 08:20 -0500, Jeff Layton wrote:
> > On Fri, 08 Feb 2008 11:13:07 -0500
> > Trond Myklebust <[email protected]> wrote:
> >
> > >
> > > On Fri, 2008-02-08 at 10:56 -0500, Jeff Layton wrote:
> > >
> > > > If it looks like the above, but EOF is 0, then we *do* "goto
> > > > short_pkt", and that case would be affected by this. But in that case
> > > > we currently reset EOF to 1. The client won't retry the request. I'm
> > > > not sure that's what we want to do either...
> > >
> > > That is to deal with the afore-mentioned broken server. I'm not
> > > unwilling to change this (I _hate_ client side fixes for server bugs),
> > > but it's important to note that there may be consequences if we do.
> >
> > Perhaps we can just narrow down this special case so that this server
> > still works, but we can return a proper error when we get other bogus
> > packets? We currently have this:
> >
> > if (!nr && (entry[0] != 0 || entry[1] == 0))
> >
> > ...but if nr==0, then I think entry[0] must be 0 as well. So, I'm
> > guessing that the server always set value_follows=0 and EOF=0. Is that
> > correct?
> >
> > If so, what about something like the following patch? This should
> > hopefully make it so that packets that are badly sized return -EIO, but
> > the special case you mention should continue to work.
>
> Yup. This looks like it should cover most known cases...
>
> Cheers
> Trond
>
Good. I still need to test this out, but was wondering what your
thoughts are on keeping the client-side hack in place for NFSv3 and
NFSv4? Should we remove it from either or both of the later NFS
versions?
Thanks,
--
Jeff Layton <[email protected]>