Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   EXT3 Users (http://www.linux-archive.org/ext3-users/)
-   -   resize too large (http://www.linux-archive.org/ext3-users/690550-resize-too-large.html)

"william L'Heureux" 08-04-2012 01:26 PM

resize too large
 
I have a file system I am trying to resize via resize2fs but I get this error

resize2fs 1.41.14 (22-Dec-2010)
resize2fs: New size too large to be expressed in 32 bits

im on debian squeeze 2.6.32-5-amd64

# pvs
* PV******** VG***** Fmt* Attr PSize* PFree
* /dev/md1** vgRAID6 lvm2 a-** 18.17t 134.12g

# lvs
* LV*** VG***** Attr** LSize* Origin Snap%* Move Log Copy%* Convert
* data1 vgRAID6 -wi-ao 18.00t

and the cryptsetup resize worked like a charm. I ran* e2fsck before the resize which pass sucessfully.

I added

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
******* }

to /etc/mke2fs.conf

and run resize2fs and got the same error


_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

08-05-2012 12:56 PM

resize too large
 
> [ ... ] 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.

[ ... ]

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

08-06-2012 10:49 PM

resize too large
 
>> [ ... ] 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...

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users


All times are GMT. The time now is 08:31 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.