home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / bsd / 8645 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  6.2 KB
  1. Path: sparky!uunet!ukma!usenet.ins.cwru.edu!agate!toe.CS.Berkeley.EDU!bostic
  2. From: bostic@toe.CS.Berkeley.EDU (Keith Bostic)
  3. Newsgroups: comp.unix.bsd
  4. Subject: Re: Largest file size for 386BSD ?
  5. Date: 9 Nov 1992 18:58:25 GMT
  6. Organization: University of California, Berkeley
  7. Lines: 128
  8. Message-ID: <1dmcchINNt54@agate.berkeley.edu>
  9. References: <1992Nov6.031757.20766@ntuix.ntu.ac.sg> <1992Nov6.173454.17896@fcom.cc.utah.edu>
  10. NNTP-Posting-Host: toe.cs.berkeley.edu
  11.  
  12. There are four issues for file size in a UNIX-like system:
  13.  
  14.     1: the off_t type, the file "offset" measured in bytes
  15.     2: the logical block type, measured in X block units
  16.     3: the physical block type, measured in Y block units
  17.     4: the number of meta-data blocks you can access
  18.  
  19. The off_t is the value returned by lseek, and in all BSD systems with
  20. the exception of 4.4BSD, it's a 32-bit signed quantity.  In 4.4BSD,
  21. it's a 64-bit signed quantity.  (As a side-note, this change broke
  22. every application on the system.  The two big issues were programs that
  23. depended on fseek and lseek returning similar values, and programs that
  24. explicitly casted lseek values to longs.)   The 32-bit off_t limit
  25. means that files cannot grow to be more than 2G in size, the 64-bit
  26. limit means that you don't have to worry about it 'cause the next three
  27. limits are going to kick in.  So, the bottom line for this limit is
  28. 2^off_t - 1, because a single out-of-band value, -1, is used to denote
  29. an error.
  30.  
  31. The second limit is the logical block type, and in a BSD system is a
  32. daddr_t, a signed 32-bit quantity.  The logical block type is the
  33. number of logical blocks that a file may have.   The reason that this
  34. has to be a signed quantity is that the "name space" for logical blocks
  35. is split into two parts, the data blocks and the meta-data blocks.
  36. Before 4.4BSD, the FFS used physical addresses for meta-data, so that
  37. this division wasn't necessary.  However, this implies that you know
  38. the disk address of a block at all times.  In a log-structured file
  39. system, since you don't know the address until you actually write the
  40. block (for lots of reasons), the "logical" name space has to be divided
  41. up.  In the 4BSD LFS (and the 4.4BSD FFS and the Sprite LFS) the
  42. logical name space is split by the top bit, i.e. "negative" block
  43. numbers are meta-data blocks.  So, the bottom line for this limit is
  44. 2^31 logical blocks in a file.
  45.  
  46. The third limit is the physical block type.  In UNIX-like systems, the
  47. physical block is also a daddr_t.  In the FFS, it's the fragment size,
  48. and the FFS addresses the disks in units of fragments, i.e. an 8K block
  49. 1K fragment file system will address the disks in 1K units.  This limits
  50. the size of the physical device.
  51.  
  52. The fourth limit is the number of data blocks that are accessible
  53. through triple-indirect addressing.  In 4BSD there are 12 (NDADDR) direct
  54. blocks and 3 (NIADDR) levels of indirection, for a total of:
  55.  
  56.     NDADDR +
  57.         NINDIR(blocksize) + NINDIR(blocksize)^2 + NINDIR(blocksize)^3
  58.  
  59. data blocks.
  60.  
  61. Given 64-bit off_t's, and 32-bit daddr_t's, this all boils down to:
  62.  
  63. Block size    # of data blocks    Max file size    Limiting type
  64.   .5K           2113676        ~  1G        4
  65.  1K          16843020        ~ 16G        4
  66.  2K         134480396        ~262G        4
  67.  4K        1074791436         ~ 4T        4
  68.  8K        2147483648         ~16T        2
  69. 16K        2147483648         ~32T        2
  70.  
  71. Note 1:
  72.     For 32-bit off_t's, the maximum file size is 2G, except for 512
  73.     byte block file systems where it's 1G.  The limiting type for
  74.     all of these is #1, except for 512 byte block file systems where
  75.     it's #4.
  76.  
  77. Note 2:
  78.     If we go to 64-bit daddr_t's, the branching factor goes DOWN,
  79.     because you need 8-bytes in the indirect block for each physical
  80.     block.  The table then becomes:
  81.  
  82. Block size    # of data blocks    Max file size    Limiting type
  83.   .5K            266316        ~130M        4
  84.  1K           2113676        ~  2G        4
  85.  2K          16843020        ~ 32G        4
  86.  4K         134480396        ~512G        4
  87.  8K        1074791436         ~ 8T        4
  88. 16K        8594130956        ~128T        4
  89.     
  90.  
  91. >In article <1992Nov6.031757.20766@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
  92.  
  93. >>This will be an important issue because soon we'll have hundreds of gigabytes,
  94. >>instead of magabytes soon.
  95. >>    It took the jump from tens mega to hundreds in just 10 years.
  96.  
  97. There are two issues that you need to consider.  The first is the actual
  98. physical data that you have, which can probably be satisfied, in 99.99
  99. percent of the cases, by 2G, let alone 16T.  The latter figure is also
  100. probably fine given what we can physically store on both magnetic and
  101. tertiary storage.  While it is true that big files are getting bigger (by
  102. roughly an order of magnitude), most files are about the same size they
  103. were ten years ago, i.e 40% are under 1K and 80% are under 20K [SOSP '91,
  104. Mary Baker, Measurements of a Distributed File System].  Even that order
  105. of magnitude isn't all that interesting for this case, as most files simple
  106. aren't larger than 16T.
  107.  
  108. The second issue is the addressibility of the data.  Some applications
  109. want to store large objects (measured in megabytes) in a huge sparse file.
  110. These applications may have a 2G disk, but want files sized in terabytes.
  111. There is no satisfactory answre on most current UNIX systems, but the
  112. 64-bit daddr_t's would seem to make the situation better.
  113.  
  114. In article <1992Nov6.173454.17896@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
  115.  
  116. >Get around the problem:
  117. >
  118. >1)    Multiple partitions not exceeding the 4 Gig limit.
  119. >2)    Larger terminal blocks.
  120. >3)    Additional indirection levels.
  121. >4)    Assumption of larger files = log-structure file systems (ala Sprite).
  122.  
  123. The interesting point for me is #4 -- although I'm not real sure what
  124. you meant.  The advantages of LFS are two-fold.  First, the features
  125. that theoretically would be available to applications, due to its
  126. no-overwrite policy, are attractive, e.g. "unrm", versioning,
  127. transactions.  Second, with multiple writers it has the potential for
  128. improved performance.
  129.  
  130. It is becoming clearer, at least to me, that the LFS performance
  131. advantages are not as obvious as they originally appeared, mostly
  132. because of the strong effects of the cleaner.  I'm starting to agree
  133. with Larry McVoy of [USENIX, January 1991, Extent-like Performance
  134. from a UNIX File System] that FFS with read/write clustering is just
  135. as fast as LFS in many circumstances, and faster in lots of large-file
  136. applications where the disk is over, say, 80% utilized.
  137.  
  138. Keith Bostic
  139.  
  140.