Re: [PATCH] NFS: Adapt readdirplus to application usage patterns

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]

On Tue, 1 May 2012 23:04:51 +0000 "Myklebust, Trond"
<Trond.Myklebust@netapp.com> wrote:

> > Also, the current code will clear NFS_INO_ADVISE_RDPLUS if it gets -ETOOSMALL,
> > and it will stay cleared until the inode falls out of cache and is reloaded.
> > The new code will set it again a lot sooner.  Is that likely to be a problem
> > (I don't remember what conditions lead to ETOOSMALL)?
> > In fact I think it will ignore  the ETOOSMALL and always retry with
> > readdirplus for the first read in a directory.  That doesn't seem good ?
> 
> ETOOSMALL means that there isn't enough buffer space to fill a full
> record. Given that we now provide > 32k buffer space, that seems like it
> would be extremely difficult to produce. Even a Linux server, with its
> 4k total limit should be able to provide at least 1 readdirplus record.
> 
> If we do find a directory that keeps triggering the ETOOSMALL, then I
> suppose we can add a NFS_INO_FORBID_RDPLUS flag to turn readdirplus off
> permanently for that directory. However until I find that particular
> beast, then I'd be inclined to wait.
> 

I can't argue with that.  And looking at the code again it does disable
readdirplus for at least the next request by setting "desc->plus = 0".
So: all good.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]