Linux ext4 development ()

Arne Hüggenberg | 29 Jul 2012 17:24

Picon

resize2fs > 16TB questions

Hello List,

im trying to resize a ext4 fs to > 16TB.

Having had a look at the e2fsprogs 1.42.x release notes i thought that, with the online resize ioctl having
been merged in Kernel 3.3, this should be possible.

But so far i have had no success achieving this:

~ # uname -a
Linux 3.3.8-gentoo #1 SMP Fri Jul 27 16:13:25 CEST 2012 x86_64 Intel(R) Xeon(R) CPU E5620  <at>  2.40GHz
GenuineIntel GNU/Linux

~ # tune2fs -l /dev/vg0/lvol1
tune2fs 1.42.4 (12-June-2012)
Filesystem volume name:   <none>
Last mounted on:          /home/filestore_extern_1
Filesystem UUID:          8fba4f1b-5311-4c9b-b8bf-def4957dc1bd
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent
64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              521011200
Block count:              4168089600
Reserved block count:     191127425

(Continue reading)

Andreas Dilger | 29 Jul 2012 18:11

Re: resize2fs > 16TB questions

On 2012-07-29, at 8:24, Arne Hüggenberg <hueggenberg <at> sportsandbytes.de> wrote:
> 
> im trying to resize a ext4 fs to > 16TB.

Unfortunately, this is not possible today without advance planning.  There are some structures on disk
(group descriptors) that need to be larger for 64-bit filesystems. 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 group descriptor size, but that isn't possible
today. 

> Having had a look at the e2fsprogs 1.42.x release notes i thought that, with the online resize ioctl having
been merged in Kernel 3.3, this should be possible.
> 
> But so far i have had no success achieving this:
> 
> ~ # uname -a
> Linux 3.3.8-gentoo #1 SMP Fri Jul 27 16:13:25 CEST 2012 x86_64 Intel(R) Xeon(R) CPU E5620  <at>  2.40GHz
GenuineIntel GNU/Linux
> 
> ~ # tune2fs -l /dev/vg0/lvol1
> tune2fs 1.42.4 (12-June-2012)
> Filesystem volume name:   <none>
> Last mounted on:          /home/filestore_extern_1
> Filesystem UUID:          8fba4f1b-5311-4c9b-b8bf-def4957dc1bd
> Filesystem magic number:  0xEF53

(Continue reading)

Arne Hüggenberg | 29 Jul 2012 18:46

Picon

Re: resize2fs > 16TB questions


On Jul 29, 2012, at 6:11 PM, Andreas Dilger wrote:

> On 2012-07-29, at 8:24, Arne Hüggenberg <hueggenberg <at> sportsandbytes.de> wrote:
>> 
>> im trying to resize a ext4 fs to > 16TB.
> 
> Unfortunately, this is not possible today without advance planning.  There are some structures on disk
(group descriptors) that need to be larger for 64-bit filesystems. 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.

I have no idea what the overhead for 64byte group descriptors is, but with LVM Setups becoming more common
and enabling incremental storage increases over a timeframe of several years, maybe 1TB filesystems
should be cutoff.

> It might also be possible to modify resize2fs to change the group descriptor size, but that isn't possible
today. 
> 
>> Having had a look at the e2fsprogs 1.42.x release notes i thought that, with the online resize ioctl
having been merged in Kernel 3.3, this should be possible.
>> 
>> But so far i have had no success achieving this:
>> 
>> ~ # uname -a
>> Linux 3.3.8-gentoo #1 SMP Fri Jul 27 16:13:25 CEST 2012 x86_64 Intel(R) Xeon(R) CPU E5620  <at>  2.40GHz
GenuineIntel GNU/Linux

(Continue reading)

Andreas Dilger | 29 Jul 2012 20:30

Re: resize2fs > 16TB questions


On 2012-07-29, at 9:46, Arne Hüggenberg <hueggenberg <at> sportsandbytes.de> wrote:
> On Jul 29, 2012, at 6:11 PM, Andreas Dilger wrote:
> 
>> On 2012-07-29, at 8:24, Arne Hüggenberg <hueggenberg <at> sportsandbytes.de> wrote:
>>> 
>>> im trying to resize a ext4 fs to > 16TB.
>> 
>> Unfortunately, this is not possible today without advance planning.  There are some structures on disk
(group descriptors) that need to be larger for 64-bit filesystems. 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.
> 
> I have no idea what the overhead for 64byte group descriptors is, but with LVM Setups becoming more common
and enabling incremental storage increases over a timeframe of several years, maybe 1TB filesystems
should be cutoff.

