home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / protocol / nfs / 2944 < prev    next >
Encoding:
Text File  |  1992-12-14  |  2.4 KB  |  55 lines
  1. Newsgroups: comp.protocols.nfs
  2. Path: sparky!uunet!wupost!spool.mu.edu!umn.edu!csus.edu!netcom.com!netapp
  3. From: hitz@netapp.com
  4. Subject: Re: NFS cookies
  5. Message-ID: <1992Dec14.053207.5392@netcom.com>
  6. Sender: netapp@netcom.com (Network Appliance)
  7. Organization: Netcom - Online Communication Services (408 241-9760 guest)
  8. References: <7594@fury.BOEING.COM>
  9. Date: Mon, 14 Dec 1992 05:32:07 GMT
  10. Lines: 43
  11.  
  12. In article <7594@fury.BOEING.COM> krm@sdc.boeing.com (Keith Michaels) writes:
  13. >Does anyone know what the practical limitations are for the 32 bit 
  14. >NFS "cookie" that is used in the READDIR function?  
  15.  
  16. >Also, is there any truth to the rumor that the first byte of the cookie is
  17. >reserved for use by the client?  
  18.  
  19. Here is what the NFS 2 spec (RFP 1094) has to say about the directory entries
  20. returned by READDIR:
  21.  
  22.     Each "entry" contains a "fileid" which consists of a unique
  23.     number to identify the file within a filesystem, the "name" of
  24.   |    the file, and a "cookie" which is an opaque pointer to the next
  25.   |    entry in the directory.  The cookie is used in the next READDIR
  26.   |    call to get more entries starting at a given point in the
  27.   |    directory.  The special cookie zero (all bits zero) can be used
  28.   |    to get the entries starting at the beginning of the directory.
  29.  
  30. The word "opaque" here means that the server is allowed to put
  31. absolutely anything in this field that it wants to.  No reserved byte
  32. for clients.  No restriction on what characters to use.
  33.  
  34. >How can NFS guarantee correct behavior of an operation that exhausts the
  35. >address space of the cookie?  
  36.  
  37. This isn't a problem.  With a 32-bit cookie, there are 2^32 possible
  38. cookies.  It's hard to imagine a directory structure much smaller than
  39. 16 bytes per entry, so a directory big enough to exhaust the cookie
  40. space would be about 32 GB.
  41.  
  42. >This is not just of theoretical interest! We have acually hit this problem 
  43. >on recursive operations like find.
  44.  
  45. It is very unlikely that this is the reason for your problem.  As
  46. someone else pointed out, most UNIX servers use as their "cookie" the
  47. offset of the directory entry in a given directory.  The problem is,
  48. when a directory gets compacted, the offset of directory entries can
  49. change.  This results in the offset pointing to the wrong location.
  50. Depending on how the server handles this, some directory entries will be
  51. repeated, or else some will not be reported at all.
  52.  
  53. Dave Hitz            hitz@netapp.com
  54. Network Appliance         (408) 562-1906
  55.