ext2_block_alloc_info

ext2_block_alloc_info

[Rohit Sharma]

A little confusion.

Just refer this structure in linux/ext2_fs_sb.h

struct ext2_block_alloc_info {
  46        /* information about reservation window */
  47        struct ext2_reserve_window_node rsv_window_node;
  48        /*
  49         * was i_next_alloc_block in ext2_inode_info
  50         * is the logical (file-relative) number of the
  51         * most-recently-allocated block in this file.
  52         * We use this for detecting linearly ascending allocation requests.
  53         */
  54        __u32                   last_alloc_logical_block;
  55        /*
  56         * Was i_next_alloc_goal in ext2_inode_info
  57         * is the *physical* companion to i_next_alloc_block.
  58         * it the the physical block number of the block which was
most-recentl
  59         * allocated to this file.  This give us the goal (target)
for the next
  60         * allocation when we detect linearly ascending requests.
  61         */
  62        ext2_fsblk_t            last_alloc_physical_block;
  63};


this information is maintained by ext2 for every inode.

here  last_alloc_logical_block is for every inode or its for filesystem.

I mean if we are allocating blocks for inode
it can be block no.  0 to n logically
and physically like 23 24 25 34 36 40 41 42

i mean to say

is it like

inode1 has logical blocks 1 2 3 , physical 22 23 24
inode2 has logical blocks 4 5 6 , physical 34 35 50

OR

inode1 has logical blocks 0 1 2 , physical 22 23 24
inode2 has logical blocks 0 1 2 , physical 34 35 50

??

Re: ext2_block_alloc_info

[Sandeep K Sinha]

Hi Rohit,

On Sat, Dec 20, 2008 at 9:13 PM, Rohit Sharma <imreckless@gmail.com> wrote:
> A little confusion.
>
> Just refer this structure in linux/ext2_fs_sb.h
>
> struct ext2_block_alloc_info {
>  46        /* information about reservation window */
>  47        struct ext2_reserve_window_node rsv_window_node;
>  48        /*
>  49         * was i_next_alloc_block in ext2_inode_info
>  50         * is the logical (file-relative) number of the
>  51         * most-recently-allocated block in this file.
>  52         * We use this for detecting linearly ascending allocation requests.
>  53         */
>  54        __u32                   last_alloc_logical_block;
>  55        /*
>  56         * Was i_next_alloc_goal in ext2_inode_info
>  57         * is the *physical* companion to i_next_alloc_block.
>  58         * it the the physical block number of the block which was
> most-recentl
>  59         * allocated to this file.  This give us the goal (target)
> for the next

Look at the comment, this clearly suggests that its a file specific information.
So, its specific to inode.

>  60         * allocation when we detect linearly ascending requests.
>  61         */

It can be only to a file, as for the file system it is already ascending.

>  62        ext2_fsblk_t            last_alloc_physical_block;
>  63};
>
>
> this information is maintained by ext2 for every inode.
>
> here  last_alloc_logical_block is for every inode or its for filesystem.
>

inode.

> I mean if we are allocating blocks for inode
> it can be block no.  0 to n logically
> and physically like 23 24 25 34 36 40 41 42
>
> i mean to say
>
> is it like
>
> inode1 has logical blocks 1 2 3 , physical 22 23 24
> inode2 has logical blocks 4 5 6 , physical 34 35 50
>

This is correct.
> OR
>
> inode1 has logical blocks 0 1 2 , physical 22 23 24
> inode2 has logical blocks 0 1 2 , physical 34 35 50
>

You cannot have the same logical block assigned to two inodes with
diff physical blocks, probably. Doesn't make sense to me.
> ??
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to ecartis@nl.linux.org
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>



-- 
Regards,
Sandeep.





 	
"To learn is to change. Education is a process that changes the learner."

Re: ext2_block_alloc_info

[Rohit Sharma]

Thanks for figuring it out. :)
It was a very helpful information.


