Re: Block I/O Mystery

[Nikita Danilov]

Block Device writes:
 > Hi,
 >     I am trying to write to inode blocks without using the VFS layer
 > (filp_open, f_op->write)
 >     etc.
 >     I could use __bread to read the inode blocks correctly. But when I'm
 >     trying to write a block after changing it I face a strange problem.
 >     My changes do not show up when I cat the file but if I use dd command on
 >    the block device it shows my writes.
 > 
 >    Steps I performed :
 > 

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.

 >    a) Created a file of 8K ( 2blocks ) and filled it with 'a'.

Now 2 pages are cached in memory in address_space associated with inode.

 >    b) Read the blocks using __bread and print(k)ed the contents.
 >        This worked correctly.

This reads blocks directly from the disk (igrnoing cached copy), and
caches them in block device address_space.

 >    c) Called __getblk for a file block, locked the buffer, made
 > changes to it (memcpy),
 >        marked buffer dirty, unlocked it and called sync_dirty_buffer.

This makes changes to the block cached in block device address_space.

 >    d) If I try to see contents of the file ( cat or vi ) they are
 > shown unchanged, but if I

vi uses read(1), and, hence, will fetch data from inode address_space,
where original pages still live.

 >        use dd on the raw device or use step b) to read a block the
 > changes made @ c)
 >       are seen.

And this will read from block device cache.

 > 
 >  Also, if I unmount the filesystem and mount it again the changes are
 > visible through cat, vi etc.
 > 
 > Can someone explain what exactly is going wrong ?

You are bypassing normal file sysetm caching and results can be
unpredictable.

 > 
 > I'm using the 2.6.13 kernel.
 > 
 > Thanks & Regards
 > -BD

Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/