The overhead is relatively low. 

>> It might also be possible to modify resize2fs to change the group descriptor size, but that isn't
possible today. 
>> 
>>> Having had a look at the e2fsprogs 1.42.x release notes i thought that, with the online resize ioctl
having been merged in Kernel 3.3, this should be possible.
>>> 
>>> But so far i have had no success achieving this:
>>>

(Continue reading)

Arne Hüggenberg | 29 Jul 2012 21:08

Picon

Re: resize2fs > 16TB questions


On Jul 29, 2012, at 8:30 PM, Andreas Dilger wrote:

> 
> On 2012-07-29, at 9:46, Arne Hüggenberg <hueggenberg <at> sportsandbytes.de> wrote:
>> On Jul 29, 2012, at 6:11 PM, Andreas Dilger wrote:
>> 
>>> On 2012-07-29, at 8:24, Arne Hüggenberg <hueggenberg <at> sportsandbytes.de> wrote:
>>>> 
>>>> im trying to resize a ext4 fs to > 16TB.
>>> 
>>> Unfortunately, this is not possible today without advance planning.  There are some structures on disk
(group descriptors) that need to be larger for 64-bit filesystems. 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.
>> 
>> I have no idea what the overhead for 64byte group descriptors is, but with LVM Setups becoming more common
and enabling incremental storage increases over a timeframe of several years, maybe 1TB filesystems
should be cutoff.
> 
> The overhead is relatively low. 
> 
>>> It might also be possible to modify resize2fs to change the group descriptor size, but that isn't
possible today. 
>>> 
>>>> Having had a look at the e2fsprogs 1.42.x release notes i thought that, with the online resize ioctl
having been merged in Kernel 3.3, this should be possible.

(Continue reading)

Andreas Dilger | 2 Aug 2012 22:15

Re: resize2fs > 16TB questions

On 2012-07-29, at 12:08, Arne Hüggenberg <hueggenberg <at> sportsandbytes.de> wrote:

> On Jul 29, 2012, at 8:30 PM, Andreas Dilger wrote:
>>>> Unfortunately, the group descriptor size is not printed.  
>>> 
>>> how can i get the group descriptor size?
>> 
>> Possibly with "debugfs stats"?
> 
> ~ # debugfs /dev/vg0/lvol1 
> debugfs 1.42.4 (12-June-2012)
> debugfs:  stats
> debugfs:  stats
> 
> Filesystem volume name:   <none>
> Last mounted on:          /home/filestore_extern_1
> Filesystem UUID:          8fba4f1b-5311-4c9b-b8bf-def4957dc1bd
> Filesystem magic number:  0xEF53
> Filesystem revision #:    1 (dynamic)
> 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
> Filesystem flags:         signed_directory_hash 
> Default mount options:    user_xattr acl
> Filesystem state:         clean
> Errors behavior:          Continue
> Filesystem OS type:       Linux
> Inode count:              521011200
> Block count:              4168089600
> Reserved block count:     191127425
> Free blocks:              2162482117

(Continue reading)

Arne Hüggenberg | 29 Jul 2012 18:48

Picon

Re: resize2fs > 16TB questions


On Jul 29, 2012, at 6:11 PM, Andreas Dilger wrote:
>> ~ # tune2fs -l /dev/vg0/lvol1
>> tune2fs 1.42.4 (12-June-2012)
>> Filesystem volume name:   <none>
>> Last mounted on:          /home/filestore_extern_1
>> Filesystem UUID:          8fba4f1b-5311-4c9b-b8bf-def4957dc1bd
>> Filesystem magic number:  0xEF53
>> Filesystem revision #:    1 (dynamic)
>> Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent
64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
> 
> Was the filesystem formatted with the 64bit option, or was this enabled after formatting time?  This puts
my earlier comment in doubt. 

Can it even be changed after format time? I tried to do that to save a backup/restore cycle, but tune2fs would
not let me?

--

-- 
Arne Hüggenberg
System Administrator
_______________________
Sports & Bytes GmbH
Rheinlanddamm 207-209
D-44137 Dortmund
Tel: + 49-231-9020-655
Fax: + 49-231-9020-989

Geschäftsführer: Thomas Treß

(Continue reading)

Return

Return to gmane.comp.file-systems.ext4.

Advertisement

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane