linux-ext4 - Re: [PATCH 2/2 bigalloc] e2fsprogs: use s_log_block_size to decide s_first_data_block in ext2fs

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20110811032343.GG3625@thunk.org>
Date:	Wed, 10 Aug 2011 23:23:43 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Robin Dong <hao.bigrat@...il.com>
Cc:	linux-ext4@...r.kernel.org, Robin Dong <sanbai@...bao.com>
Subject: Re: [PATCH 2/2 bigalloc] e2fsprogs: use s_log_block_size to decide
 s_first_data_block in ext2fs_initialize

On Fri, Aug 05, 2011 at 12:27:51PM +0800, Robin Dong wrote:
> From: Robin Dong <sanbai@...bao.com>
> 
> After mke2fs with 1024 block size:
> 
> #misc/mke2fs -m 0 -O ^resize_inode,extent,meta_bg,bigalloc -b 1024 /dev/sda
> 
> kernel reports:
> 
> [74687.352702] EXT4-fs (loop0): ext4_check_descriptors: Inode bitmap for group 0 not in group (block 524288)!
> [74687.355534] EXT4-fs (loop0): group descriptors corrupted!
> 
> when mount /dev/sda.

Wow, out of curiosity, why are you using a 1k block size?

Actually, the bug here is in the kernel (in complaining), not in
e2fsprogs.  The only time we want s_first_data_block to be 1 is in the
case when block size and cluster is 1024.

In the case where the cluster is greater than 1k, we want to keep the
clusters aligned (for efficiency with 4k blocksize disks if for no
other reason).  Since the superblock is located at a 1k offset,
cluster #0 will always be reserved, so the first 1k is already
reserved for use by the bootloader.

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