* get_blocks_t semantics @ 2005-07-20 14:03 Nir Tzachar 2005-07-21 3:14 ` Badari Pulavarty 0 siblings, 1 reply; 4+ messages in thread From: Nir Tzachar @ 2005-07-20 14:03 UTC (permalink / raw) To: linux-fsdevel [-- Attachment #1: Type: text/plain, Size: 573 bytes --] 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. -- ========================================================= Nir Tzachar. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: get_blocks_t semantics 2005-07-20 14:03 get_blocks_t semantics Nir Tzachar @ 2005-07-21 3:14 ` Badari Pulavarty 2005-07-21 6:46 ` Nir Tzachar 0 siblings, 1 reply; 4+ messages in thread From: Badari Pulavarty @ 2005-07-21 3:14 UTC (permalink / raw) To: tzachar; +Cc: linux-fsdevel 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 ? Thanks, Badari ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: get_blocks_t semantics 2005-07-21 3:14 ` Badari Pulavarty @ 2005-07-21 6:46 ` Nir Tzachar 2005-07-21 22:40 ` Badari Pulavarty 0 siblings, 1 reply; 4+ messages in thread From: Nir Tzachar @ 2005-07-21 6:46 UTC (permalink / raw) To: Badari Pulavarty; +Cc: linux-fsdevel [-- Attachment #1: Type: text/plain, Size: 1480 bytes --] 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?? furthermore, what set_buffer_mapped (used in map_bh) does?? i could not find it's definition anywhere?? about create, "allocate a block" means just deciding which block should be allocated, update the fs control structures, and return that block #, right?? > Thanks, > Badari -- ========================================================= Nir Tzachar. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: get_blocks_t semantics 2005-07-21 6:46 ` Nir Tzachar @ 2005-07-21 22:40 ` Badari Pulavarty 0 siblings, 0 replies; 4+ messages in thread From: Badari Pulavarty @ 2005-07-21 22:40 UTC (permalink / raw) To: tzachar; +Cc: linux-fsdevel 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-07-21 22:40 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-07-20 14:03 get_blocks_t semantics Nir Tzachar 2005-07-21 3:14 ` Badari Pulavarty 2005-07-21 6:46 ` Nir Tzachar 2005-07-21 22:40 ` Badari Pulavarty
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).