Question regarding concurrent accesses through block device and fs

Question regarding concurrent accesses through block device and fs

[Francis Moreau]

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 ?

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 ?

thanks
-- 
Francis

RE: Question regarding concurrent accesses through block device and fs

[Niu_Yawei]

 

> -----Original Message-----
> From: linux-fsdevel-owner@vger.kernel.org 
> [mailto:linux-fsdevel-owner@vger.kernel.org] On Behalf Of 
> Francis Moreau
> Sent: 2009年2月14日 4:26
> To: linux-fsdevel@vger.kernel.org
> 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@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question regarding concurrent accesses through block device and fs

[Francis Moreau]

Hello,

2009/2/16  <Niu_Yawei@emc.com>:
>> 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.

Do you mean that the call to unmap_underlying_metadata() is not needed
for both cases (blockdev and fs accesses) ?

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

So why trying to keep consistency for file systems accesses ?

thanks
-- 
Francis