From: Andreas Dilger <adilger@clusterfs.com>
To: Markus Schaber <schabios@logi-track.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Block Device Caching
Date: Tue, 29 Jun 2004 16:46:22 -0600 [thread overview]
Message-ID: <20040629224622.GQ15166@schnapps.adilger.int> (raw)
In-Reply-To: <20040630002014.4970b82d@kingfisher.intern.logi-track.com>
[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]
On Jun 30, 2004 00:20 +0200, Markus Schaber wrote:
> During our application testing, we noticed that our application (that
> operates directly on a LVM volume) we noticed that it seems the read
> data does not go into any cache.
>
> Now we did some tests using dd blocksize=1M count=1000:
>
> Using dd directly on the /dev/daten/testing lvm volume, we read about 95
> MBytes/Seconds. Issuing multiple dds in sequence gives little variance in IO
> speed (between 90 and 100 MB/sec).
>
> When we create a file system on this volume, and mount it, and we create
> a 1G file there, the dd gives us the same 95 MB/sec on the first read
> after the mount, and approx. 480 MB/Sec on subsequent reads.
>
> This lead us to the conclusion that block devices do not cache, but the
> filesystem does. But subsequently, I ran some tests on my developer
> machine (Pentium 4 Mobile Laptop).
>
> When dd'ing 100MB from /dev/hda5, the first read gives about
> 22MBytes/Sek (which seems okay for a 2.5" IDE Disk), but subsequend
> reads give about 389MBytes/sek (which is impossible to achieve using
> such hardware). Interestingly, this happens on a mounted partition,
> while when unmounting the partition, caching does not work. But for the
> /dev/daten/testing above, mounting a filesystem on the partition does
> not help in caching.
When you close the block device it flushes the cache for that device (inode).
If you kept the device open in some way (e.g. "sleep 10000000 < /dev/hda5")
then it should start caching the data between dd runs.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-06-29 22:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-29 22:20 Block Device Caching Markus Schaber
2004-06-29 22:46 ` Andreas Dilger [this message]
2004-06-29 23:41 ` Timothy Miller
2004-06-30 6:30 ` Markus Schaber
2004-07-02 9:21 ` CCISS driver and Caching (was: Block Device Caching) Markus Schaber
2004-06-29 23:40 ` Block Device Caching Timothy Miller
2004-06-30 8:29 ` Helge Hafting
[not found] ` <20040630123828.7d48c6e6@kingfisher.intern.logi-track.com>
[not found] ` <40E543D7.9030303@hist.no>
2004-07-02 12:01 ` Markus Schaber
2004-07-02 12:56 ` FabF
2004-07-05 15:07 ` Markus Schaber
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=20040629224622.GQ15166@schnapps.adilger.int \
--to=adilger@clusterfs.com \
--cc=linux-kernel@vger.kernel.org \
--cc=schabios@logi-track.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.