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

Message-ID: <alpine.LFD.2.00.1008261342280.4071@dhcp-lab-213.englab.brq.redhat.com>
Date:	Thu, 26 Aug 2010 14:14:41 +0200 (CEST)
From:	Lukas Czerner <lczerner@...hat.com>
To:	Peng Tao <bergwolf@...il.com>
cc:	Lukas Czerner <lczerner@...hat.com>, 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

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 hope it helped.

Regards.
-Lukas
--
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