From: Justin Maggard <jmaggard10@gmail.com>
To: linux-ext4@vger.kernel.org
Subject: >16TB issues
Date: Thu, 2 Jul 2009 15:23:42 -0700 [thread overview]
Message-ID: <150c16850907021523p25ddae32v2eeea54418d2e6d5@mail.gmail.com> (raw)
I've been toying with ext4 and e2fsprogs pu branch (pulled from git
yesterday) on very large volumes, and I've run into some issues. What
I've found so far with an 19TB MD RAID0 volume, running 2.6.29.4 (I'm
planning on trying 2.6.30 soon):
- mkfs.ext4 *appears* to work fine, reporting no errors. Examining
the superblock info with dumpe2fs -h looks normal -- although I'm
unfamiliar with "Lifetime writes" field, and I'm not sure why it's at
73GB immediately after doing mkfs, before ever mount it.
- 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
- Trying to mount normally with no options does not work. The kernel
log contains these messages:
EXT4-fs: barriers enabled
JBD: no valid journal superblock found
EXT4-fs: error loading journal.
- Mounting with -o noload does appear to work, and reading and
writing seems to work fine.
- Setting default mount options with tune2fs works fine, as expected.
- Then, I went on to check out filesystem resizing. I created an LVM
15TB LV, and ran mkfs.ext4 on it. Looking at the superblock info, it
did not contain the 64bit flag, which I assume is expected behavior.
I extended the LV to ~18TB and tried resize2fs, and got this error:
resize2fs: Can't read an block bitmap while trying to resize /dev/data/data0
If there's anything else anyone would have me try, or any patches to
test, just let me know.
Thanks!
-Justin
next reply other threads:[~2009-07-02 22:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-02 22:23 Justin Maggard [this message]
2009-07-03 14:38 ` >16TB issues 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
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=150c16850907021523p25ddae32v2eeea54418d2e6d5@mail.gmail.com \
--to=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 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).