Messages in this thread | | | Date | Fri, 14 Nov 1997 16:07:49 -0500 | From | Bill Hawes <> | Subject | Re: knfsd and system crashes |
| |
Olaf Kirch wrote: > While this file handle is invariant across system reboots, it has other > problems. Probably the worst is that it is not invariant against renames. > Try this on an NFS-mounted partition: > > mkdir zappa > (mv zappa/frank .; echo "You lose") > zappa/frank > > and you should get 'stale file handle', or, on 2.0.30, an empty file. > (I guess there's a problem with error propagation in the flush-on-close > stuff in NFS). This problem also affects the dentry-stuff file handle > layout, BTW.
Hi Olaf, Thanks for your comments on the nfs fh issues.
I've changed the dentry validation so that we can now validate a renamed dentry. Currently I'm still requiring that the dentry be in the same parent directory, though this could probably be relaxed too.
> Another problem is that unfsd uses a file handle cache at all. I don't > recall what the exact size is, but regardless how large you make it, > for any real work it will always be too small and start thrashing. Combine > that with the above algorithm and you quickly start wondering why people > don't complain about it any louder than they currently are.
The advantage of having the dentry pointer in the fh, assuming it can be validated, is that the system already maintains the dentry cache.
> Basically, the _only_ way to do NFS correctly is to put dev/inode number > into the file handle and use them to retrieve the inode/dentry/whatever. > This is the way Sun's implementation works, and this is what the NFS spec > reflects. Read it, and you'll find that there's really no other way to > do it on a Unix box if you want to be 100% compliant.
OK, I've done this. Current layout has dentry pointer (a cookie actually, until it's validated), ino, parent ino, device, and xino/xdev.
I've currently got the third-level (when we have a parent dentry) search working, but I'm a little unclear on the best strategy for implementing the full volume search given device number and parent inode/inode number. Can you offer some suggestions here?
With regards to recovery after reboot/restart, I've come up with a scheme that I think will address concerns about what happens when all of the dentry pointers become invalid. The first time such a filehandle is presented we have to do a full lookup, but I plan to cache the results as a "patch up" cache, indexed by hashed (dev, inode). Normally this cache will be very small or empty. When the client subsequently presents the old filehandle, we then check the patch-up cache before proceeding to the full search (maybe even before trying to validate the dentry.)
Entries can be kicked out of the patch-up cache after a few minutes, keeping it nearly empty for fast searching. I think this will allow a quick recovery from restarting the nfs server.
Regards, Bill
| |