-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/7/2015 11:58 PM, Andreas Dilger wrote: >> 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. That is pretty much what I said, except that I was pointing out that it does not *read* first to see if the disk is already zeroed, as that would be a waste of time. It just writes out the zeros for block groups that still have the uninit flag set. > 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. Again, that's pretty much what I said. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUro+rAAoJENRVrw2cjl5RDcMIAIF/qOjB4FfQ1v1NPLnbYrwa MeGxmAGIq8ftOlfOpSo8W/Adal4eegPwiBzE/8JciTHli2hZFkboG96lCGLL2GHd 51gqADIcSUmPHleLP3L/MSleFLvOAC4xYWYi00idZF5UVK3tt6m07+T/DCkoku1L 8Yg0BH5rxxRyPMRe3a/Y3WoI3PFFQDiDhz/7PSFH1W6JrEmiZutIDfm/U4h6zFWU tlNUMyiya8DrJt4katjBTa74EPWdZQjT/dOuUGGslAgOro69ZZQ4jmEXeJGN96Ly mMhbzkw9mjvSHYWuH2Hf1QlxoMKgq1hxaNbwEtImBzYeQTb9VSqM6BSO1ru0m9M= =X07B -----END PGP SIGNATURE----- -- 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