On Sun, Dec 21, 2008 at 1:10 AM, Sandeep K Sinha
<sandeepksinha@gmail.com> wrote:
> Hi Rohit,
>
> On Sat, Dec 20, 2008 at 9:13 PM, Rohit Sharma <imreckless@gmail.com> wrote:
>> A little confusion.
>>
>> Just refer this structure in linux/ext2_fs_sb.h
>>
>> struct ext2_block_alloc_info {
>>  46        /* information about reservation window */
>>  47        struct ext2_reserve_window_node rsv_window_node;
>>  48        /*
>>  49         * was i_next_alloc_block in ext2_inode_info
>>  50         * is the logical (file-relative) number of the
>>  51         * most-recently-allocated block in this file.
>>  52         * We use this for detecting linearly ascending allocation requests.
>>  53         */
>>  54        __u32                   last_alloc_logical_block;
>>  55        /*
>>  56         * Was i_next_alloc_goal in ext2_inode_info
>>  57         * is the *physical* companion to i_next_alloc_block.
>>  58         * it the the physical block number of the block which was
>> most-recentl
>>  59         * allocated to this file.  This give us the goal (target)
>> for the next
>
> Look at the comment, this clearly suggests that its a file specific information.
> So, its specific to inode.
>
>>  60         * allocation when we detect linearly ascending requests.
>>  61         */
>
> It can be only to a file, as for the file system it is already ascending.
>
>>  62        ext2_fsblk_t            last_alloc_physical_block;
>>  63};
>>
>>
>> this information is maintained by ext2 for every inode.
>>
>> here  last_alloc_logical_block is for every inode or its for filesystem.
>>
>
> inode.
>
>> I mean if we are allocating blocks for inode
>> it can be block no.  0 to n logically
>> and physically like 23 24 25 34 36 40 41 42
>>
>> i mean to say
>>
>> is it like
>>
>> inode1 has logical blocks 1 2 3 , physical 22 23 24
>> inode2 has logical blocks 4 5 6 , physical 34 35 50
>>
>
> This is correct.
>> OR
>>
>> inode1 has logical blocks 0 1 2 , physical 22 23 24
>> inode2 has logical blocks 0 1 2 , physical 34 35 50
>>
>
> You cannot have the same logical block assigned to two inodes with
> diff physical blocks, probably. Doesn't make sense to me.
>> ??
>>
>> --
>> To unsubscribe from this list: send an email with
>> "unsubscribe kernelnewbies" to ecartis@nl.linux.org
>> Please read the FAQ at http://kernelnewbies.org/FAQ
>>
>>
>
>
>
> --
> Regards,
> Sandeep.
>
>
>
>
>
>
> "To learn is to change. Education is a process that changes the learner."
>

Re: ext2_block_alloc_info

[Peter Teoh]

