* 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).