mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 --]

  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 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 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®