On Sat, Dec 20, 2008 at 11:43 PM, Rohit Sharma <imreckless@gmail.com> wrote:
> A little confusion.
>
> Just refer this structure in linux/ext2_fs_sb.h
>
> struct ext2_block_alloc_info {
>  46        /* information about reservation window */
>  47        struct ext2_reserve_window_node rsv_window_node;
>  48        /*
>  49         * was i_next_alloc_block in ext2_inode_info
>  50         * is the logical (file-relative) number of the
>  51         * most-recently-allocated block in this file.
>  52         * We use this for detecting linearly ascending allocation requests.
>  53         */
>  54        __u32                   last_alloc_logical_block;

if i interpret the meaning of "file-relative logical number"
correctly, and since one-file-one-inode concept, then it means that it
should mean inode-relative logical block number.

>  55        /*
>  56         * Was i_next_alloc_goal in ext2_inode_info
>  57         * is the *physical* companion to i_next_alloc_block.
>  58         * it the the physical block number of the block which was

> inode1 has logical blocks 0 1 2 , physical 22 23 24
> inode2 has logical blocks 0 1 2 , physical 34 35 50
>

as per comment above, the sequence above looks likely, but then this
is my guess again.

-- 
Regards,
Peter Teoh

Ernest Hemingway - "Never mistake motion for action."

Re: ext2_block_alloc_info

[Mike Snitzer]

On Sat, Dec 20, 2008 at 8:25 PM, Peter Teoh <htmldeveloper@gmail.com> wrote:
> On Sat, Dec 20, 2008 at 11:43 PM, Rohit Sharma <imreckless@gmail.com> wrote:
>> A little confusion.
>>
>> Just refer this structure in linux/ext2_fs_sb.h
>>
>> struct ext2_block_alloc_info {
>>  46        /* information about reservation window */
>>  47        struct ext2_reserve_window_node rsv_window_node;
>>  48        /*
>>  49         * was i_next_alloc_block in ext2_inode_info
>>  50         * is the logical (file-relative) number of the
>>  51         * most-recently-allocated block in this file.
>>  52         * We use this for detecting linearly ascending allocation requests.
>>  53         */
>>  54        __u32                   last_alloc_logical_block;
>
> if i interpret the meaning of "file-relative logical number"
> correctly, and since one-file-one-inode concept, then it means that it
> should mean inode-relative logical block number.
>
>>  55        /*
>>  56         * Was i_next_alloc_goal in ext2_inode_info
>>  57         * is the *physical* companion to i_next_alloc_block.
>>  58         * it the the physical block number of the block which was
>
>> inode1 has logical blocks 0 1 2 , physical 22 23 24
>> inode2 has logical blocks 0 1 2 , physical 34 35 50
>>
>
> as per comment above, the sequence above looks likely, but then this
> is my guess again.

You are correct.  last_alloc_logical_block is used to detect if the
write workload against a given inode is sequential (the current
logical block is last_alloc_logical_block+1).

Mike

Re: ext2_block_alloc_info

[Peter Teoh]

[-- Attachment #1: Type: text/plain, Size: 2711 bytes --]

anyone knows any way of enumerating all the low level information like these
for each file?

Best I can get is "debugfs":

So using "show_inode_infor xxxx":

Inode: 1146884   Type: regular    Mode:  0767   Flags: 0x0   Generation:
4262211373
User:     0   Group:     0   Size: 4670783
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 9152
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x46db7fb6 -- Mon Sep  3 11:29:58 2007
atime: 0x47c66735 -- Thu Feb 28 15:48:05 2008
mtime: 0x43118298 -- Sun Aug 28 17:23:36 2005
BLOCKS:
(0-11):2317946-0, (IND):2317958, (12-1035):2317959-0, (DIND):2318983,
(IND):2318984, (1036-1140):2318985-0
TOTAL: 1144

Here the "BLOCKS" correspond to the block numbering we are talking about,
right?   It always start at 0 per-file.   "IND" is the indirect block.   But
what is "DIND"?   "2317946" is the physical block number right?   And what
is the zero after the "2317946"?

On Tue, Dec 23, 2008 at 10:56 AM, Mike Snitzer <snitzer@gmail.com> wrote:

> On Sat, Dec 20, 2008 at 8:25 PM, Peter Teoh <htmldeveloper@gmail.com>
> wrote:
> > On Sat, Dec 20, 2008 at 11:43 PM, Rohit Sharma <imreckless@gmail.com>
> wrote:
> >> A little confusion.
> >>
> >> Just refer this structure in linux/ext2_fs_sb.h
> >>
> >> struct ext2_block_alloc_info {
> >>  46        /* information about reservation window */
> >>  47        struct ext2_reserve_window_node rsv_window_node;
> >>  48        /*
> >>  49         * was i_next_alloc_block in ext2_inode_info
> >>  50         * is the logical (file-relative) number of the
> >>  51         * most-recently-allocated block in this file.
> >>  52         * We use this for detecting linearly ascending allocation
> requests.
> >>  53         */
> >>  54        __u32                   last_alloc_logical_block;
> >
> > if i interpret the meaning of "file-relative logical number"
> > correctly, and since one-file-one-inode concept, then it means that it
> > should mean inode-relative logical block number.
> >
> >>  55        /*
> >>  56         * Was i_next_alloc_goal in ext2_inode_info
> >>  57         * is the *physical* companion to i_next_alloc_block.
> >>  58         * it the the physical block number of the block which was
> >
> >> inode1 has logical blocks 0 1 2 , physical 22 23 24
> >> inode2 has logical blocks 0 1 2 , physical 34 35 50
> >>
> >
> > as per comment above, the sequence above looks likely, but then this
> > is my guess again.
>
> You are correct.  last_alloc_logical_block is used to detect if the
> write workload against a given inode is sequential (the current
> logical block is last_alloc_logical_block+1).
>
> Mike
>



-- 
Regards,
Peter Teoh

Ernest Hemingway - "Never mistake motion for action."

[-- Attachment #2: Type: text/html, Size: 4154 bytes --]

Re: ext2_block_alloc_info

[Peter Teoh]

Sorry, resent due to SMTP error:

anyone knows any way of enumerating all the low level information like
these for each file?

Best I can get is "debugfs":

So using "show_inode_infor xxxx":

Inode: 1146884   Type: regular    Mode:  0767   Flags: 0x0
Generation: 4262211373
User:     0   Group:     0   Size: 4670783
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 9152
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x46db7fb6 -- Mon Sep  3 11:29:58 2007
atime: 0x47c66735 -- Thu Feb 28 15:48:05 2008
mtime: 0x43118298 -- Sun Aug 28 17:23:36 2005
BLOCKS:
(0-11):2317946-0, (IND):2317958, (12-1035):2317959-0, (DIND):2318983,
(IND):2318984, (1036-1140):2318985-0
TOTAL: 1144

Here the "BLOCKS" correspond to the block numbering we are talking
about, right?   It always start at 0 per-file.   "IND" is the indirect
block.   But what is "DIND"?   "2317946" is the physical block number
right?   And what is the zero after the "2317946"?

On Tue, Dec 23, 2008 at 10:56 AM, Mike Snitzer <snitzer@gmail.com> wrote:
>
> On Sat, Dec 20, 2008 at 8:25 PM, Peter Teoh <htmldeveloper@gmail.com> wrote:
> > On Sat, Dec 20, 2008 at 11:43 PM, Rohit Sharma <imreckless@gmail.com> wrote:
> >> A little confusion.
> >>
> >> Just refer this structure in linux/ext2_fs_sb.h
> >>
> >> struct ext2_block_alloc_info {
> >>  46        /* information about reservation window */
> >>  47        struct ext2_reserve_window_node rsv_window_node;
> >>  48        /*
> >>  49         * was i_next_alloc_block in ext2_inode_info
> >>  50         * is the logical (file-relative) number of the
> >>  51         * most-recently-allocated block in this file.
> >>  52         * We use this for detecting linearly ascending allocation requests.
> >>  53         */
> >>  54        __u32                   last_alloc_logical_block;
> >
> > if i interpret the meaning of "file-relative logical number"
> > correctly, and since one-file-one-inode concept, then it means that it
> > should mean inode-relative logical block number.
> >
> >>  55        /*
> >>  56         * Was i_next_alloc_goal in ext2_inode_info
> >>  57         * is the *physical* companion to i_next_alloc_block.
> >>  58         * it the the physical block number of the block which was
> >
> >> inode1 has logical blocks 0 1 2 , physical 22 23 24
> >> inode2 has logical blocks 0 1 2 , physical 34 35 50
> >>
> >
> > as per comment above, the sequence above looks likely, but then this
> > is my guess again.
>
> You are correct.  last_alloc_logical_block is used to detect if the
> write workload against a given inode is sequential (the current
> logical block is last_alloc_logical_block+1).
>
> Mike



--
Regards,
Peter Teoh

Ernest Hemingway - "Never mistake motion for action."

Re: ext2_block_alloc_info

[Sandeep K Sinha]

I have a tool ready with unfolds a file system completely thrugh
ioctl. You will just have to patch the kernel.
And that also, its for ext2.
But its really verbose.

You can have a look for the sources @ http://code.google.com/p/fscops/
We will be uploading the tool there soon.

Rohit if you have a working copy can you mail it to him.

On Tue, Dec 23, 2008 at 9:59 AM, Peter Teoh <htmldeveloper@gmail.com> wrote:
> Sorry, resent due to SMTP error:
>
> anyone knows any way of enumerating all the low level information like
> these for each file?
>
> Best I can get is "debugfs":
>
> So using "show_inode_infor xxxx":
>
> Inode: 1146884   Type: regular    Mode:  0767   Flags: 0x0
> Generation: 4262211373
> User:     0   Group:     0   Size: 4670783
> File ACL: 0    Directory ACL: 0
> Links: 1   Blockcount: 9152
> Fragment:  Address: 0    Number: 0    Size: 0
> ctime: 0x46db7fb6 -- Mon Sep  3 11:29:58 2007
> atime: 0x47c66735 -- Thu Feb 28 15:48:05 2008
> mtime: 0x43118298 -- Sun Aug 28 17:23:36 2005
> BLOCKS:
> (0-11):2317946-0, (IND):2317958, (12-1035):2317959-0, (DIND):2318983,
> (IND):2318984, (1036-1140):2318985-0
> TOTAL: 1144
>
> Here the "BLOCKS" correspond to the block numbering we are talking
> about, right?   It always start at 0 per-file.   "IND" is the indirect
> block.   But what is "DIND"?   "2317946" is the physical block number
> right?   And what is the zero after the "2317946"?
>
> On Tue, Dec 23, 2008 at 10:56 AM, Mike Snitzer <snitzer@gmail.com> wrote:
>>
>> On Sat, Dec 20, 2008 at 8:25 PM, Peter Teoh <htmldeveloper@gmail.com> wrote:
>> > On Sat, Dec 20, 2008 at 11:43 PM, Rohit Sharma <imreckless@gmail.com> wrote:
>> >> A little confusion.
>> >>
>> >> Just refer this structure in linux/ext2_fs_sb.h
>> >>
>> >> struct ext2_block_alloc_info {
>> >>  46        /* information about reservation window */
>> >>  47        struct ext2_reserve_window_node rsv_window_node;
>> >>  48        /*
>> >>  49         * was i_next_alloc_block in ext2_inode_info
>> >>  50         * is the logical (file-relative) number of the
>> >>  51         * most-recently-allocated block in this file.
>> >>  52         * We use this for detecting linearly ascending allocation requests.
>> >>  53         */
>> >>  54        __u32                   last_alloc_logical_block;
>> >
>> > if i interpret the meaning of "file-relative logical number"
>> > correctly, and since one-file-one-inode concept, then it means that it
>> > should mean inode-relative logical block number.
>> >
>> >>  55        /*
>> >>  56         * Was i_next_alloc_goal in ext2_inode_info
>> >>  57         * is the *physical* companion to i_next_alloc_block.
>> >>  58         * it the the physical block number of the block which was
>> >
>> >> inode1 has logical blocks 0 1 2 , physical 22 23 24
>> >> inode2 has logical blocks 0 1 2 , physical 34 35 50
>> >>
>> >
>> > as per comment above, the sequence above looks likely, but then this
>> > is my guess again.
>>
>> You are correct.  last_alloc_logical_block is used to detect if the
>> write workload against a given inode is sequential (the current
>> logical block is last_alloc_logical_block+1).
>>
>> Mike
>
>
>
> --
> Regards,
> Peter Teoh
>
> Ernest Hemingway - "Never mistake motion for action."
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to ecartis@nl.linux.org
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>



-- 
Regards,
Sandeep.





 	
"To learn is to change. Education is a process that changes the learner."

Re: ext2_block_alloc_info

[Peter Teoh]

Very good work done.....may be 2 more document will be useful:

a.   TODO LIst:  listing your purpose/targets/directions/work
breakdown for the next few months.
b.   API List/scripts lists:  listing the work output - be
modules/scripts/or C API (userspace/kernelspace) completed, which
others may find useful.   It should coincide with your targets.

Shall browse deeper!!!

On Tue, Dec 23, 2008 at 12:37 PM, Sandeep K Sinha
<sandeepksinha@gmail.com> wrote:
> I have a tool ready with unfolds a file system completely thrugh
> ioctl. You will just have to patch the kernel.
> And that also, its for ext2.
> But its really verbose.
>
> You can have a look for the sources @ http://code.google.com/p/fscops/
> We will be uploading the tool there soon.
>
> Rohit if you have a working copy can you mail it to him.
>
> On Tue, Dec 23, 2008 at 9:59 AM, Peter Teoh <htmldeveloper@gmail.com> wrote:
>> Sorry, resent due to SMTP error:
>>
>> anyone knows any way of enumerating all the low level information like
>> these for each file?
>>
>> Best I can get is "debugfs":
>>
>> So using "show_inode_infor xxxx":
>>
>> Inode: 1146884   Type: regular    Mode:  0767   Flags: 0x0
>> Generation: 4262211373
>> User:     0   Group:     0   Size: 4670783
>> File ACL: 0    Directory ACL: 0
>> Links: 1   Blockcount: 9152
>> Fragment:  Address: 0    Number: 0    Size: 0
>> ctime: 0x46db7fb6 -- Mon Sep  3 11:29:58 2007
>> atime: 0x47c66735 -- Thu Feb 28 15:48:05 2008
>> mtime: 0x43118298 -- Sun Aug 28 17:23:36 2005
>> BLOCKS:
>> (0-11):2317946-0, (IND):2317958, (12-1035):2317959-0, (DIND):2318983,
>> (IND):2318984, (1036-1140):2318985-0
>> TOTAL: 1144
>>
>> Here the "BLOCKS" correspond to the block numbering we are talking
>> about, right?   It always start at 0 per-file.   "IND" is the indirect
>> block.   But what is "DIND"?   "2317946" is the physical block number
>> right?   And what is the zero after the "2317946"?
>>
>> On Tue, Dec 23, 2008 at 10:56 AM, Mike Snitzer <snitzer@gmail.com> wrote:
>>>
>>> On Sat, Dec 20, 2008 at 8:25 PM, Peter Teoh <htmldeveloper@gmail.com> wrote:
>>> > On Sat, Dec 20, 2008 at 11:43 PM, Rohit Sharma <imreckless@gmail.com> wrote:
>>> >> A little confusion.
>>> >>
>>> >> Just refer this structure in linux/ext2_fs_sb.h
>>> >>
>>> >> struct ext2_block_alloc_info {
>>> >>  46        /* information about reservation window */
>>> >>  47        struct ext2_reserve_window_node rsv_window_node;
>>> >>  48        /*
>>> >>  49         * was i_next_alloc_block in ext2_inode_info
>>> >>  50         * is the logical (file-relative) number of the
>>> >>  51         * most-recently-allocated block in this file.
>>> >>  52         * We use this for detecting linearly ascending allocation requests.
>>> >>  53         */
>>> >>  54        __u32                   last_alloc_logical_block;
>>> >
>>> > if i interpret the meaning of "file-relative logical number"
>>> > correctly, and since one-file-one-inode concept, then it means that it
>>> > should mean inode-relative logical block number.
>>> >
>>> >>  55        /*
>>> >>  56         * Was i_next_alloc_goal in ext2_inode_info
>>> >>  57         * is the *physical* companion to i_next_alloc_block.
>>> >>  58         * it the the physical block number of the block which was
>>> >
>>> >> inode1 has logical blocks 0 1 2 , physical 22 23 24
>>> >> inode2 has logical blocks 0 1 2 , physical 34 35 50
>>> >>
>>> >
>>> > as per comment above, the sequence above looks likely, but then this
>>> > is my guess again.
>>>
>>> You are correct.  last_alloc_logical_block is used to detect if the
>>> write workload against a given inode is sequential (the current
>>> logical block is last_alloc_logical_block+1).
>>>
>>> Mike
>>
>>
>>
>> --
>> Regards,
>> Peter Teoh
>>
>> Ernest Hemingway - "Never mistake motion for action."
>>
>> --
>> To unsubscribe from this list: send an email with
>> "unsubscribe kernelnewbies" to ecartis@nl.linux.org
>> Please read the FAQ at http://kernelnewbies.org/FAQ
>>
>>
>
>
>
> --
> Regards,
> Sandeep.
>
>
>
>
>
>
> "To learn is to change. Education is a process that changes the learner."
>



-- 
Regards,
Peter Teoh

Ernest Hemingway - "Never mistake motion for action."

Re: ext2_block_alloc_info

[Andreas Dilger]

On Dec 23, 2008  10:07 +0530, Sandeep K Sinha wrote:
> I have a tool ready with unfolds a file system completely thrugh
> ioctl. You will just have to patch the kernel.
> And that also, its for ext2.

It would be much more generic to use the FIEMAP ioctl, which has made
it into the 2.6.28 kernel.  It will currently only dump the file data
and xattr blocks, but it is designed to be extensible to allow dumping
other kinds of inode metadata (e.g. indirect/index blocks, etc).

> But its really verbose.

There are patches to e2fsprogs to allow filefrag to call FIEMAP to dump
the file layout.  They were posted to this list a few months ago, and
are scheduled for upstream inclusion.  While they will be part of e2fsprogs,
the FIEMAP ioctl is a generic mechanism that is supported by ext2/3/4,
OCFS, and XFS, and hopefully more now that it is in the kernel.

> You can have a look for the sources @ http://code.google.com/p/fscops/
> We will be uploading the tool there soon.

While the description of "What OHSM offer" sounds really good, I couldn't
find any code or description of what is actually implemented.  Is this
a system that actually works, or is it only describing what you would like
OHSM to do?

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

Re: ext2_block_alloc_info

[Sandeep K Sinha]

Thanks a lot Peter and Andreas for taking out time and going through fscops.
We welcome all your suggestion.

We will soon be uploading all the docs/sources on to the web.
Stay tuned !!!

Thanks,
Again

On Tue, Dec 23, 2008 at 1:35 PM, Andreas Dilger <adilger@sun.com> wrote:
> On Dec 23, 2008  10:07 +0530, Sandeep K Sinha wrote:
>> I have a tool ready with unfolds a file system completely thrugh
>> ioctl. You will just have to patch the kernel.
>> And that also, its for ext2.
>
> It would be much more generic to use the FIEMAP ioctl, which has made
> it into the 2.6.28 kernel.  It will currently only dump the file data
> and xattr blocks, but it is designed to be extensible to allow dumping
> other kinds of inode metadata (e.g. indirect/index blocks, etc).
>
>> But its really verbose.
>
> There are patches to e2fsprogs to allow filefrag to call FIEMAP to dump
> the file layout.  They were posted to this list a few months ago, and
> are scheduled for upstream inclusion.  While they will be part of e2fsprogs,
> the FIEMAP ioctl is a generic mechanism that is supported by ext2/3/4,
> OCFS, and XFS, and hopefully more now that it is in the kernel.
>
>> You can have a look for the sources @ http://code.google.com/p/fscops/
>> We will be uploading the tool there soon.
>
> While the description of "What OHSM offer" sounds really good, I couldn't
> find any code or description of what is actually implemented.  Is this
> a system that actually works, or is it only describing what you would like
> OHSM to do?
>
> Cheers, Andreas
> --
> Andreas Dilger
> Sr. Staff Engineer, Lustre Group
> Sun Microsystems of Canada, Inc.
>
>



-- 
Regards,
Sandeep.





 	
"To learn is to change. Education is a process that changes the learner."

Re: ext2_block_alloc_info

[Manish Katiyar]

On Tue, Dec 23, 2008 at 9:59 AM, Peter Teoh <htmldeveloper@gmail.com> wrote:
> Sorry, resent due to SMTP error:
>
> anyone knows any way of enumerating all the low level information like
> these for each file?
>
> Best I can get is "debugfs":
>
> So using "show_inode_infor xxxx":
>
> Inode: 1146884   Type: regular    Mode:  0767   Flags: 0x0
> Generation: 4262211373
> User:     0   Group:     0   Size: 4670783
> File ACL: 0    Directory ACL: 0
> Links: 1   Blockcount: 9152
> Fragment:  Address: 0    Number: 0    Size: 0
> ctime: 0x46db7fb6 -- Mon Sep  3 11:29:58 2007
> atime: 0x47c66735 -- Thu Feb 28 15:48:05 2008
> mtime: 0x43118298 -- Sun Aug 28 17:23:36 2005
> BLOCKS:
> (0-11):2317946-0, (IND):2317958, (12-1035):2317959-0, (DIND):2318983,
> (IND):2318984, (1036-1140):2318985-0
> TOTAL: 1144
>
> Here the "BLOCKS" correspond to the block numbering we are talking
> about, right?   It always start at 0 per-file.   "IND" is the indirect
> block.
>  But what is "DIND"?

Double indirect blocks ..... Sine the size of file is 4670783, we
would need 1140 direct blocks (holding data) and other indirect
blocks.

>  "2317946" is the physical block number
> right?
Yes.......

> And what is the zero after the "2317946"?
0 is just the end specifier for a range which debugfs prints. So
either you print the range of blocks or a 0 at the end to mark the
start of a new range. The code to do is present in
e2fsprogs/debugfs/debugfs.c : list_blocks_proc()

list_block_proc () {
...................
	/*
	 * Not a normal block.  Always force a new range.
	 */
	finish_range(lb);
	if (lb->first)
		lb->first = 0;
	else
		fprintf(lb->f, ", ");
	if (blockcnt == -1)
		fprintf(lb->f, "(IND):%u", *blocknr);
	else if (blockcnt == -2)
		fprintf(lb->f, "(DIND):%u", *blocknr);
	else if (blockcnt == -3)
		fprintf(lb->f, "(TIND):%u", *blocknr);
...................
}


