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
??
Hi Rohit,
On Sat, Dec 20, 2008 at 9:13 PM, Rohit Sharma <[email protected]> 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 [email protected]
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>
--
Regards,
Sandeep.
"To learn is to change. Education is a process that changes the learner."
Thanks for figuring it out. :)
It was a very helpful information.
On Sun, Dec 21, 2008 at 1:10 AM, Sandeep K Sinha
<[email protected]> wrote:
> Hi Rohit,
>
> On Sat, Dec 20, 2008 at 9:13 PM, Rohit Sharma <[email protected]> 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 [email protected]
>> Please read the FAQ at http://kernelnewbies.org/FAQ
>>
>>
>
>
>
> --
> Regards,
> Sandeep.
>
>
>
>
>
>
> "To learn is to change. Education is a process that changes the learner."
>
On Sat, Dec 20, 2008 at 11:43 PM, Rohit Sharma <[email protected]> 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."
On Sat, Dec 20, 2008 at 8:25 PM, Peter Teoh <[email protected]> wrote:
> On Sat, Dec 20, 2008 at 11:43 PM, Rohit Sharma <[email protected]> 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
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 <[email protected]> wrote:
>
> On Sat, Dec 20, 2008 at 8:25 PM, Peter Teoh <[email protected]> wrote:
> > On Sat, Dec 20, 2008 at 11:43 PM, Rohit Sharma <[email protected]> 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."
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 <[email protected]> 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 <[email protected]> wrote:
>>
>> On Sat, Dec 20, 2008 at 8:25 PM, Peter Teoh <[email protected]> wrote:
>> > On Sat, Dec 20, 2008 at 11:43 PM, Rohit Sharma <[email protected]> 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 [email protected]
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>
--
Regards,
Sandeep.
"To learn is to change. Education is a process that changes the learner."
On Tue, Dec 23, 2008 at 9:59 AM, Peter Teoh <[email protected]> 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 <[email protected]> wrote:
>>
>> On Sat, Dec 20, 2008 at 8:25 PM, Peter Teoh <[email protected]> wrote:
>> > On Sat, Dec 20, 2008 at 11:43 PM, Rohit Sharma <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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 <[email protected]> wrote:
> On Sat, Dec 20, 2008 at 8:25 PM, Peter Teoh <[email protected]>
> wrote:
> > On Sat, Dec 20, 2008 at 11:43 PM, Rohit Sharma <[email protected]>
> 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."
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
<[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
>>>
>>> On Sat, Dec 20, 2008 at 8:25 PM, Peter Teoh <[email protected]> wrote:
>>> > On Sat, Dec 20, 2008 at 11:43 PM, Rohit Sharma <[email protected]> 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 [email protected]
>> 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."
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.
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 <[email protected]> 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."
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