lkml.org 
[lkml]   [1997]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.154 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site