From: Nikita Danilov <nikita@clusterfs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17222.25180.191039.128718@gargle.gargle.HOWL>
Date: Fri, 7 Oct 2005 15:56:12 +0400
To: Block Device <blockdevice@gmail.com>
Cc: Linux Kernel Mailing List <Linux-Kernel@vger.kernel.org>
Subject: Re: Block I/O Mystery
In-Reply-To: <64c763540510070436s681a3e00q511fb68c1c876aa9@mail.gmail.com>
References: <64c763540510062301v2ac65a47p953038b8b674cf1d@mail.gmail.com>
	<17222.18470.744354.727641@gargle.gargle.HOWL>
	<64c763540510070436s681a3e00q511fb68c1c876aa9@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1382
Lines: 39

Block Device writes:
 > Hi,
 > 
 >    After some more toying around, I have seen that it works correctly
 > on ext2 fs but not
 > on etx3. :) ...
 > 
 >   My questions inline ..
 > 
 > On 10/7/05, Nikita Danilov <nikita@clusterfs.com> wrote:
 > 
 > > Blocks read by bread() and friends are cached in block device (not you
 > > :-) struct address_space. File data are cached in the per-inode struct
 > > address_space.
 > 
 > But even if I'm reading blocks from a device directly, they are
 > finally blocks from  the same inode. Why then are they stored
 > separately ?

bread() has no idea about "inode". It just reads block number N from
device D. And this is how it is stored in the cache (and can later be
found there): "device D, block N".

read(), on the other hand, reads logical block i from file F, and this
is how that block (page actually) is cached: "file F, page with logical
number i within file".

These two caching mechanisms are disjoint and almost no form of
coherency is maintained between them.

All this, of course, is up to file system to implement, and different
file systems do this slightly differently.

Nikita.
-
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/