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 @ 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
Free blocks: 2195165566
Free inodes: 520937830
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 60
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 4096
Inode blocks per group: 256
RAID stride: 16
RAID stripe width: 160
Flex block group size: 16
Filesystem created: Fri Jul 27 17:16:24 2012
Last mount time: Sun Jul 29 15:22:23 2012
Last write time: Sun Jul 29 15:22:23 2012
Mount count: 6
Maximum mount count: -1
Last checked: Fri Jul 27 17:16:24 2012
Check interval: 0 (<none>)
Lifetime writes: 7485 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: ef2ec72a-750b-4822-bd8d-9117faadeaee
Journal backup: inode blocks
~ # vgdisplay
--- Volume group ---
VG Name vg0
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 2
Act PV 2
VG Size 18.18 TiB
PE Size 4.00 MiB
Total PE 4766718
Alloc PE / Size 4766718 / 18.18 TiB
Free PE / Size 0 / 0
VG UUID q6p5LG-pi1P-pAcI-fSsv-vFI7-6sAA-eabaBH
~ # lvdisplay
--- Logical volume ---
LV Name /dev/vg0/lvol1
VG Name vg0
LV UUID 7OF1do-HqZD-FGSN-chJF-rPYC-x1Ty-vGCZlc
LV Write Access read/write
LV Status available
# open 1
LV Size 18.18 TiB
Current LE 4766718
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:1
~ # resize2fs /dev/vg0/lvol1
resize2fs 1.42.4 (12-June-2012)
resize2fs: New size too large to be expressed in 32 bits
Any advice on how to proceed would be welcome.
Regards,
Arne
On 2012-07-29, at 8:24, Arne Hüggenberg <[email protected]> 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 @ 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
Was the filesystem formatted with the 64bit option, or was this enabled after formatting time? This puts my earlier comment in doubt.
> 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: 2195165566
> Free inodes: 520937830
> First block: 0
> Block size: 4096
> Fragment size: 4096
> Reserved GDT blocks: 60
> Blocks per group: 32768
> Fragments per group: 32768
> Inodes per group: 4096
> Inode blocks per group: 256
> RAID stride: 16
> RAID stripe width: 160
> Flex block group size: 16
> Filesystem created: Fri Jul 27 17:16:24 2012
> Last mount time: Sun Jul 29 15:22:23 2012
> Last write time: Sun Jul 29 15:22:23 2012
> Mount count: 6
> Maximum mount count: -1
> Last checked: Fri Jul 27 17:16:24 2012
> Check interval: 0 (<none>)
> Lifetime writes: 7485 GB
> Reserved blocks uid: 0 (user root)
> Reserved blocks gid: 0 (group root)
> First inode: 11
> Inode size: 256
> Required extra isize: 28
> Desired extra isize: 28
> Journal inode: 8
> Default directory hash: half_md4
> Directory Hash Seed: ef2ec72a-750b-4822-bd8d-9117faadeaee
> Journal backup: inode blocks
Unfortunately, the group descriptor size is not printed.
> ~ # vgdisplay
> --- Volume group ---
> VG Name vg0
> System ID
> Format lvm2
> Metadata Areas 2
> Metadata Sequence No 4
> VG Access read/write
> VG Status resizable
> MAX LV 0
> Cur LV 1
> Open LV 1
> Max PV 0
> Cur PV 2
> Act PV 2
> VG Size 18.18 TiB
> PE Size 4.00 MiB
> Total PE 4766718
> Alloc PE / Size 4766718 / 18.18 TiB
> Free PE / Size 0 / 0
> VG UUID q6p5LG-pi1P-pAcI-fSsv-vFI7-6sAA-eabaBH
>
> ~ # lvdisplay
> --- Logical volume ---
> LV Name /dev/vg0/lvol1
> VG Name vg0
> LV UUID 7OF1do-HqZD-FGSN-chJF-rPYC-x1Ty-vGCZlc
> LV Write Access read/write
> LV Status available
> # open 1
> LV Size 18.18 TiB
> Current LE 4766718
> Segments 2
> Allocation inherit
> Read ahead sectors auto
> - currently set to 256
> Block device 254:1
>
> ~ # resize2fs /dev/vg0/lvol1
> resize2fs 1.42.4 (12-June-2012)
> resize2fs: New size too large to be expressed in 32 bits
This may just be a hard-coded check built into resize2fs, but may be over-zealous of the filesystem was formatted with -O 64bit.
> Any advice on how to proceed would be welcome.
>
> Regards,
> Arne
>
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Jul 29, 2012, at 6:11 PM, Andreas Dilger wrote:
> On 2012-07-29, at 8:24, Arne H?ggenberg <[email protected]> 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 @ 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
>
> Was the filesystem formatted with the 64bit option, or was this enabled after formatting time? This puts my earlier comment in doubt.
the filesystem was formatted with
from mke2fs.conf:
ext4 = {
features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize,64bit
auto_64-bit_support = 1
inode_size = 256
}
>
>> 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: 2195165566
>> Free inodes: 520937830
>> First block: 0
>> Block size: 4096
>> Fragment size: 4096
>> Reserved GDT blocks: 60
>> Blocks per group: 32768
>> Fragments per group: 32768
>> Inodes per group: 4096
>> Inode blocks per group: 256
>> RAID stride: 16
>> RAID stripe width: 160
>> Flex block group size: 16
>> Filesystem created: Fri Jul 27 17:16:24 2012
>> Last mount time: Sun Jul 29 15:22:23 2012
>> Last write time: Sun Jul 29 15:22:23 2012
>> Mount count: 6
>> Maximum mount count: -1
>> Last checked: Fri Jul 27 17:16:24 2012
>> Check interval: 0 (<none>)
>> Lifetime writes: 7485 GB
>> Reserved blocks uid: 0 (user root)
>> Reserved blocks gid: 0 (group root)
>> First inode: 11
>> Inode size: 256
>> Required extra isize: 28
>> Desired extra isize: 28
>> Journal inode: 8
>> Default directory hash: half_md4
>> Directory Hash Seed: ef2ec72a-750b-4822-bd8d-9117faadeaee
>> Journal backup: inode blocks
>
> Unfortunately, the group descriptor size is not printed.
how can i get the group descriptor size?
>>
>>
>> ~ # resize2fs /dev/vg0/lvol1
>> resize2fs 1.42.4 (12-June-2012)
>> resize2fs: New size too large to be expressed in 32 bits
>
> This may just be a hard-coded check built into resize2fs, but may be over-zealous of the filesystem was formatted with -O 64bit.
>
>> Any advice on how to proceed would be welcome.
>>
>> Regards,
>> Arne
>>
>>
Regards,
Arne-
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?
Sitz und Handelsregister: Dortmund, HRB 14983
Finanzamt Dortmund - West
Steuer-Nr.: 314/5700/1299
USt-Id. Nr.: DE 208084540
On 2012-07-29, at 9:46, Arne Hüggenberg <[email protected]> wrote:
> On Jul 29, 2012, at 6:11 PM, Andreas Dilger wrote:
>
>> On 2012-07-29, at 8:24, Arne Hüggenberg <[email protected]> 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:
>>>
>>> ~ # 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 @ 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
>>
>> Was the filesystem formatted with the 64bit option, or was this enabled after formatting time? This puts my earlier comment in doubt.
>
> the filesystem was formatted with
> from mke2fs.conf:
>
> ext4 = {
> features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize,64bit
> auto_64-bit_support = 1
> inode_size = 256
> }
I think the "auto_64-bit_support" means that 64-byte group descriptors are not enabled for filesystems below 16TB.
>>> 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: 2195165566
>>> Free inodes: 520937830
>>> First block: 0
>>> Block size: 4096
>>> Fragment size: 4096
>>> Reserved GDT blocks: 60
>>> Blocks per group: 32768
>>> Fragments per group: 32768
>>> Inodes per group: 4096
>>> Inode blocks per group: 256
>>> RAID stride: 16
>>> RAID stripe width: 160
>>> Flex block group size: 16
>>> Filesystem created: Fri Jul 27 17:16:24 2012
>>> Last mount time: Sun Jul 29 15:22:23 2012
>>> Last write time: Sun Jul 29 15:22:23 2012
>>> Mount count: 6
>>> Maximum mount count: -1
>>> Last checked: Fri Jul 27 17:16:24 2012
>>> Check interval: 0 (<none>)
>>> Lifetime writes: 7485 GB
>>> Reserved blocks uid: 0 (user root)
>>> Reserved blocks gid: 0 (group root)
>>> First inode: 11
>>> Inode size: 256
>>> Required extra isize: 28
>>> Desired extra isize: 28
>>> Journal inode: 8
>>> Default directory hash: half_md4
>>> Directory Hash Seed: ef2ec72a-750b-4822-bd8d-9117faadeaee
>>> Journal backup: inode blocks
>>
>> Unfortunately, the group descriptor size is not printed.
>
> how can i get the group descriptor size?
Possibly with "debugfs stats"?
Cheers, Andreas
>>> ~ # resize2fs /dev/vg0/lvol1
>>> resize2fs 1.42.4 (12-June-2012)
>>> resize2fs: New size too large to be expressed in 32 bits
>>
>> This may just be a hard-coded check built into resize2fs, but may be over-zealous of the filesystem was formatted with -O 64bit.
>>
>>> Any advice on how to proceed would be welcome.
>>>
>>> Regards,
>>> Arne
>>>
>>>
>
> Regards,
> Arne
On Jul 29, 2012, at 8:30 PM, Andreas Dilger wrote:
>
> On 2012-07-29, at 9:46, Arne H?ggenberg <[email protected]> wrote:
>> On Jul 29, 2012, at 6:11 PM, Andreas Dilger wrote:
>>
>>> On 2012-07-29, at 8:24, Arne H?ggenberg <[email protected]> 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:
>>>>
>>>> ~ # 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 @ 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
>>>
>>> Was the filesystem formatted with the 64bit option, or was this enabled after formatting time? This puts my earlier comment in doubt.
>>
>> the filesystem was formatted with
>> from mke2fs.conf:
>>
>> ext4 = {
>> features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize,64bit
>> auto_64-bit_support = 1
>> inode_size = 256
>> }
>
> I think the "auto_64-bit_support" means that 64-byte group descriptors are not enabled for filesystems below 16TB.
>
>>>> 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: 2195165566
>>>> Free inodes: 520937830
>>>> First block: 0
>>>> Block size: 4096
>>>> Fragment size: 4096
>>>> Reserved GDT blocks: 60
>>>> Blocks per group: 32768
>>>> Fragments per group: 32768
>>>> Inodes per group: 4096
>>>> Inode blocks per group: 256
>>>> RAID stride: 16
>>>> RAID stripe width: 160
>>>> Flex block group size: 16
>>>> Filesystem created: Fri Jul 27 17:16:24 2012
>>>> Last mount time: Sun Jul 29 15:22:23 2012
>>>> Last write time: Sun Jul 29 15:22:23 2012
>>>> Mount count: 6
>>>> Maximum mount count: -1
>>>> Last checked: Fri Jul 27 17:16:24 2012
>>>> Check interval: 0 (<none>)
>>>> Lifetime writes: 7485 GB
>>>> Reserved blocks uid: 0 (user root)
>>>> Reserved blocks gid: 0 (group root)
>>>> First inode: 11
>>>> Inode size: 256
>>>> Required extra isize: 28
>>>> Desired extra isize: 28
>>>> Journal inode: 8
>>>> Default directory hash: half_md4
>>>> Directory Hash Seed: ef2ec72a-750b-4822-bd8d-9117faadeaee
>>>> Journal backup: inode blocks
>>>
>>> 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
Free inodes: 520936736
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 60
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 4096
Inode blocks per group: 256
RAID stride: 16
RAID stripe width: 160
Flex block group size: 16
Filesystem created: Fri Jul 27 17:16:24 2012
Last mount time: Sun Jul 29 15:22:23 2012
Last write time: Sun Jul 29 20:50:44 2012
Mount count: 6
Maximum mount count: -1
Last checked: Fri Jul 27 17:16:24 2012
Check interval: 0 (<none>)
Lifetime writes: 7662 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: ef2ec72a-750b-4822-bd8d-9117faadeaee
Journal backup: inode blocks
Directories: 6392
Group 0: block bitmap at 2049, inode bitmap at 2065, inode table at 2081
26585 free blocks, 4085 free inodes, 2 used directories, 4084 unused inodes
[Checksum 0x7d46]
Group 1: block bitmap at 2050, inode bitmap at 2066, inode table at 2337
4634 free blocks, 4096 free inodes, 0 used directories, 4096 unused inodes
[Inode not init, Checksum 0x97aa]
Group 2: block bitmap at 2051, inode bitmap at 2067, inode table at 2593
1020 free blocks, 4096 free inodes, 0 used directories, 4096 unused inodes
[Inode not init, Checksum 0x571f]
Group 3: block bitmap at 2052, inode bitmap at 2068, inode table at 2849
2047 free blocks, 4096 free inodes, 0 used directories, 4096 unused inodes
> Cheers, Andreas
>
>>>> ~ # resize2fs /dev/vg0/lvol1
>>>> resize2fs 1.42.4 (12-June-2012)
>>>> resize2fs: New size too large to be expressed in 32 bits
>>>
>>> This may just be a hard-coded check built into resize2fs, but may be over-zealous of the filesystem was formatted with -O 64bit.
>>>
>>>> Any advice on how to proceed would be welcome.
>>>>
>>>> Regards,
>>>> Arne
>>>>
>>>>
>>
>> Regards,
>> Arne
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Regards,
Arne
On 2012-07-29, at 12:08, Arne Hüggenberg <[email protected]> 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
> Free inodes: 520936736
> First block: 0
> Block size: 4096
> Fragment size: 4096
> Reserved GDT blocks: 60
> Blocks per group: 32768
> Fragments per group: 32768
> Inodes per group: 4096
> Inode blocks per group: 256
> RAID stride: 16
> RAID stripe width: 160
> Flex block group size: 16
> Filesystem created: Fri Jul 27 17:16:24 2012
> Last mount time: Sun Jul 29 15:22:23 2012
> Last write time: Sun Jul 29 20:50:44 2012
> Mount count: 6
> Maximum mount count: -1
> Last checked: Fri Jul 27 17:16:24 2012
> Check interval: 0 (<none>)
> Lifetime writes: 7662 GB
> Reserved blocks uid: 0 (user root)
> Reserved blocks gid: 0 (group root)
> First inode: 11
> Inode size: 256
> Required extra isize: 28
> Desired extra isize: 28
> Journal inode: 8
> Default directory hash: half_md4
> Directory Hash Seed: ef2ec72a-750b-4822-bd8d-9117faadeaee
> Journal backup: inode blocks
> Directories: 6392
> Group 0: block bitmap at 2049, inode bitmap at 2065, inode table at 2081
> 26585 free blocks, 4085 free inodes, 2 used directories, 4084 unused inodes
> [Checksum 0x7d46]
> Group 1: block bitmap at 2050, inode bitmap at 2066, inode table at 2337
> 4634 free blocks, 4096 free inodes, 0 used directories, 4096 unused inodes
> [Inode not init, Checksum 0x97aa]
> Group 2: block bitmap at 2051, inode bitmap at 2067, inode table at 2593
> 1020 free blocks, 4096 free inodes, 0 used directories, 4096 unused inodes
> [Inode not init, Checksum 0x571f]
> Group 3: block bitmap at 2052, inode bitmap at 2068, inode table at 2849
> 2047 free blocks, 4096 free inodes, 0 used directories, 4096 unused inodes
Surprisingly, the group descriptor size is also not printed here. Looking at the code in mke2fs, it appears the 64-byte size used for filesystems when the 64bit flag is set, regardless of what size the filesystem is, and there is no way to change it.
It looks like my theory is wrong, but I don't have access to a system to test this. Probably worthwhile to ask Yongqiang Yang (CC'd), who wrote the 64-bit resize code.
Cheers, Andreas-
On Thu, Aug 2, 2012 at 1:15 PM, Andreas Dilger <[email protected]> wrote:
>
> On 2012-07-29, at 12:08, Arne H?ggenberg <[email protected]> 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
> > Free inodes: 520936736
> > First block: 0
> > Block size: 4096
> > Fragment size: 4096
> > Reserved GDT blocks: 60
> > Blocks per group: 32768
> > Fragments per group: 32768
> > Inodes per group: 4096
> > Inode blocks per group: 256
> > RAID stride: 16
> > RAID stripe width: 160
> > Flex block group size: 16
> > Filesystem created: Fri Jul 27 17:16:24 2012
> > Last mount time: Sun Jul 29 15:22:23 2012
> > Last write time: Sun Jul 29 20:50:44 2012
> > Mount count: 6
> > Maximum mount count: -1
> > Last checked: Fri Jul 27 17:16:24 2012
> > Check interval: 0 (<none>)
> > Lifetime writes: 7662 GB
> > Reserved blocks uid: 0 (user root)
> > Reserved blocks gid: 0 (group root)
> > First inode: 11
> > Inode size: 256
> > Required extra isize: 28
> > Desired extra isize: 28
> > Journal inode: 8
> > Default directory hash: half_md4
> > Directory Hash Seed: ef2ec72a-750b-4822-bd8d-9117faadeaee
> > Journal backup: inode blocks
> > Directories: 6392
> > Group 0: block bitmap at 2049, inode bitmap at 2065, inode table at 2081
> > 26585 free blocks, 4085 free inodes, 2 used directories, 4084 unused inodes
> > [Checksum 0x7d46]
> > Group 1: block bitmap at 2050, inode bitmap at 2066, inode table at 2337
> > 4634 free blocks, 4096 free inodes, 0 used directories, 4096 unused inodes
> > [Inode not init, Checksum 0x97aa]
> > Group 2: block bitmap at 2051, inode bitmap at 2067, inode table at 2593
> > 1020 free blocks, 4096 free inodes, 0 used directories, 4096 unused inodes
> > [Inode not init, Checksum 0x571f]
> > Group 3: block bitmap at 2052, inode bitmap at 2068, inode table at 2849
> > 2047 free blocks, 4096 free inodes, 0 used directories, 4096 unused inodes
>
> Surprisingly, the group descriptor size is also not printed here. Looking at the code in mke2fs, it appears the 64-byte size used for filesystems when the 64bit flag is set, regardless of what size the filesystem is, and there is no way to change it.
>
> It looks like my theory is wrong, but I don't have access to a system to test this. Probably worthwhile to ask Yongqiang Yang (CC'd), who wrote the 64-bit resize code.
>
I had the same confusion 11 months ago, when the 64-bit resize
patchset was first posted, and I posted almost the same question here.
My understanding at the end of the mailing list discussion was that
you still cannot resize your filesystem beyond 16TB -- even if the
64bit flag is set -- and you may never be able to do so on that
filesystem because you are using resize_inode and not meta_bg. There
was a patchset posted on this list a few months ago by Yongquiang Yang
to do meta_bg expansion, but there hasn't been much action around it
from what I have seen (maybe for the 3.7 merge window?).
You can read on here:
http://permalink.gmane.org/gmane.comp.file-systems.ext4/27718
-Justin
In my memory, meta_bg is not allowed to set with resize_inode. So if
you want to use the patch, you need options
meta_bg,64bit,^resize_inode when mkfs. I am busy on other things, so
I am a way the patch for a while.
Yongqiang.
On Fri, Aug 3, 2012 at 4:57 AM, Justin Maggard <[email protected]> wrote:
> On Thu, Aug 2, 2012 at 1:15 PM, Andreas Dilger <[email protected]> wrote:
>>
>> On 2012-07-29, at 12:08, Arne H?ggenberg <[email protected]> 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
>> > Free inodes: 520936736
>> > First block: 0
>> > Block size: 4096
>> > Fragment size: 4096
>> > Reserved GDT blocks: 60
>> > Blocks per group: 32768
>> > Fragments per group: 32768
>> > Inodes per group: 4096
>> > Inode blocks per group: 256
>> > RAID stride: 16
>> > RAID stripe width: 160
>> > Flex block group size: 16
>> > Filesystem created: Fri Jul 27 17:16:24 2012
>> > Last mount time: Sun Jul 29 15:22:23 2012
>> > Last write time: Sun Jul 29 20:50:44 2012
>> > Mount count: 6
>> > Maximum mount count: -1
>> > Last checked: Fri Jul 27 17:16:24 2012
>> > Check interval: 0 (<none>)
>> > Lifetime writes: 7662 GB
>> > Reserved blocks uid: 0 (user root)
>> > Reserved blocks gid: 0 (group root)
>> > First inode: 11
>> > Inode size: 256
>> > Required extra isize: 28
>> > Desired extra isize: 28
>> > Journal inode: 8
>> > Default directory hash: half_md4
>> > Directory Hash Seed: ef2ec72a-750b-4822-bd8d-9117faadeaee
>> > Journal backup: inode blocks
>> > Directories: 6392
>> > Group 0: block bitmap at 2049, inode bitmap at 2065, inode table at 2081
>> > 26585 free blocks, 4085 free inodes, 2 used directories, 4084 unused inodes
>> > [Checksum 0x7d46]
>> > Group 1: block bitmap at 2050, inode bitmap at 2066, inode table at 2337
>> > 4634 free blocks, 4096 free inodes, 0 used directories, 4096 unused inodes
>> > [Inode not init, Checksum 0x97aa]
>> > Group 2: block bitmap at 2051, inode bitmap at 2067, inode table at 2593
>> > 1020 free blocks, 4096 free inodes, 0 used directories, 4096 unused inodes
>> > [Inode not init, Checksum 0x571f]
>> > Group 3: block bitmap at 2052, inode bitmap at 2068, inode table at 2849
>> > 2047 free blocks, 4096 free inodes, 0 used directories, 4096 unused inodes
>>
>> Surprisingly, the group descriptor size is also not printed here. Looking at the code in mke2fs, it appears the 64-byte size used for filesystems when the 64bit flag is set, regardless of what size the filesystem is, and there is no way to change it.
>>
>> It looks like my theory is wrong, but I don't have access to a system to test this. Probably worthwhile to ask Yongqiang Yang (CC'd), who wrote the 64-bit resize code.
>>
>
> I had the same confusion 11 months ago, when the 64-bit resize
> patchset was first posted, and I posted almost the same question here.
> My understanding at the end of the mailing list discussion was that
> you still cannot resize your filesystem beyond 16TB -- even if the
> 64bit flag is set -- and you may never be able to do so on that
> filesystem because you are using resize_inode and not meta_bg. There
> was a patchset posted on this list a few months ago by Yongquiang Yang
> to do meta_bg expansion, but there hasn't been much action around it
> from what I have seen (maybe for the 3.7 merge window?).
>
> You can read on here:
> http://permalink.gmane.org/gmane.comp.file-systems.ext4/27718
>
> -Justin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Wishes
Yongqiang Yang
On 2012-08-02, at 19:36, Yongqiang Yang <[email protected]> wrote:
> In my memory, meta_bg is not allowed to set with resize_inode. So if
> you want to use the patch, you need options
> meta_bg,64bit,^resize_inode when mkfs.
It is already default to disable resize_inode when 64bit is enabled, but possibly this is only some for filesystems over 16TB.
It might make sense to disable resize_inode when the filesystem is resized to 16TB by resize2fs.
> I am busy on other things, so
> I am a way the patch for a while.
>
> On Fri, Aug 3, 2012 at 4:57 AM, Justin Maggard <[email protected]> wrote:
>> On Thu, Aug 2, 2012 at 1:15 PM, Andreas Dilger <[email protected]> wrote:
>>>
>>> On 2012-07-29, at 12:08, Arne Hüggenberg <[email protected]> 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
>>>> Free inodes: 520936736
>>>> First block: 0
>>>> Block size: 4096
>>>> Fragment size: 4096
>>>> Reserved GDT blocks: 60
>>>> Blocks per group: 32768
>>>> Fragments per group: 32768
>>>> Inodes per group: 4096
>>>> Inode blocks per group: 256
>>>> RAID stride: 16
>>>> RAID stripe width: 160
>>>> Flex block group size: 16
>>>> Filesystem created: Fri Jul 27 17:16:24 2012
>>>> Last mount time: Sun Jul 29 15:22:23 2012
>>>> Last write time: Sun Jul 29 20:50:44 2012
>>>> Mount count: 6
>>>> Maximum mount count: -1
>>>> Last checked: Fri Jul 27 17:16:24 2012
>>>> Check interval: 0 (<none>)
>>>> Lifetime writes: 7662 GB
>>>> Reserved blocks uid: 0 (user root)
>>>> Reserved blocks gid: 0 (group root)
>>>> First inode: 11
>>>> Inode size: 256
>>>> Required extra isize: 28
>>>> Desired extra isize: 28
>>>> Journal inode: 8
>>>> Default directory hash: half_md4
>>>> Directory Hash Seed: ef2ec72a-750b-4822-bd8d-9117faadeaee
>>>> Journal backup: inode blocks
>>>> Directories: 6392
>>>> Group 0: block bitmap at 2049, inode bitmap at 2065, inode table at 2081
>>>> 26585 free blocks, 4085 free inodes, 2 used directories, 4084 unused inodes
>>>> [Checksum 0x7d46]
>>>> Group 1: block bitmap at 2050, inode bitmap at 2066, inode table at 2337
>>>> 4634 free blocks, 4096 free inodes, 0 used directories, 4096 unused inodes
>>>> [Inode not init, Checksum 0x97aa]
>>>> Group 2: block bitmap at 2051, inode bitmap at 2067, inode table at 2593
>>>> 1020 free blocks, 4096 free inodes, 0 used directories, 4096 unused inodes
>>>> [Inode not init, Checksum 0x571f]
>>>> Group 3: block bitmap at 2052, inode bitmap at 2068, inode table at 2849
>>>> 2047 free blocks, 4096 free inodes, 0 used directories, 4096 unused inodes
>>>
>>> Surprisingly, the group descriptor size is also not printed here. Looking at the code in mke2fs, it appears the 64-byte size used for filesystems when the 64bit flag is set, regardless of what size the filesystem is, and there is no way to change it.
>>>
>>> It looks like my theory is wrong, but I don't have access to a system to test this. Probably worthwhile to ask Yongqiang Yang (CC'd), who wrote the 64-bit resize code.
>>>
>>
>> I had the same confusion 11 months ago, when the 64-bit resize
>> patchset was first posted, and I posted almost the same question here.
>> My understanding at the end of the mailing list discussion was that
>> you still cannot resize your filesystem beyond 16TB -- even if the
>> 64bit flag is set -- and you may never be able to do so on that
>> filesystem because you are using resize_inode and not meta_bg. There
>> was a patchset posted on this list a few months ago by Yongquiang Yang
>> to do meta_bg expansion, but there hasn't been much action around it
>> from what I have seen (maybe for the 3.7 merge window?).
>>
>> You can read on here:
>> http://permalink.gmane.org/gmane.comp.file-systems.ext4/27718
>>
>> -Justin
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Best Wishes
> Yongqiang Yang