As I looked through the specs on nfs I was encouraged at first be the "stateless" design, until I found they cheated.
First of all, a good reference: http://www.freesoft.org/CIE/Topics/115.htm And from that, the protocol: http://www.freesoft.org/CIE/RFC/1813/index.htm The good news: open and close are largely ignored. Read and write and directory are supported. Much of the problems with NFS design, locking, files changing "underneath" the nfs layer, files disappearing or being renamed in another thread are handled elegantly by owlib and can be ignored by our server. Indeed, we don;t need to keep track of mounted clients, mount points, commits, symlinks, or file/directory rename, creation or deletion. We also don't need to worry about setting file attributes. (By this, I mean the client doing these tasks. Clearly the bus can change). 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. Proposals for the filehandle: 1. Make a hash of the path and store in temporarily. 2. Use the device serial number and filetype and extension (1) The first technique requires unknown memory (though can be arbitrarily limited) and needs some way of clearing old entries. Hash collisions must be a solved problem. The lookup (filehandle part) might even skip owlib entirely, and be done purely on the text of the path. Works well for branching -- with the NFS path length of 1024, maximum branching is around 70 layers deep. Listing large directories will fill the filename hash table quickly (6000 entries for the Thermochron alone). With a pathname of ~50 characters that would be 300K. (2) The second technique requires no added memory and allows unlimited clients to be hitting the server simultaneously. 64 bytes limits the maximum depth of branching to around 7-8 levels. Filehandles would be permanently valid. (Combination) Probably the best approach would be to use the second method for to device/filename and add a cache for long branch paths. Paul ------------------------------------------------------- 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
