From: Hans Reiser <reiser@namesys.com>
To: Jimmie Mayfield <mayfield+usenet@sackheads.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Interesting disk throughput performance problem
Date: Sun, 22 Jul 2001 13:20:24 +0400 [thread overview]
Message-ID: <3B5A9AD8.FADBA3CF@namesys.com> (raw)
In-Reply-To: <20010721233313.A15232@sackheads.org>
I'm just guessing here, but is write caching active on one but not the other?
Hans
Jimmie Mayfield wrote:
>
> Hi. I'm running into some disk throughput issues that I can't explain.
> Hopefully someone reading this can offer an explanation.
>
> One of my machines is running 2.4.5 and has 2 hard drives: a 7200 rpm
> ATA100 Maxtor and a 5400 rpm ATA33 IBM. Each drive is a master on its own
> controller (AMI CMD649 as found on the IWill KT266-R). Both drives contain
> reiserfs 3.6x filesystems.
>
> By all local benchmarks, the 7200 rpm drive is the faster drive. But this
> doesn't seem to be the case for large files originating from remote clients.
> Witness:
>
> My crude test involves scp'ing a 100MB file from another machine on my home
> network over 100bT ethernet.
>
> 1) scp to the 5400rpm drive: roughly 10MB/sec.
> 2) scp to the 7200rpm drive: roughly 2MB/sec.
>
> I've tried 'tail' and 'notail' mount options with no change (as expected since
> this is a single large file). I suspect that the machine would become CPU-bound
> somewhere in the 20MB/sec range (see below for my reasoning).
>
> I see the same sort of behavior using Samba though not nearly as
> pronounced (the 5400rpm drive is merely 2x as fast as the 7200rpm drive).
>
> Okay. Since the test involved 2 separate drives with different geometries,
> I figured this might be due to physical block location. Perhaps the file
> is getting allocated to the fastest cylinders on the 5400 rpm drive and
> the slowest cylinders on the 7200 rpm drive. Or it could be a fragmentation
> issue.
>
> So I tried the test locally: with the file stored on the 5400rpm drive,
> scp it to localhost and write it to the 7200rpm drive. Results were a little
> below 10MB/sec (CPU near 100% presumably due to encrypting/decrypting on
> the fly).
>
> Any ideas why the 7200rpm drive performs so poorly for remote clients but
> performs wonderfully well when those same operations are performed locally?
>
> Jimmie
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2001-07-22 9:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-22 3:33 Interesting disk throughput performance problem Jimmie Mayfield
2001-07-22 9:20 ` Hans Reiser [this message]
2001-07-22 14:07 ` toon
2001-07-22 14:41 ` Hans Reiser
2001-07-22 10:29 ` Jakob Østergaard
2001-07-22 10:44 ` Mike Black
2001-07-24 15:06 ` Jimmie Mayfield
-- strict thread matches above, loose matches on Subject: below --
2001-07-24 17:11 Tim Schmielau
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=3B5A9AD8.FADBA3CF@namesys.com \
--to=reiser@namesys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mayfield+usenet@sackheads.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 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.