From: "Eric D. Mudama" <edmudama@mail.bounceswoosh.org>
To: Willy Tarreau <willy@w.ods.org>
Cc: Tom Vier <tmv@comcast.net>, linux-kernel@vger.kernel.org
Subject: Re: File system compression, not at the block layer
Date: Sat, 24 Apr 2004 10:02:25 -0600 [thread overview]
Message-ID: <20040424160224.GA26244@bounceswoosh.org> (raw)
In-Reply-To: <20040424073622.GN596@alpha.home.local>
On Sat, Apr 24 at 9:36, Willy Tarreau wrote:
>On Fri, Apr 23, 2004 at 10:24:58PM -0400, Tom Vier wrote:
>> On Fri, Apr 23, 2004 at 05:18:44PM -0400, Timothy Miller wrote:
>> > In a drive with multiple platters and therefore multiple heads, you
>> > could read/write from all heads simultaneously. Or is that how they
>> > already do it?
>>
>> fwih, there was once a drive that did this. the problem is track alignment.
>> these days, you'd need seperate motors for each head.
>
>I think they now all do it. Haven't you noticed that drives with many
>platters are always faster than their cousins with fewer platters ? And
>I don't speak about access time, but about sequential reads.
Only one read/write element can be active at one time in a modern disk
drive. The issue is that while the drive's headstack was originally
in alignment, all sorts of factors can cause it to fall out of
alignment. If that occurs, the heads might not line up with each
other, meaning that when you used to line up with A1 and B1 (side A,
cylinder 1) your two heads now align with A1 and B40.
Every surface has embedded servo information, which allows the drive
to work around mechanical variability and handling damage. The
difference in position between adjacent heads in a drive factors into
a parameter called "head switch skew". Head switch skew is "how long
does it take us to seek to the next sequential LBA after reading the
last LBA on a track/head?" Track-to-track skew is how long to seek
and settle on the adjacent track on the same head.
These two parameters are used to generate the drive's format, which in
turn account for the sequential throughput. (higher skews means lower
usage duty cycle means lower overall throughput.) If the skews are
set too low, the drive blows revs because it can't settle in time for
the LBA it needs to read.
In general, a drive with lots of heads will perform better on most
workloads because it doesn't have to seek as far radially to cover the
same amount of data. However, a single-headed and a multi-headed
drive of the same generation should be virtually identical in
sequential throughput... within a few percent. If anything, the
single-headed drive should be a bit faster because track-to-track
skews are typically smaller than headswitch skews.
--eric
--
Eric D. Mudama
edmudama@mail.bounceswoosh.org
next prev parent reply other threads:[~2004-04-24 16:01 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-23 17:26 Timothy Miller
2004-04-23 17:30 ` Miquel van Smoorenburg
2004-04-23 17:41 ` Theodore Ts'o
2004-04-23 17:57 ` Jörn Engel
2004-04-23 18:14 ` Timothy Miller
2004-04-23 18:34 ` Paul Jackson
2004-04-23 20:14 ` Joel Jaeggli
2004-04-23 20:34 ` Richard B. Johnson
2004-04-23 20:44 ` Måns Rullgård
2004-04-23 20:59 ` Richard B. Johnson
2004-04-23 21:14 ` Ben Greear
2004-04-23 21:25 ` Timothy Miller
2004-04-24 4:58 ` Ben Greear
2004-04-27 15:45 ` Timothy Miller
2004-04-23 21:18 ` Timothy Miller
2004-04-24 1:28 ` Horst von Brand
2004-04-24 2:24 ` Tom Vier
2004-04-24 7:36 ` Willy Tarreau
2004-04-24 16:02 ` Eric D. Mudama [this message]
2004-04-25 3:05 ` Horst von Brand
2004-04-25 7:29 ` Willy Tarreau
2004-04-25 19:50 ` Eric D. Mudama
2004-04-27 15:43 ` Timothy Miller
2004-04-28 0:29 ` Tom Vier
2004-04-23 21:31 ` Joel Jaeggli
2004-04-23 22:20 ` Ian Stirling
2004-04-23 23:34 ` Paul Jackson
2004-04-27 15:42 ` Timothy Miller
2004-04-27 16:02 ` Jörn Engel
2004-04-24 1:18 ` Horst von Brand
2004-04-26 10:22 ` Jörn Engel
2004-04-23 21:15 ` Timothy Miller
2004-04-23 21:36 ` Joel Jaeggli
2004-04-27 20:34 ` Pavel Machek
2004-04-28 22:57 ` Timothy Miller
2004-04-29 9:46 ` Jörn Engel
2004-04-29 9:52 ` Pavel Machek
2004-04-29 10:09 ` Jörn Engel
2004-04-29 10:19 ` Pavel Machek
2004-04-29 17:17 ` Tim Connors
2004-04-28 1:00 ` David Lang
2004-04-28 10:09 ` Jörn Engel
2004-04-28 10:21 ` Nikita Danilov
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=20040424160224.GA26244@bounceswoosh.org \
--to=edmudama@mail.bounceswoosh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tmv@comcast.net \
--cc=willy@w.ods.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®