Can anyone tell me the history of CONFIG_EXT{2,3}_CHECK?
There is code for a "check" option for mount if these options are
enabled, but there's no way to enable them.
TIA
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Oct 31, 2005 01:13 +0100, Adrian Bunk wrote:> Can anyone tell me the history of CONFIG_EXT{2,3}_CHECK? > > There is code for a "check" option for mount if these options are > enabled, but there's no way to enable them.These are expensive debugging options, which walk the inode/block bitmaps for getting the group inode/block usage instead of using the group summary data. Not used very often but I suspect occasionally useful for developers mucking with ext[23] internals. Since it is developer-only code it needs to be enabled with #define CONFIG_EXT[23]_CHECK in a header or compile option. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.
On Mon, Oct 31, 2005 at 02:25:03PM -0700, Andreas Dilger wrote:> On Oct 31, 2005 01:13 +0100, Adrian Bunk wrote: > > Can anyone tell me the history of CONFIG_EXT{2,3}_CHECK? > > > > There is code for a "check" option for mount if these options are > > enabled, but there's no way to enable them. > > These are expensive debugging options, which walk the inode/block bitmaps > for getting the group inode/block usage instead of using the group > summary data. Not used very often but I suspect occasionally useful for > developers mucking with ext[23] internals. Since it is developer-only > code it needs to be enabled with #define CONFIG_EXT[23]_CHECK in a > header or compile option.It's basically a stripped down version of e2fsck pass #5, though. Is there any reason why this needs to be in the kernel? If it would be useful I could easily make a userspace implementation of these checks. - Ted