From: Florian Philipp <lists@f_philipp.fastmail.net>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Normal disk speed?
Date: Sat, 02 Oct 2010 14:44:19 +0200 [thread overview]
Message-ID: <4CA72923.8000500@f_philipp.fastmail.net> (raw)
In-Reply-To: <201010021411.49279.volkerarmin@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]
Am 02.10.2010 14:11, schrieb Volker Armin Hemmann:
> On Saturday 02 October 2010, Florian Philipp wrote:
[...]
>>
>> Assumptions:
>>
>> 1. Seek time is constant. For HDDs we can take an average value. Of
>> course this doesn't work for tapes. They have a seek time which
>> increases linearly with the distance between the fragments.
>
> I think you misunderstood my remark.
>
> Tapes try to stream. Take an old DLT drive with 5-10mb/sec streaming speed.
> Slow, isn't it?
>
> But when you do a backup on such an old tape even with a modern harddisk you
> have problems keeping it streaming. As soon as you hit a directory with many
> small files - like ~/Mail or /usr/portage you are screwed.
>
> Yes, you have wonderfull 100mb/sec when you read a big, fat file. Or a single
> small file. But when you have houndreds, thousands or hundreds of thousands of
> small files, harddisks suck.
> And your tape drive has to stop and rewind every couple of seconds because
> your harddisks were not able to keep up the required 10mb/sec. Trueley
> pathetic.
Well, that's exactly what my little math shows. When you read 4kB files,
you can end up with 0.0065 * 50 MB/s = 0.32 MB/s effective throughput
(worst case).
>
> Besides, seek times are not constant ;)
>
Sure they aren't. That's why it is stated as an assumption. It is just a
model. Like every model it has its limits.[1] It doesn't take into
account prefetching, caching and NCQ/TCQ, for example.
Still it is a valid assumption: *On average*, the read/write head has to
move around half the radius of the platter to reach its next position
and it has to wait for half a rotation until the right block is under
the head. If we assume that fragments are uniformly distributed over the
whole disk, we can simply take an average value for seek times.
The model also doesn't take into account that even with no
fragmentation, there might be some seek operations: Blocks on an HDD are
organized in rings (tracks), not as a spiral like the sound track on an
good old LP. That means that at some point, the r/w head has to switch
to the next track when the file does not reside on one track alone.
[1] A bit off-topic: I work in applied sciences and engineering. There
I've learned two basic rules about models: 1. Truth doesn't matter,
usefulness does. 2. Every model has its limits. Knowing these limits is
the single most important important thing when using a model.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2010-10-02 12:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-30 10:58 [gentoo-user] Normal disk speed? Adam Carter
2010-09-30 13:10 ` Florian Philipp
2010-09-30 16:00 ` Peter Humphrey
2010-09-30 16:12 ` [gentoo-user] " Nikos Chantziaras
2010-09-30 16:50 ` [gentoo-user] " Florian Philipp
2010-09-30 21:43 ` Peter Humphrey
2010-09-30 13:26 ` [gentoo-user] " James
2010-09-30 16:53 ` [gentoo-user] " Volker Armin Hemmann
2010-10-01 1:12 ` Adam Carter
2010-10-01 4:41 ` Volker Armin Hemmann
2010-10-01 8:42 ` Florian Philipp
2010-10-01 16:23 ` Volker Armin Hemmann
2010-10-02 2:11 ` Adam Carter
2010-10-02 11:54 ` Florian Philipp
2010-10-02 12:11 ` Volker Armin Hemmann
2010-10-02 12:44 ` Florian Philipp [this message]
2010-10-02 15:06 ` Florian Philipp
2010-10-01 9:05 ` Daniel Troeder
2010-10-01 14:40 ` [gentoo-user] " James
2010-10-02 17:29 ` Daniel Troeder
2010-10-03 0:13 ` James
2010-10-06 8:04 ` Adam Carter
2010-10-06 18:52 ` Daniel Troeder
2010-10-06 22:59 ` Adam Carter
2010-10-07 9:33 ` Daniel Troeder
2010-10-18 10:03 ` Adam Carter
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=4CA72923.8000500@f_philipp.fastmail.net \
--to=lists@f_philipp.fastmail.net \
--cc=gentoo-user@lists.gentoo.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