linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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).