From: Theodore Ts'o <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>
Cc: ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] e2fsprogs: allocate inode table wholly within group
Date: Sun, 7 Jul 2013 19:34:05 -0400 [thread overview]
Message-ID: <20130707233405.GA14906@thunk.org> (raw)
In-Reply-To: <20130707155316.GB11993@thunk.org>
On Sun, Jul 07, 2013 at 11:53:16AM -0400, Theodore Ts'o wrote:
> There seems to be something wrong here. The test file system was
> created like this:
>
> mke2fs -t ext2 -O ^resize_inode -b 1024 -g 1024 -qF /tmp/foo.img 64M
>
> The file system hence should have 64 block groups, and dumpe2fs before
> the resize looks like this on an x86 system:
>
> Group 1: (Blocks 1025-2048)
> Backup superblock at 1025, Group descriptors at 1026-1027
> Block bitmap at 1028 (+3), Inode bitmap at 1029 (+4)
> Inode table at 1030-1061 (+5)
>
> ... and after:
>
> Group 1: (Blocks 1025-2048)
> Backup superblock at 1025, Group descriptors at 1026-1089
> Block bitmap at 1090 (+65), Inode bitmap at 1091 (+66)
> Inode table at 1092-1123 (+67)
>
> Note the range of block group #1: 1025-2048, whereas on the PPC,
> apparently the range is quite different: Group 1: (Blocks 1025-1110)
>
> So there's something else going really wrong here....
I just tried building e2fsprogs 1.42.8 on a powerpc system in a Debian
unstable (sid) chroot, and I'm not able to reproduce this test
failure. I tried building using both gcc 4.6.4 and gcc 4.8, in case
it was a compiler bug.
So again, there's something really, REALLY wrong....
- Ted
next prev parent reply other threads:[~2013-07-07 23:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-02 19:14 [PATCH] e2fsprogs: allocate inode table wholly within group Eric Sandeen
2013-07-04 14:19 ` [PATCH] e2fsprogs FTBFS: " Eric Sandeen
2013-07-07 15:53 ` [PATCH] e2fsprogs: " Theodore Ts'o
2013-07-07 23:34 ` Theodore Ts'o [this message]
2013-07-08 1:59 ` Eric Sandeen
2013-07-08 18:34 ` Eric Sandeen
2013-07-08 21:27 ` Eric Sandeen
2013-10-01 1:57 ` Theodore Ts'o
2013-10-01 3:59 ` [PATCH 1/4] resize2fs: add debugging support for resize2fs -M calcuations Theodore Ts'o
2013-10-01 3:59 ` [PATCH 2/4] resize2fs: fix -M size calculations to avoid cutting off the inode table Theodore Ts'o
2013-10-01 3:59 ` [PATCH 3/4] resize2fs: relocate inode table blocks if necessary when shrinking Theodore Ts'o
2013-10-01 3:59 ` [PATCH 4/4] tests: add test for resize2fs -M with inode table in middle of block group Theodore Ts'o
2013-10-01 15:26 ` [PATCH] e2fsprogs: allocate inode table wholly within group Eric Sandeen
2013-10-01 15:35 ` Eric Sandeen
2013-10-01 16:29 ` Eric Sandeen
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=20130707233405.GA14906@thunk.org \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.