* BH_Boundary explanation:
*
* There is a problem. The mpage read code assembles several pages, gets all
* their disk mappings, and then submits them all. That's fine, but obtaining
* the disk mappings may require I/O. Reads of indirect blocks, for example.
*
* So an mpage read of the first 16 blocks of an ext2 file will cause I/O to be
* submitted in the following order:
* 12 0 1 2 3 4 5 6 7 8 9 10 11 13 14 15 16
*
* because the indirect block has to be read to get the mappings of blocks
* 13,14,15,16. Obviously, this impacts performance.
*
* So what we do it to allow the filesystem's get_block() function to set
* BH_Boundary when it maps block 11. BH_Boundary says: mapping of the block
* after this one will require I/O against a block which is probably close to
* this one. So you should push what I/O you have currently accumulated.
*
* This all causes the disk requests to be issued in the correct order.
Hope that helps,
Onkar
On Thu, Apr 8, 2010 at 11:50 AM, Joel Fernandes <agnel.joel@xxxxxxxxx> wrote:
> On Thu, Apr 8, 2010 at 11:34 AM, Joel Fernandes <agnel.joel@xxxxxxxxx>Do you mean the next logical block (in an inode) is not physically
> wrote:
>>
>> Could anyone explain the significance of the BH_Boundary flag in a
>> buffer head. and when you should this flag be set or cleared?
>> What other effects does setting or clearing this flag have?
>>
> Set if the block to be submitted after this one will not be adjacent to this
> one.
>
adjancent to the current block being submitted?
Wouldn't it be hard to determine this as then you would have to map
the next logical block to determine its physical number and check if
it is adjacent to the current block.
Could you tell me what would happen if we never set this flag?
I appreciate your response, thanks a lot.
It might be a better idea to bottom post, people get pissed otherwise.
You could see a sample here:
http://en.wikipedia.org/wiki/Posting_style#Bottom-posting
Thanks,
-Joel
