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 File System Performance 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-12 21:27 ` Steve Lord
2001-11-12 21:43 ` Andrew Morton
2001-11-12 21:45 ` Steve Lord
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:26 ` Steve Lord
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 21:53 ` Lionel Bouton [this message]
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 16:40 ` Ben Israel
2001-11-12 17:29 ` Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
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 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.