On 26/07/14 20:45, Theodore Ts'o wrote:
OK, it looks like the e2fsprogs patch got you through the first
hurdle, but the failure is something that made no sense at first:
[489412.650430] EXT4-fs (md0): resizing filesystem from 5804916736 to
5860149888 blocks
[489412.700282] EXT4-fs warning (device md0): verify_reserved_gdb:713:
reserved GDT 2769 missing grp 177147 (5804755665)
The code path which emitted the above warning something that should
ever be entered for file systems greater than 16TB. But then I took a
look at the first message that you sent on this thread, and I think
see what's going wrong. From your dumpe2fs -h output:
Filesystem features: has_journal ext_attr resize_inode dir_index filetype
extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink
extra_isize
Block count: 5804916736
Reserved GDT blocks: 585
If the block count is greater than 2**32 (4294967296), resize_inode
must not be set, and reserved GDT blocks should be zero. So this is
definitely not right.
I'm going to guess that this file system was originally a smaller size
(and probably smaller than 16T), and then was resized to 22TB,
probably using an earlier version of the kernel and/or e2fsprogs. Is
my guess correct? If so, do you remember the history of what size the
file system was, and in what steps it was resized, and what version of
the e2fsprogs and the kernel that was used at each stage, starting
from the original mke2fs and each successive resize?
This was the first resize of this FS. Initially this array was about
15T. About 12 months ago I attempted to resize it up to 19T and bumped
up against the fact I had not created the initial filesystem with 64 bit
support, so I cobbled together some storage and did a
backup/create/restore. At that point I would probably have specified
resize_inode manually as an option (as reading the man page it looked
like a good idea as I always had plans to expand in future) to mke2fs
along with 64bit. Fast forward 12 months and I've added 2 drives to the
array and bumped up against this issue. So it was initially 4883458240
blocks. It would have been created with e2fsprogs from Debian Stable (so
1.42.5).
I can't test this to verify my memory however as I don't seem to be able
to create a sparse file large enough to create a filesystem in. I appear
to be bumping up against a 2T filesize limit.
--
Dolphins are so intelligent that within a few weeks they can
train Americans to stand at the edge of the pool and throw them
fish.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
