![]() | |||||||||||||
Messages in this thread |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-10-07 10:49 [from the cache] ©2003-2008 | |||||||||||||