Re: [PATCH 3/3] Add inode table initialization code into Ext4

[Peng Tao <bergwolf@gmail.com>]

Hi, Lukas,

On Thu, Aug 26, 2010 at 8:14 PM, Lukas Czerner <lczerner@redhat.com> wrote:
> On Thu, 26 Aug 2010, Peng Tao wrote:
>
>> Hi, all,
>>
>> On Sat, Aug 21, 2010 at 1:51 AM, Lukas Czerner <lczerner@redhat.com> wrote:
>> > When lazy_itable_init extended option is passed to mke2fs, it
>> > considerably speed up filesystem creation because inode tables are left
>> > uninitialized, thus contains some old data. When this fs is mounted
>> > filesystem code should initialize (zero out) uninitialized inode table.
>> > So far this code was missing for ext4 and this patch adds this feature.
>> >
>> > When file system is mounted with "inititable" mount option, new thread
>> > (called itableinitd) is created. This thread walks through allocation
>> > groups searching for the group with not yet initialized inode table.
>> > When such a group is found it write zeroes through whole inode table and
>> > put itself into sleep for defined number of seconds to not disturb other
>> > ongoing I/O. This is repeated until it walks through every allocation group
>> > then the iitableinitd thread is stopped.
>> This will slow down e2fsck speed that is gained from uninitialized
>> italbe. Am I missing something? What about having another block group
>> flag to tell itable that is just zeroed but not used, from itable that
>> is already in use?
>>
>
> Hi,
>
> this is probably my bad. I should have used term "zeroed inode table" instead
> of "initialized inode table". You see, there are two flags.
>
> * EXT4_BG_INODE_UNINIT tells us that inode BITMAP was not used yet, thus
>  no inode was allocated from that group just yet, so kernel need not to
>  read this bitmap from the disk and rather construct fresh (zeroed)
>  inode bitmap in memory (see ext4_init_inode_bitmap).
>
> * EXT4_BG_INODE_ZEROED tells us whether or not inode TABLE was
>  zeroed out. This is the flag which is set by the mkfs when
>  lazy_itable_init extended option is set. This flag was not used
>  for anything useful in kernel, nor e2fsck until now.
>
> Se when the thread is done zeroing the inode table it sets the
> EXT4_BG_INODE_ZEROED flag, but leaves EXT4_BG_INODE_UNINIT as is, so
> e2fsck should not be any slower.
I see it. Thank you very much for the explanation.



-- 
Thanks,
-Bergwolf
--
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