Hard disks, one year ago today (Tangent: filesystem performance microbenchmark)

Hard disks, one year ago today (Tangent: filesystem performance microbenchmark)

Post by t.. » Wed, 31 May 2000 04:00:00

Quote:>>>  There's a little pressure for higher disk performance.  Windows
>>>generates a great deal of spurious disk activity, which makes a
>>>faster hard disk very important for higher system performance.  
>>>Also, many other OS's (eg, Solaris' and FreeBSD's) filesystems are
>>>only half-asynchronous.  Faster hard drives have a noticeable impact
>>>on these systems' performance.  The pressure is mostly limited by
>>>the availability of high-performance SCSI drives; what pressure that
>>>is felt to improve EIDE performance is generated by buyers who
>>>actually care about disk performance (and most home users don't know
>>>that hard disks even *have* a performance) but not so much that they
>>>are willing to spend the extra $$$ on a Cheetah or other SCSI

>>In my limited experience much of the pressure for disk performance
>>is currently being met by adding RAM, either in the disk or as main
>>memory (at least on the desktop). It's another example (effectively)
>>of Amdahl's law: speeding up disk accesses, even by 50% or so, does
>>not buy you nearly as much as eliminating them does.

>  Adding RAM to main memory will help decrease disk accesses in a
>fully asynchronous filesystem (like Linux's), but many OS's do not
>use a fully asynchronous filesystem.  Windows generates a lot of
>disk activity even if there is enough RAM to cache the data you are
>using, and Solaris and FreeBSD (et al) will cache most data, but
>does not cache some metadata and does not write-back other metadata
>(eg, file access times), making "find" and some other very filesystem
>intensive jobs bottlenecked on the speed of the physical disk
>subsystem, regardless of how much RAM you have for caching things.

>  There are options for mounting filesystems under FreeBSD which
>makes them more fully asynchronous, but most people do not use them,
>and they fall short of making filsystem access fully asynchronous.  
>One trick that has been suggested is NFS-mounting local filesystems,
>but I haven't seen that tried yet.

  On a tangentally related note, Paeyl has a filesystem microbenchmark
that might be of interest to some of you.  A few of the bitminers have
run it on a variety of systems from desktops with EIDE subsystems to
small servers with RAID disk subsystems, and a few different operating
systems (linux, netbsd, freebsd, solaris, et al).  We've been talking
about increasing the scope of the microbenchmark to include things like
measuring stat() and modification performance.


  -- TTK