Re: [E2FSPROGS, RFC] mke2fs: New bitmap and inode table allocation for FLEX_BG

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 22 Apr 2008 21:21:49 -0400
Theodore Tso <tytso@xxxxxxx> wrote:

> On Tue, Apr 22, 2008 at 05:27:51PM -0500, Jose R. Santos wrote:
> > > Let's stay with 16 then for now.  Spindle speed doesn't actually
> > > matter here; what matters is seek speed, and the density of the disk
> > 
> > Well higher spindle speed affect cylinder seek times which affect
> > overall seek time, which is why I think it should be tested as well.
> 
> Well, I looked at some laptop drives with spindle speeds of 4200rpm,
> 5400rpm, and 7200rpm, and they have an average read/write seek time of
> of 10.5/12.5ms.
> 
> Comparing Western Digital's current enterprise disk drives (the RE-2)
> which are 7200rpm, and their Enterprise "Green Power" drives (the
> RE2-GP) which try to hide the fact that their disks are 5400RPM, but
> which web sites have outed by using doing a frequency analysis of its
> acoustic output --- both have the same read/write seek time of 8.9ms.

Well, these Green Power drives from Western Digital dont have constant
spindle speed and I believe that they run at 7200 rpm under load and
5400 when mostly idle.  Makes sense why the seek times would be the
same.  On the other hand, the VelociRaptor drives with 10k rpm have a
latency of 5.5ms.

Looking at the specs of Seagate Savvio and Cheetah family of drives, a
33% increase in spindle speed from 10k to 15K rpms give out around 25%
improvement in average seek latency.  Also note that benchmark
publishes that are sensitive to IO latencies tend to use smaller 15k
rpm disk than their larger but slower counter parts.  RPM speeds
usually beats density when it comes to seek time improvements.

> 
> Interestingly, some of the older disks have faster seek times (i.e.,
> 4ms), at the same disk platters, and I doubt it's because hard drive
> head positioning motors have gotten slower; rather, it's probably that
> as the platter density has increased, the time to position the hard
> drive heads is what's taking longer.  

Or it could be that hard drive manufactures in the digital media age
care more about capacity at a cheaper price than tuning a drive for
best seek performance.  For those user that demand speed, there are
options available like the VelociRaptor family of drives but those come
at a cost of both capacity and price.

I got to say 4ms is really good.  Was this on IDE?  Most drive I've
seen in this category have been stuck in the 7-8ms barrier.  Dont
recall seeing them lower than this, but I have not been paying much
attention in the last couple of years.

> Something that would be interesting to do is to do some experiments
> measuring small seeks (i.e., within a 1 gigabyte or so), and long
> seeks (i.e., across 10-20% and 50% of the disk drive).  The difference
> between those two times is what's probably driving your flex_bg
> performance numbers, and it might be easier simply to measure that
> directly.

I may have some data related to that since I did run blktrace on
some of my runs.  Need check if I still have the data so that I can run
seekwatcher on them.  I had to erase most of them since the traces where
huge. :(

> 
> 							- Ted



-JRS
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux