> wouldnt it be better to first look up newly created inodes, and wait for
> still pending operations if still present? [new inodes wont be present
> locally 99% of the cases]. We should not assume anything about the order
> RPC requests get scheduled by the server, me thinks.
To implement that we would need a way of holding up an inode lookup
until a pending change completes (or is aborted). There would need to be
a flag saying "pending operation", and then when the nfs call returned
we would clear the flag and wake up any waiters.
This would work well, but we currently don't have a "wait for pending
operation" capability in the inode lookup -- in this case it would be a
wait for the inode to be iput.
> Your suggestion i think works identically well, but it rather relies on
> the local directory being locked than on (more fundamental) RPC scheduling
> properties. So if one time we want to parallelize NFS operations more
> aggressively (eg. unlock the parent directory _before_ getting back a
> reply from the server?), we might be bitten by the 'early iput()' trick?
I think there should be room for more parallelizing without going to the
length of unlocking the parent directory. The whole VFS layer depends on
the parent lock for correctness, and that's already reasonably fine
grained (unless everything on the system is happening in one directory,
of course.)
> Plus, a 'filehandle number uniqueness check' might catch a few bugs as
> well.
Yes, I have been thinking about adding a filehandle check as a
diagnostic -- if we ever get a successful inode lookup with a
mismatched filehandle, it's big trouble.
Regards,
Bill