>> [ ... ] im on debian squeeze 2.6.32-5-amd64 [ ... ]
>> resize2fs: New size too large to be expressed in 32 bits [
>> ... ] data1 vgRAID6 -wi-ao 18.00t
>> Thanks for letting us know that 'resize2fs' and 'ext3'
and
>> the Linux kernel continue to behave as documented.
Someone sent me an email with this question, and the answer may
be useful to others:
> but: where is it documented? [ ... ]
The 'ext3' filesystem is limited to 8/16TiB:
https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Bigger_File_System_and_File_Sizes
?Currently, Ext3 support 16 TiB of maximum file system size and
2 TiB of maximum file size.?
(the same information appears in Wikipedia etc.) and this is
the 'ext3' mailing list, not the 'ext4' mailing list which is
served at another place:
https://ext4.wiki.kernel.org/index.php/Mailinglists
so I must assume that the original poster was indeed trying to
create an 'ext3' filesystem, and this configuration is thus not
going to take effect anyhow:
> ext4 = {
> features =
has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
> auto_64-bit_support = 1 ## ADDED THIS
> inode_size = 256
> }
It might feel tempting to convert an 'ext3' filesystem to 'ext4'
to escape the 8/16TiB limitation, but even for 'ext4' there is a
resize limit of less than 8/16TiB if the filesystem initial size
was less than 8/16TiB (which it must be if it was initially
'ext3'), because the 'ext4' ondisk layout by default is
compatible then with the 'ext3' ondisk layout if possible and
thus uses 32b offsets by default:
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Block_Group_Descriptors
?In ext2, ext3, and ext4 (when the 64bit feature is not enabled),
the block group descriptor was only 32 bytes long and therefore
ends at bg_used_dirs_count_lo. On an ext4 filesystem with the
64bit feature enabled, the block group descriptor expands to the
full 64 bytes described below.?
http://comments.gmane.org/gmane.comp.file-systems.ext4/33531 It
?It is possible to format a 32-bit filesystem with larger group
descriptors using the "-O 64bit" option, but this doesn't
happen by default today.
Possibly we should start using the 64-byte group descriptors
by default for filesystems over, say, 4 TB, so they can be
resized beyond 16 TB.
It might also be possible to modify resize2fs to change the
pgroup descriptor size, but that isn't possible today.?
But the original poster reported:
>> resize2fs 1.41.14 (22-Dec-2010)
and the configuration above is not going to work anyhow as
'e2fsprogs' before 1.42 do not support sizes larger than 8/16TiB
for 'ext4' anyhow:
https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Bigger_File_System_and_File_Sizes
?Ext4 adds 48-bit block addressing, so it will have 1 EiB[1] of
maximum file system size and 16 TiB of maximum file size. [
... ] NOTE! The code to create file systems bigger than 16 TiB
is, at the time of writing this article, not in any stable
release of e2fsprogs. It will be in future releases.?
http://os1a.cs.columbia.edu/lxr/source/Documentation/filesystems/ext4.txt?v=2.6.32
?* ability to use filesystems > 16TB (e2fsprogs support not
available yet)?
http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.42
?E2fsprogs 1.42 (November 29, 2011)
This release of e2fsprogs has support for file systems > 16TB.
Online resize requires kernel support which will hopefully be in
Linux version 3.2?
The above links also appeared in a web search for the phrase
"too large to be expressed in 32 bits" which yields some more
useful links (for 'ext4'):
http://blog.ronnyegner-consulting.de/2011/08/18/ext4-and-the-16-tb-limit-now-solved/
http://forums.debian.net/viewtopic.php?f=5&t=77522
Anyhow I reckon that filesystems significantly larger than
2-6TiB are not a good idea for a number of important reasons,
which however matter only when things go wrong, so most people
don't care, and that resizing is a somewhat dangerous operation
that has performance problems, so overall I would not recommend
going looking for trouble...