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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 10 Jun 2009 18:41:22 -0400
From:	Howard Cochran <hcochran@...mark.com>
To:	linux-ext4@...r.kernel.org
Subject: Kernel thread to zero itables for lazy_itable_init?

Greetings.

What is the status of the code to start a background kernel thread to 
zero the inode tables when filesystem that was created with mke2fs -E 
lazy_itable_init is mounted?  All I have found is a patch set posted to 
this mailing list back on November 21, 2008 and some discussion of the 
implementation, but nothing after that.

Is this effort still alive?

On a related note, from what I have read here, and from looking at the 
ext4 kernel code, the filesystem itself never really requires the inode 
tables to be zeroed out.  The only reason one might want to do that is 
so that fsck does not detect false errors. 

But, in data=ordered mode, would not marking the inode as allocated in 
the bitmap be done in the same journal transaction as populating the 
inode on disk (as well as creating a directory entry pointing to it)?  
And, unless the journal is broken, then either all that succeeds or none 
of it does.  So outside of a hardware failure, or data being overwritten 
directly on the block device, it's not possible for an "actually in-use" 
inode to be marked unallocated in the inode bitmap.

So, I am wondering whether we really need the complexity of a kernel 
thread to zero out the itable (or the long delay of doing it during 
mke2fs).  Instead, would it not be better to modify fsck to ignore 
garbage in unallocated inodes, at least for filesystems that have a journal.

Thanks,
Howard Cochran

--
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