linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ted Ts'o <tytso@mit.edu>
To: Robin Dong <hao.bigrat@gmail.com>
Cc: linux-ext4@vger.kernel.org, Robin Dong <sanbai@taobao.com>
Subject: Re: [PATCH 2/2 bigalloc] e2fsprogs: use s_log_block_size to decide s_first_data_block in ext2fs_initialize
Date: Wed, 10 Aug 2011 23:23:43 -0400	[thread overview]
Message-ID: <20110811032343.GG3625@thunk.org> (raw)
In-Reply-To: <1312518471-30714-2-git-send-email-hao.bigrat@gmail.com>

On Fri, Aug 05, 2011 at 12:27:51PM +0800, Robin Dong wrote:
> From: Robin Dong <sanbai@taobao.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

  reply	other threads:[~2011-08-11  3:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-05  4:27 [PATCH 1/2 bigalloc] e2fsprogs: change "blocks" to "clusters" in dumpe2fs Robin Dong
2011-08-05  4:27 ` [PATCH 2/2 bigalloc] e2fsprogs: use s_log_block_size to decide s_first_data_block in ext2fs_initialize Robin Dong
2011-08-11  3:23   ` Ted Ts'o [this message]
2011-08-05  6:35 ` [PATCH 1/2 bigalloc] e2fsprogs: change "blocks" to "clusters" in dumpe2fs Andreas Dilger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110811032343.GG3625@thunk.org \
    --to=tytso@mit.edu \
    --cc=hao.bigrat@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sanbai@taobao.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).