lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <150c16850907021523p25ddae32v2eeea54418d2e6d5@mail.gmail.com>
Date:	Thu, 2 Jul 2009 15:23:42 -0700
From:	Justin Maggard <jmaggard10@...il.com>
To:	linux-ext4@...r.kernel.org
Subject: >16TB issues

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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