lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2d08ef090812201144t63266826ob038c530ba9f66cd@mail.gmail.com>
Date:	Sun, 21 Dec 2008 01:14:16 +0530
From:	"Rohit Sharma" <imreckless@...il.com>
To:	"Sandeep K Sinha" <sandeepksinha@...il.com>
Cc:	Kernelnewbies <kernelnewbies@...linux.org>,
	ext4 <linux-ext4@...r.kernel.org>
Subject: Re: ext2_block_alloc_info

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


On Sun, Dec 21, 2008 at 1:10 AM, Sandeep K Sinha
<sandeepksinha@...il.com> wrote:
> Hi Rohit,
>
> On Sat, Dec 20, 2008 at 9:13 PM, Rohit Sharma <imreckless@...il.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@...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."
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