home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / wizards / 5356 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  2.7 KB
  1. Path: sparky!uunet!think.com!ames!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek
  2. From: torek@horse.ee.lbl.gov (Chris Torek)
  3. Newsgroups: comp.unix.wizards
  4. Subject: Re: file system layout
  5. Date: 1 Jan 1993 00:08:16 GMT
  6. Organization: Lawrence Berkeley Laboratory, Berkeley CA
  7. Lines: 55
  8. Message-ID: <28188@dog.ee.lbl.gov>
  9. References: <1992Dec30.163131.17280@ll.mit.edu> <lk6u47INN47f@appserv.Eng.Sun.COM>
  10. NNTP-Posting-Host: 128.3.112.15
  11.  
  12. In article <1992Dec30.163131.17280@ll.mit.edu> singer@ll.mit.edu
  13. (Matthew R. Singer) writes:
  14. >>Since I am writing just one big file on a newly formatted disk, it
  15. >>should be contiguous (right?) [under SunOS].
  16.  
  17. In article <lk6u47INN47f@appserv.Eng.Sun.COM> lm@slovax.Eng.Sun.COM
  18. (Larry McVoy) writes:
  19. >Nope.  Even though I wacked it to do contig allocation when it can, it
  20. >still switches cylinder groups every meg or so.  I suppose you could
  21. >dick around with the tuning parameters to make one mondo cyl group.
  22.  
  23. The `change groups' strategy exists to prevent the local clustering
  24. tactics from turning the file system into a series of unmanageable
  25. clumps.  By forcing a seek every 1 MB or so, the file system tries to
  26. guarantee a high probability of a `well positioned' block being
  27. available whenever needed.  Without this, large files would fill their
  28. primary cylinder group, and new files created in that group would get
  29. scattered hither and yon.
  30.  
  31. Of course, if you are just going to write one single file on a disk,
  32. the file system policies work against you.  Then again, if you are
  33. going to use the entire disk as a single file, you hardly need a file
  34. system at all....
  35.  
  36. Incidentally, Margo Seltzer found the following bug in the original BSD
  37. block allocator:
  38.  
  39. [ffs_alloc.c: your line numbers will differ; in fact your code might
  40. even differ a bit, and/or be found in ufs_alloc.c.  Presumably this is
  41. fixed in SunOS.]
  42. ***************
  43. *** 458,464 ****
  44.      */
  45.     nextblk = bap[indx - 1] + fs->fs_frag;
  46. !     if (indx > fs->fs_maxcontig &&
  47. !         bap[indx - fs->fs_maxcontig] + blkstofrags(fs, fs->fs_maxcontig)
  48. !         != nextblk)
  49.         return (nextblk);
  50.     if (fs->fs_rotdelay != 0)
  51. --- 464,469 ----
  52.      */
  53.     nextblk = bap[indx - 1] + fs->fs_frag;
  54. !     if (indx < fs->fs_maxcontig || bap[indx - fs->fs_maxcontig] +
  55. !         blkstofrags(fs, fs->fs_maxcontig) != nextblk)
  56.         return (nextblk);
  57.     if (fs->fs_rotdelay != 0)
  58.  
  59. Kirk got the test backwards originally, so the tunefs -a parameter
  60. never mattered....  I no longer have VAXen, but I am curious as to
  61. whether this fix might improve performance on the old RA81 disks.  I
  62. was never able to tune those at all; the performance was always
  63. miserable, never more than a few hundred K per second.
  64. -- 
  65. In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
  66. Berkeley, CA        Domain:    torek@ee.lbl.gov
  67.