On Tue, 1 May 2012 23:04:51 +0000 "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> 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:
signature.asc
Description: PGP signature
