From: Justin Maggard <jmaggard10@gmail.com>
To: Andreas Dilger <adilger@sun.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: >16TB issues
Date: Thu, 16 Jul 2009 11:04:41 -0700 [thread overview]
Message-ID: <150c16850907161104j5e059baep988c5f04a0552c8c@mail.gmail.com> (raw)
In-Reply-To: <20090703143729.GJ20343@webber.adilger.int>
On Fri, Jul 3, 2009 at 7:38 AM, Andreas Dilger<adilger@sun.com> wrote:
>> - Immediately running e2fsck on the volume before ever mounting it
>> will not complete, and results in the following:
>> # e2fsck -n /dev/md2
>> e2fsck 1.41.7 (29-June-2009)
>> Error reading block 2435874816 (Attempt to read block from filesystem
>> resulted in short read). Ignore error? no
>> /dev/md2: Attempt to read block from filesystem resulted in short read
>> while reading block 2435874816
>> /dev/md2: Attempt to read block from filesystem resulted in short read
>> reading journal superblock
>> e2fsck: Attempt to read block from filesystem resulted in short read
>> while checking ext3 journal for /dev/md2
>
> It looks like there may be some problem with the underlying device?
> I posted a program here a few months ago called "ll_ver_dev" which
> can quickly (or slowly) verify that writes and reads to different
> offsets in a block device return consistent data. The quick version
> will detect such problems as 32-bit overflows, but if you are having
> strange problems you might need to run the full version.
>
> You could also try running with a filesystem just under 16TB and
> verifying that works.
>
Running with a filesystem just under 16TB works fine. Forgive my
ignorance, but for the life of me I couldn't find an reference
anywhere about your "ll_ver_dev" program. But doing dd if=/dev/zero
across the entire ~18TB didn't report any errors, so I believe the
underlying device is in good shape.
Running e2fsck with an external journal did change the behavior
though. Basically it no longer chokes on the journal, but it does
somewhere else:
e2fsck 1.41.8 (11-July-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Error reading block 576192512 (Attempt to read block from filesystem
resulted in short read) while reading inode and block bitmaps. Ignore
error? no
e2fsck: Can't read an block bitmap while retrying to read bitmaps for /dev/md2
e2fsck: aborted
>> - Mounting with -o noload does appear to work, and reading and
>> writing seems to work fine.
>
> That's because the journal is not being used, which is what seems to
> be having the problem. I wonder if the journal is beyond 8TB or
> beyond 16TB for some reason and this is causing grief?
>
Perhaps, but I'm not sure. Using an external journal device also
worked the same as not loading the journal.
-Justin
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-07-16 18:04 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 [this message]
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
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=150c16850907161104j5e059baep988c5f04a0552c8c@mail.gmail.com \
--to=jmaggard10@gmail.com \
--cc=adilger@sun.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 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).