home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / sysv386 / 12521 < prev    next >
Encoding:
Text File  |  1992-07-27  |  2.0 KB  |  46 lines
  1. Newsgroups: comp.unix.sysv386
  2. Path: sparky!uunet!usc!sol.ctr.columbia.edu!destroyer!ncar!ico!dougp
  3. From: dougp@ico.isc.com (Doug Pintar)
  4. Subject: Re: ISC 3.0: Why Very Fast File System is slower?
  5. Message-ID: <1992Jul28.060848.21420@ico.isc.com>
  6. Sender: uucp@ncar.ucar.edu (UNIX-to-UNIX Copy)
  7. Organization: Interactive Systems Corp., Boulder CO
  8. References: <76678@ut-emx.uucp>
  9. Date: Tue, 28 Jul 1992 06:08:48 GMT
  10. Lines: 34
  11.  
  12. In article <76678@ut-emx.uucp> muhammad@chaos.utexas.edu (Muhammad Pervez) writes:
  13. >
  14. >    From the tests I have done with the VFFS (Very Fast File System),
  15. >I am getting a performance of about half as compared to the default
  16. >file system (S51K).  Am I missing something?  I will like to hear
  17. >comments about this new file system.
  18. >
  19.  
  20. >    Then used the copy command:
  21. >
  22. >    # time cp foo bar
  23. >  
  24. Here's the problem.  The VFFS provides no buffering, nor does it do the
  25. adaptive read-ahead that the standard (ISC anyway) filesystem does.  The
  26. 'cp' command uses a small (4K) buffer for reading and writing the file
  27. when copying it.  The standard filesystem will attempt to read something
  28. like 34KB at a time, so most of the reads will wind up getting things
  29. from the buffer cache.  In addition, you won't see the times taken by the
  30. cache manager doing write-behind.  The VFFS was designed for programs that
  31. use *large* buffers internally, usually to do unidirectional file I/O.
  32. Try doing something like
  33.     dd if=foo of=/dev/null bs=1024k
  34. to see how fast it'll read.  It wasn't designed to be terrific on copy
  35. operations, but you could easily write a small program to write 30MB in
  36. 1MB chunks and see how fast it works.
  37.  
  38. This is a problem of using the wrong benchmarking method.  Remember, the
  39. VFFS was *not* designed to be a general-purpose filesystem (although, as
  40. you've demonstrated, it will *work* as such -- just not terribly well).
  41. Think of big files such as images (maybe 18MB each) where you need to
  42. read in large portions of them to perform some kind of computation and
  43. then need to write it out again somewhere later.
  44. Cheers,
  45. DLP
  46.