Thanks -
Manish


>
> On Tue, Dec 23, 2008 at 10:56 AM, Mike Snitzer <snitzer@gmail.com> wrote:
>>
>> On Sat, Dec 20, 2008 at 8:25 PM, Peter Teoh <htmldeveloper@gmail.com> wrote:
>> > On Sat, Dec 20, 2008 at 11:43 PM, Rohit Sharma <imreckless@gmail.com> wrote:
>> >> A little confusion.
>> >>
>> >> Just refer this structure in linux/ext2_fs_sb.h
>> >>
>> >> struct ext2_block_alloc_info {
>> >>  46        /* information about reservation window */
>> >>  47        struct ext2_reserve_window_node rsv_window_node;
>> >>  48        /*
>> >>  49         * was i_next_alloc_block in ext2_inode_info
>> >>  50         * is the logical (file-relative) number of the
>> >>  51         * most-recently-allocated block in this file.
>> >>  52         * We use this for detecting linearly ascending allocation requests.
>> >>  53         */
>> >>  54        __u32                   last_alloc_logical_block;
>> >
>> > if i interpret the meaning of "file-relative logical number"
>> > correctly, and since one-file-one-inode concept, then it means that it
>> > should mean inode-relative logical block number.
>> >
>> >>  55        /*
>> >>  56         * Was i_next_alloc_goal in ext2_inode_info
>> >>  57         * is the *physical* companion to i_next_alloc_block.
>> >>  58         * it the the physical block number of the block which was
>> >
>> >> inode1 has logical blocks 0 1 2 , physical 22 23 24
>> >> inode2 has logical blocks 0 1 2 , physical 34 35 50
>> >>
>> >
>> > as per comment above, the sequence above looks likely, but then this
>> > is my guess again.
>>
>> You are correct.  last_alloc_logical_block is used to detect if the
>> write workload against a given inode is sequential (the current
>> logical block is last_alloc_logical_block+1).
>>
>> Mike
>
>
>
> --
> Regards,
> Peter Teoh
>
> Ernest Hemingway - "Never mistake motion for action."
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: ext2_block_alloc_info

[Eric Sandeen]

Peter Teoh wrote:
> Sorry, resent due to SMTP error:
> 
> anyone knows any way of enumerating all the low level information like
> these for each file?
> 
> Best I can get is "debugfs":

which uses libext2fs, so if you look at the debugfs source you can find
out which basic library calls to use to get this information.

> So using "show_inode_infor xxxx":
> 
> Inode: 1146884   Type: regular    Mode:  0767   Flags: 0x0
> Generation: 4262211373
> User:     0   Group:     0   Size: 4670783
> File ACL: 0    Directory ACL: 0
> Links: 1   Blockcount: 9152
> Fragment:  Address: 0    Number: 0    Size: 0
> ctime: 0x46db7fb6 -- Mon Sep  3 11:29:58 2007
> atime: 0x47c66735 -- Thu Feb 28 15:48:05 2008
> mtime: 0x43118298 -- Sun Aug 28 17:23:36 2005
> BLOCKS:
> (0-11):2317946-0, (IND):2317958, (12-1035):2317959-0, (DIND):2318983,
> (IND):2318984, (1036-1140):2318985-0
> TOTAL: 1144
> 
> Here the "BLOCKS" correspond to the block numbering we are talking
> about, right?   It always start at 0 per-file.   "IND" is the indirect
> block.   But what is "DIND"?   "2317946" is the physical block number
> right?   And what is the zero after the "2317946"?

BLOCKS: is the logical/physical mapping for the file.

(AA-BB): YY-ZZ are (logical):physical ranges.

IND is indirect, DIND is double indirect.

As for the "XXXX-0" I'm not sure offhand; it should be the start-end
range for the physical blocks.  Bug perhaps?  :)

-Eric