fs/mpage.c * 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 <[email protected]>wrote: > > On Thu, Apr 8, 2010 at 11:34 AM, Joel Fernandes <[email protected]> > > 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. > > > > Do you mean the next logical block (in an inode) is not physically > 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 >
