From: Lionel Bouton <Lionel.Bouton@free.fr>
To: Steve Lord <lord@sgi.com>
Cc: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: File System Performance
Date: Mon, 12 Nov 2001 22:53:23 +0100 [thread overview]
Message-ID: <3BF044D3.8060503@free.fr> (raw)
In-Reply-To: <3BF02702.34C21E75@zip.com.au>, <00b201c16b81$9d7aaba0$5101a8c0@pbc.adelphia.net> <3BEFF9D1.3CC01AB3@zip.com.au> <00da01c16ba2$96aeda00$5101a8c0@pbc.adelphia.net> <3BF02702.34C21E75@zip.com.au> <1005595583.13307.5.camel@jen.americas.sgi.com> <3BF03402.87D44589@zip.com.au> <1005600431.13303.10.camel@jen.americas.sgi.com>
>
>
>
>I tried an experiment which puzzled me somwhat:
>
>> mount /xfs
>> cd /xfs/lord/xfs-linux
>> time tar cf /dev/null linux
>>
>
>real 0m7.743s
>user 0m0.510s
>sys 0m1.380s
>
>>hdparm -t /dev/sda5
>>
>
>/dev/sda5:
> Timing buffered disk reads: 64 MB in 3.76 seconds = 17.02 MB/sec
>
>>du -sk linux
>>
>173028 linux
>
>The tar got ~21 Mbytes/sec.
>
Things I'll check :
0/ rerun this test !!!
1/ is there cache on the scsi controler ?
2/ xfs data cached at mount ? (I don't believe so)
3/ "hdparm -t" is on crack.
4/ du reports a disk usage way ahead of files' sizes total (don't know
xfs enough to estimate this propability) and tar won't read the whole
"du -sk" data.
2/ "time mount /xfs" could help (if mount + tar times are below
expected, this case can be eliminated).
3/ ask hdparm's maintener.
4/ tar, check tar size.
next prev parent reply other threads:[~2001-11-12 21:53 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-12 13:54 Ben Israel
2001-11-12 16:33 ` Andrew Morton
2001-11-12 17:50 ` Ben Israel
2001-11-12 19:46 ` Andrew Morton
2001-11-12 19:59 ` Richard Gooch
2001-11-12 23:07 ` Mike Fedyk
2001-11-13 0:04 ` Richard Gooch
2001-11-13 0:08 ` Mike Fedyk
2001-11-13 0:26 ` Richard Gooch
2001-11-13 0:47 ` Mike Castle
2001-11-13 1:28 ` Mike Fedyk
2001-11-13 6:34 ` Richard Gooch
2001-11-13 20:56 ` Andreas Dilger
2001-11-13 7:45 ` Andreas Dilger
2001-11-12 20:06 ` Steve Lord
2001-11-12 20:41 ` Andrew Morton
2001-11-13 0:17 ` Andreas Dilger
2001-11-13 0:40 ` Peter J . Braam
2001-11-13 20:46 ` Andreas Dilger
2001-11-16 22:07 ` Peter J . Braam
2001-11-16 23:14 ` Mike Fedyk
2001-11-12 21:27 ` Steve Lord
2001-11-12 21:43 ` Andrew Morton
2001-11-12 21:48 ` Linus Torvalds
2001-11-12 22:11 ` Lionel Bouton
2001-11-12 19:41 ` Gérard Roudier
2001-11-12 22:14 ` Linus Torvalds
2001-11-12 22:30 ` Ragnar Kjørstad
2001-11-12 22:36 ` Andrew Morton
2001-11-12 23:04 ` Mike Castle
2001-11-13 9:56 ` Peter Wächtler
2001-11-13 9:41 ` Henning P. Schmiedehausen
2001-11-12 22:16 ` Andrew Morton
2001-11-12 22:32 ` Lionel Bouton
2001-11-12 22:45 ` Alan Cox
2001-11-12 22:39 ` Alan Cox
2001-11-12 22:39 ` Xavier Bestel
2001-11-12 22:46 ` Mike Castle
2001-11-12 22:26 ` Steve Lord
2001-11-12 21:45 ` Steve Lord
2001-11-12 21:53 ` Lionel Bouton [this message]
2001-11-12 16:40 ` Ben Israel
2001-11-12 17:29 ` Andrew Morton
2001-11-12 22:36 Grant Erickson
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=3BF044D3.8060503@free.fr \
--to=lionel.bouton@free.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=lord@sgi.com \
/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®