On Tue, 2005-04-19 at 11:09 -0400, Paul Alfille wrote: > The bad news: NFS seems to depend on a filehandle. It is an opaque 64 byte > structure. We'll have to generate it for every path and verify it with every > access, since it goes to and from the client.
It doesn't just seem to. The NFS "vnode" or "filehandle" is how NFS works. > Proposals for the filehandle: > > 1. Make a hash of the path and store in temporarily. This is a bad idea. This is why the unfsd is bad- if the server crashes and then comes back, all the clients are hosed. > 2. Use the device serial number and filetype and extension <[EMAIL PROTECTED]> This was part of a thread where I brought up doing this for other reasons-- regarding the cache code -- and to look up entries faster. Using a pair of functions - even if they're generated by a perl script- to construct "vnodes" or 20-bit cacheids or whatnot- from file NAMES, and back again, makes this problem go away. It also simplifies caching as we know immediately where in the cache to look. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/ ------------------------------------------------------- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
