Re: get_blocks_t semantics

[Badari Pulavarty <pbadari@us.ibm.com>]

Nir Tzachar wrote:

> On Wed, 2005-07-20 at 20:14 -0700, Badari Pulavarty wrote:
> 
>>Nir Tzachar wrote:
>>
>>
>>>hello list.
>>>
>>>can someone please explain the exact semantics the get_block_t function 
>>>(which is passed to mpage_readpage(s)) should implement??
>>>i could not find any documentation, and existing code kind of baffled
>>>me...
>>>
>>>my current understanding goes like this:
>>>if the block is present, call map_bh on the bh, with the physical block
>>>number.
>>>else, if "create" is set, allocate a new block for the inode, and again
>>>update the new physical block number.
>>>
>>>is this all?? 
>>>
>>>thanks.
>>>
>>
>>For a given file offset, get_block() function is supposed to return the
>>physical disk block# of the block. (and size of the block). If "create"
>>is one, it needs to allocate the block (if it doesn't already exist). 
>>Makes sense ?
> 
> 
> from fs.h:
> typedef int (get_block_t)(struct inode *inode, sector_t iblock,
>                      struct buffer_head *bh_result, int create);
> 
> so, iblock is the block number in the file, or the offset in the file??

iblock = fileoffset in represented sectors. (for example,
file offset 4K = 8)

> furthermore, what  set_buffer_mapped (used in map_bh) does?? i could not
> find it's definition anywhere??

When the filesystems map the fileoffset to a disk block, it returns the
block# in the "bh->b_blocknr" and sets the flag to indicate that the
buffer is mapped (to a disk block).

If get_block() returned sucess, but if the buffer mapped is not set, 
means thats there is a hole.

> 
> about create, "allocate a block" means just deciding which block should
> be allocated, update the fs control structures, and return that block #,
> right??
> 

yep.

Thanks,
Badari