home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / fj / os / 386bsd / 246 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  5.0 KB
  1. Path: sparky!uunet!ccut!news.u-tokyo.ac.jp!yayoi!tansei1!mhiroshi
  2. From: mhiroshi@tansei.cc.u-tokyo.ac.jp (H. Murakami)
  3. Newsgroups: fj.os.386bsd
  4. Subject: patch for ufs_alloc.c
  5. Message-ID: <3850@tansei1.tansei.cc.u-tokyo.ac.jp>
  6. Date: 8 Jan 93 13:44:47 GMT
  7. Sender: news@tansei.cc.u-tokyo.ac.jp
  8. Distribution: fj
  9. Organization: Hokkaido Univ. However I am subject to tansei for JUNET.
  10. Lines: 102
  11.  
  12. To: fj.os.386bsd
  13. Subject: patch for ufs_alloc.c
  14.  
  15. Disk block allocation $B$N<jB3$-$N%P%0(J(BSD$BA4HL(J).
  16.  
  17. ========> QUOTE <========
  18. From: bde@runx.oz.au (Bruce Evans)
  19. Newsgroups: comp.unix.internals,comp.unix.bsd
  20. Subject: Disk tuning (was Re: file system layout)
  21. Message-ID: <1993Jan1.102538.4626@runx.oz.au>
  22. Date: 1 Jan 93 10:25:38 GMT
  23. References: <1992Dec30.163131.17280@ll.mit.edu> <lk6u47INN47f@appserv.Eng.Sun.COM> <28188@dog.ee.lbl.gov>
  24. Organization: RUNX Un*x Timeshare.  Sydney, Australia.
  25. Lines: 76
  26. Xref: tansei1 comp.unix.internals:11211 comp.unix.bsd:10426
  27. Status: RO
  28.  
  29. In article <28188@dog.ee.lbl.gov> torek@horse.ee.lbl.gov (Chris Torek) writes:
  30. >Incidentally, Margo Seltzer found the following bug in the original BSD
  31. >block allocator:
  32. >
  33. >[ffs_alloc.c: your line numbers will differ; in fact your code might
  34. >even differ a bit, and/or be found in ufs_alloc.c.  Presumably this is
  35. >fixed in SunOS.]
  36.  
  37.  
  38. *** ufs_alloc.c.orig Fri Jan  8 04:35:50 1993
  39. --- ufs_alloc.c    Fri Jan  8 04:36:05 1993
  40. ***************
  41. *** 437,445 ****
  42.        * requested rotationally delayed by fs_rotdelay milliseconds.
  43.        */
  44.       nextblk = bap[indx - 1] + fs->fs_frag;
  45. !     if (indx > fs->fs_maxcontig &&
  46. !         bap[indx - fs->fs_maxcontig] + blkstofrags(fs, fs->fs_maxcontig)
  47. !         != nextblk)
  48.           return (nextblk);
  49.       if (fs->fs_rotdelay != 0)
  50.           /*
  51. --- 437,444 ----
  52.        * requested rotationally delayed by fs_rotdelay milliseconds.
  53.        */
  54.       nextblk = bap[indx - 1] + fs->fs_frag;
  55. !     if (indx < fs->fs_maxcontig || bap[indx - fs->fs_maxcontig] +
  56. !         blkstofrags(fs, fs->fs_maxcontig) != nextblk)
  57.           return (nextblk);
  58.       if (fs->fs_rotdelay != 0)
  59.           /*
  60.  
  61. >Kirk got the test backwards originally, so the tunefs -a parameter
  62. >never mattered....  I no longer have VAXen, but I am curious as to
  63. >whether this fix might improve performance on the old RA81 disks.  I
  64. >was never able to tune those at all; the performance was always
  65. >miserable, never more than a few hundred K per second.
  66.  
  67. 386BSD-0.1 still has the old version (assuming that the above patch is
  68. not backwards :-).
  69.  
  70. I tried tuning a Seagate 330MB ESDI disk under 386BSD yesterday.  The
  71. tunefs -a parameter worked like I expected: increasing it increased read
  72. performance and reduced write performance.  This is because my disk
  73. controller (a WD1007V-SE1) takes too long in between separate write
  74. commands and the 386BSD driver does not coalesce contiguous blocks
  75. into a single write command (nor does ufs give it enough opportunities
  76. to do so).  Separate read commands are not so much of a problem because
  77. the slow controller is disguised by caching in the controller.
  78.  
  79. I get best results with tunefs -a 1 -d 1 and a block size of 4K.  The
  80. default rotational delay is 4 msec, which corresponds to 14 sector times
  81. or 2 blocks or at best 33% efficiency :-(.  A rotational delay of 0
  82. works poorly for writing.  Rotational delays of 1 msec and 2 msec both
  83. correspond to 1 block and work OK (for at best 50% efficiency).  A larger
  84. block size wouldn't help because _some_delay between blocks is required,
  85. and the minimum delay of 1 block time always reduces the maximum
  86. efficiency to 50%.  (Actually, for large files I get very close to 25%
  87. efficiency on 15Mb/sec drive and not so close to 50% efficiency on a
  88. 10Mb/sec drive, because the faster drive has to be formatted at 2:1
  89. interleave for the controller's caching to keep up.  At 2:1 interleave
  90. the timing is not very critical so it is easier to get close to the
  91. maximum possible efficiency.)
  92.  
  93. Minix and linux (both using the minix-1.5 file system) get much better
  94. performance from this controller.  E.g., under my version of Minix
  95. (which is more or less standard except for the disk driver), reading and
  96. writing a 2MB file on recently built 64MB Minix file system with only
  97. 4MB free was about 50% faster than reading and writing a 2MB file on an
  98. empty 166MB 386BSD file system.  The minix-1.5 fs uses a block size of
  99. only 1K and attempts to lay out the blocks contiguously.  It uses my
  100. modifications of reading ahead up to 17K and always writing all dirty
  101. blocks whenever any dirty block has to be written, so that the driver
  102. usually has a large number of contiguous blocks to work with.  The
  103. driver collects disk-contiguous blocks and makes the largest possible
  104. i/o requests to the controller.  Directory blocks are _not_ written
  105. immediately. This goes well with writing all dirty blocks whenever one
  106. dirty block has to be written and makes operations like `ar xo libc.a'
  107. and `rm -rf junk' 10 to 20 times faster than with the 386BSD ufs.  It
  108. increases the chance of a crash messing up the file system, but I prefer
  109. the reduced chance of a crash because of less i/o.
  110. -- 
  111. Bruce Evans  (bde@runx.oz.au)
  112.  
  113.  
  114.