> -----Original Message----- > From: linux-fsdevel-owner@xxxxxxxxxxxxxxx > [mailto:linux-fsdevel-owner@xxxxxxxxxxxxxxx] On Behalf Of > Francis Moreau > Sent: 2009年2月14日 4:26 > To: linux-fsdevel@xxxxxxxxxxxxxxx > Subject: Question regarding concurrent accesses through block > device and fs > > Hello, > > I have a question regarding the page cache/buffer heads behaviour when > some blocks are accessed through a regular file and through the block > dev hosting this file. > > First it looks like when accessing some blocks through a block device, > the same mechanisms are used as when reading a file through a file > system: the page cache is used. > > That means that a block could be mapped by several buffers at the same > time. > > I don't see any issues to this but looking at __block_prepare_write(), > it seems that we don't want this to happen since it does: > > [...] > if (buffer_new(bh)) { > unmap_underlying_metadata(bh->b_bdev, > bh->b_blocknr); > > > [...] > } > > where unmap_underlying_metadata() unmaps the blockdev buffer > which maps b_blocknr block. Also this call seems unneeded if > __block_prepare_write() is called when writing through the block > dev since we already know that the buffer doesn't exist (we are > here to create it). > > Could anybody why this is needed at all ? I think it's not necessary for block device too. > > Also I'm wondering if the block is written first through the file > system (but the data are still in the page cache, not commited to the > disk) and another process try to read the same block through the > block device. Does it get stale data ? > Yes, I think so. Kernel can't guarantee such kind of consistency. > thanks > -- > Francis > -- > To unsubscribe from this list: send the line "unsubscribe > linux-fsdevel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
