Raid resize from 12tb to over 16tb

Kernels & Hardware, configuring network, installing services

Raid resize from 12tb to over 16tb

Postby misterpat » 2012-03-22 23:05

Greetings everyone!

I have a NAS box at my house that currently has 11 2tb drives in it. I just added the last 2 which put me over 16tb. I've been researching for ways to resize it and found the following information. I'm using mdadm to manage the raid.

http://www.phoronix.com/scan.php?page=news_item&px=MTA0MDg

The EXT4 file-system pull request went in today for the Linux 3.3 kernel. The EXT4 updates for this next kernel include the new online resize interface.

Among various bug-fixes and other changes to the current de facto standard Linux file-system, EXT4 now has the new online resize interface, which was first publicly introduced a few months back. The new online resize interface for EXT4 is the work of Yongqiang Yang.

As far as what the new online resize interface is for with EXT4, "It is a new online resize interface for ext4. It can be used via ioctl with EXT4_IOC_RESIZE_FS and a 64 bit integer indicating size of the resized fs in block."

What makes Yongqiang's implementation different though from the status quo online resize of EXT4 is that the kernel now does all the work. The resizing now is also much faster. Benchmarks shown by Yongqiang indicate the file-system resize operation with this new code is now significantly faster. A 20GB resize on the old code toook over five minutes with the pre-3.3 implementation, but now he's shown that it can be done in just 3.35 seconds. A 100GB resize can be done in less than a half second.

Besides being much faster for resizing the file-system, the new code can also more easily handle new features. "New resize can support new feature like bigalloc and exclude bitmap easily. Because it lets kernel do all work."

The EXT4 new online resize code is specifically talked about in this mailing list message (among others) from the past few months. The new resize code adds in around 1,000 lines of code to the file-system's kernel module.

The pull request for the Linux 3.3 kernel that includes this work plus other EXT4 changes can be found in this email from Ted Ts'o.

This EXT4 improvement is just one of the many features of the Linux 3.3 kernel, which has just begun development and will be officially released in about two months. The Btrfs file-system pull request for 3.3 has yet to hit, but we'll see if it brings work like the pretty beefy changes it had in the last kernel cycle. Hopefully you're also not waiting on the Reiser4 file-system to go mainline.


So I updated my system, Debian Wheezy, to the 3.3 kernel. Im also running e2fsprogs 1.42.1-2 which should support online resizing.

But when I tried to resize from 12tb to over 16tb, Im getting the famous message.

Code: Select all
root@mega:~# resize2fs /dev/md0
resize2fs 1.42.1 (17-Feb-2012)
resize2fs: New size too large to be expressed in 32 bits


Upon further research, I found this.

http://ubuntuforums.org/showpost.php?p=10995759&postcount=6

There isn't a way to get around this issue, I'm afraid. Support for >
16TB file systems is something that requires a fundamental change in
the file system format, and which is in late beta status.

It requires the pre-release, e2fsprogs 1.42 development branch, and
unfortunately, the file system must be reformatted to support larger
(greater than 32-bit) block numbers. Certain on-disk data structures
(specifically, the block group descriptors) have to grow in size from
32 bytes to 64 bytes, so it's not something where we could upgrade a
file system in-place to support > 16TB.

Sorry, I'm afraid can't give you a magic solution to your problem....

Regards,

- Ted


So, it seems that if I back up my data, wipe the drives, make a new file system, I should be good to go? Anyone have any input on this? Thanks for Your time.
misterpat
 
Posts: 11
Joined: 2012-03-22 22:56

Return to System configuration

Who is online

Users browsing this forum: No registered users and 11 guests

fashionable