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