From: Volker Armin Hemmann <volkerarmin@googlemail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Normal disk speed?
Date: Sat, 2 Oct 2010 14:11:49 +0200 [thread overview]
Message-ID: <201010021411.49279.volkerarmin@googlemail.com> (raw)
In-Reply-To: <4CA71D8F.4010508@f_philipp.fastmail.net>
On Saturday 02 October 2010, Florian Philipp wrote:
> Am 01.10.2010 18:23, schrieb Volker Armin Hemmann:
> > On Friday 01 October 2010, Florian Philipp wrote:
> >> Am 01.10.2010 03:12, schrieb Adam Carter:
> >>> Your harddisk seeks, everything is slow.
> >>>
> >>> So does that then mean that my options are;
> >>> 1. Defragment, so there is less seeking
> >>> 2. Get an SSD
> >>>
> >>> Since 2 is too expensive for a decent size drive, is there anything i
> >>> can do about 1 without a backup and restore operation? Or will the
> >>> fragmentation be very small on reiser3 anyway (i mount with notail) so
> >>> I should just accept things as they are.
> >>
> >> To prevent fragmentation, try to always keep a decent amount of free
> >> space on each partition. That way, the FS driver can allocate space for
> >> new files without too much fragmentation (a fragment every 2 MB or so
> >> doesn't really hurt performance).
> >
> > you obviously never used a tape drive...
>
> Hehe, yep. :)
>
> While we're at the topic, we can do some basic math to show how bad
> fragmentation is.
>
> Symbols:
>
> s [MB]: total size
> t_f [s]: total read/write time with fragmentation
> t_nf [s]: total read/write time without fragmentation
> t_s [s]: seek time
> v [MB/s]: sequential throughput
> n [-]: number of fragments
> f [1/MB]: fragmentation (fragments per MB)
> e [-]: effectiveness (percentage)
>
> 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.
Besides, seek times are not constant ;)
next prev parent reply other threads:[~2010-10-02 12:12 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 [this message]
2010-10-02 12:44 ` Florian Philipp
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=201010021411.49279.volkerarmin@googlemail.com \
--to=volkerarmin@googlemail.com \
--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