From: Valerie Aurora <vaurora@redhat.com>
To: Justin Maggard <jmaggard10@gmail.com>
Cc: Andreas Dilger <adilger@sun.com>, linux-ext4@vger.kernel.org
Subject: Re: >16TB issues
Date: Mon, 27 Jul 2009 18:03:08 -0400 [thread overview]
Message-ID: <20090727220308.GV27582@shell> (raw)
In-Reply-To: <150c16850907221527l3060aa85h883656bcc7d7e1c4@mail.gmail.com>
On Wed, Jul 22, 2009 at 03:27:24PM -0700, Justin Maggard wrote:
> On Tue, Jul 21, 2009 at 12:21 PM, Andreas Dilger<adilger@sun.com> wrote:
> >> I shouldn't need e2fsprogs to be compiled 64-bit as well, right?
> >> Currently I've got a 64-bit kernel with 32-bit userspace.
> >
> > Yes, that is a potential problem.
>
> It looks like it certainly is a problem with current e2fsprogs "pu"
> branch. My latest findings from basic testing (just mkfs.ext4, then
> e2fsck -fy, and -- if e2fsck modified the filesystem -- another e2fsck
> -fy) are as follows:
>
> 1) 64-bit mke2fs + 64-bit e2fsck
> Appears to work fine. No errors reported anywhere.
>
> 2) 64-bit mke2fs + 32-bit e2fsck
> Also appears to work fine. llverfs --partial looked okay, and e2fsck
> reported no errors.
>
> 3) 32-bit mke2fs + 64-bit e2fsck
> Mkfs.ext4 must have done something wrong, but e2fsck was able to fix
> it up, and future e2fsck (32 or 64-bit) runs reported no issues.
> e2fsck output was:
> Block bitmap differences: +(1063780365--1063780367)
> +(1063780381--1063780383) +(1063782048--1063782431)
> -(5359140864--5359173631)
> Running mkfs through valgrind doesn't show any obvious errors.
>
> 4) 32-bit mke2fs + 32-bit e2fsck
> Same as (3), for the mkfs and the first e2fsck again reported fixing
> the same block bitmap differences. But after the first e2fsck was
> complete, the second e2fsck run reported:
> e2fsck: Superblock invalid, trying backup blocks...
> Group descriptor 0 checksum is invalid. Fix? yes
> Group descriptor 1 checksum is invalid. Fix? yes
> ...
> Group descriptor 81774 checksum is invalid. Fix? yes
> followed by tons of block bitmap differences.
Great, this is really helpful. I've added it to my todo list.
-VAL
next prev parent reply other threads:[~2009-07-27 22:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-02 22:23 >16TB issues Justin Maggard
2009-07-03 14:38 ` Andreas Dilger
2009-07-16 18:04 ` Justin Maggard
2009-07-16 18:59 ` Valerie Aurora
2009-07-21 16:10 ` Andreas Dilger
2009-07-21 18:52 ` Justin Maggard
2009-07-21 18:57 ` Eric Sandeen
2009-07-21 19:21 ` Andreas Dilger
2009-07-22 22:27 ` Justin Maggard
2009-07-27 22:03 ` Valerie Aurora [this message]
2009-07-30 22:23 ` Valerie Aurora
2009-08-01 1:24 ` Justin Maggard
2009-08-03 17:20 ` Valerie Aurora
2009-08-11 21:39 ` Valerie Aurora
2009-08-11 22:05 ` Theodore Tso
2009-08-12 1:25 ` Valerie Aurora
2009-08-12 2:04 ` Theodore Tso
2009-08-12 17:59 ` Valerie Aurora
2009-08-28 2:30 ` Justin Maggard
2009-08-28 12:40 ` Theodore Tso
2009-08-28 20:27 ` Justin Maggard
2009-08-12 4:21 ` Eric Sandeen
2009-08-12 5:35 ` Justin Maggard
2009-08-12 14:12 ` 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=20090727220308.GV27582@shell \
--to=vaurora@redhat.com \
--cc=adilger@sun.com \
--cc=jmaggard10@gmail.com \
--cc=linux-ext4@vger.kernel.org \
/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.