On Jan 7, 2015, at 9:05 PM, Phillip Susi <psusi@xxxxxxxxxx> wrote: > On 01/06/2015 11:15 PM, Dave Chinner wrote: >> (e.g. in ext4 inode tables because mkfs used to zero them) if they >> haven't been used, so when it reads them it detects that >> initialisation is needed because the blocks are empty.... > > No, it knows that the inode table needs initialized because there is a > flag in the group descriptor that says this inode table is still > uninitalized. It never reads the blocks to see if they are full of > zeros. mke2fs sets the flag when it does not initialize the table > with zeros, either by direct writes ( which it doesn't do if > lazy_itable_init is true, which it defaults to these days ), or by > discarding the blocks when the device claims to support deterministic > discard that zeros. That is only partially correct. While it is true that mke2fs sets the UNINIT flag at format time, the "lazy" part of that means there is a kernel thread still does the zeroing of the inode table blocks, but after the filesystem is mounted, for any group that does not have the ZEROED flag set. After that point, the "UNINIT" flag is an optimization to avoid reading the bitmap and unused blocks from disk during allocation. This is needed in case the group descriptor or inode bitmap is corrupted, and e2fsck needs to scan the inode table for in-use inodes. We don't want it to find old inodes from before the filesystem was formatted. The ext4_init_inode_table() calls sb_issue_zeroout->blkdev_issue_zeroout(), so if the underlying storage supported deterministic zeroing of the underlying storage, this could be handled very efficiently. Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
