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

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] [day] [month] [year] [list]

Date:	Thu, 26 Aug 2010 22:15:17 +0800
From:	Peng Tao <bergwolf@...il.com>
To:	Lukas Czerner <lczerner@...hat.com>
Cc:	linux-ext4@...r.kernel.org, rwheeler@...hat.com,
	sandeen@...hat.com, jack@...e.cz, tytso@....edu, adilger@...ger.ca
Subject: Re: [PATCH 3/3] Add inode table initialization code into Ext4

Hi, Lukas,

On Thu, Aug 26, 2010 at 8:14 PM, Lukas Czerner <lczerner@...hat.com> wrote:
> On Thu, 26 Aug 2010, Peng Tao wrote:
>
>> Hi, all,
>>
>> On Sat, Aug 21, 2010 at 1:51 AM, Lukas Czerner <lczerner@...hat.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html