From: Theodore Tso <tytso@mit.edu>
To: "Jose R. Santos" <jrs@us.ibm.com>
Cc: linux-ext4@vger.kernel.org, Valerie Clement <valerie.clement@bull.net>
Subject: Re: [E2FSPROGS, RFC] mke2fs: New bitmap and inode table allocation for FLEX_BG
Date: Tue, 22 Apr 2008 21:21:49 -0400 [thread overview]
Message-ID: <20080423012149.GF20668@mit.edu> (raw)
In-Reply-To: <20080422172751.22d5aef9@gara>
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.
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.
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.
- Ted
next prev parent reply other threads:[~2008-04-23 1:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-22 12:46 [RFC] Modified flex_bg patches Theodore Ts'o
2008-04-22 12:46 ` [E2FSPROGS, RFC] Basic flexible block group support Theodore Ts'o
2008-04-22 12:46 ` [E2FSPROGS, RFC] mke2fs: New bitmap and inode table allocation for FLEX_BG Theodore Ts'o
2008-04-22 14:18 ` Jose R. Santos
2008-04-22 14:51 ` Theodore Tso
2008-04-22 15:32 ` Jose R. Santos
2008-04-22 18:57 ` Theodore Tso
2008-04-22 22:27 ` Jose R. Santos
2008-04-23 1:21 ` Theodore Tso [this message]
2008-04-23 5:48 ` Jose R. Santos
2008-04-23 12:23 ` Theodore Tso
2008-04-23 16:24 ` Jose R. Santos
2008-04-23 20:57 ` Andreas Dilger
2008-04-23 21:20 ` Jose R. Santos
2008-04-23 20:39 ` Andreas Dilger
2008-04-23 21:05 ` Jose R. Santos
2008-04-25 20:10 ` Andreas Dilger
2008-04-28 12:01 ` Theodore Tso
2008-04-23 21:01 ` Andreas Dilger
2008-04-22 13:47 ` [E2FSPROGS, RFC] Basic flexible block group support Jose R. Santos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080423012149.GF20668@mit.edu \
--to=tytso@mit.edu \
--cc=jrs@us.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=valerie.clement@bull.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.