[Solved] Can't expand RAID over 16TB

durthu · 19. Dezember 2015

Hi,

i've use OMV since 1-2 years to built my own NAS. I have recently bought a 19" storage case (IPC 4U 4320 L) and i have installed OMV 2.1.

I have created a RAID5 and started with 3 x 4To hard drive. I have moved some files and data on my new NAS. After that, i added more hard drive one by one.
I have a problem after adding the sixth hard drive. I can't expand the filesystem because of an error and a limit of 16TB with filesystem created in 32bits.

here's the error message in the WebGUI

Code

Erreur #6000:
exception 'OMVException' with message 'Failed to grow the filesystem '/dev/md0': resize2fs 1.42.5 (29-Jul-2012)
resize2fs: New size too large to be expressed in 32 bits
' in /usr/share/openmediavault/engined/rpc/filesystemmgmt.inc:699
Stack trace:
#0 [internal function]: OMVRpcServiceFileSystemMgmt->resize(Array, Array)
#1 /usr/share/php/openmediavault/rpcservice.inc(125): call_user_func_array(Array, Array)
#2 /usr/share/php/openmediavault/rpc.inc(79): OMVRpcServiceAbstract->callMethod('resize', Array, Array)
#3 /usr/sbin/omv-engined(500): OMVRpc::exec('FileSystemMgmt', 'resize', Array, Array, 1)
#4 {main}

Code

$ uname -m
x86_64
$ uname -a
Linux Nargothrond 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u2 x86_64 GNU/Linux

In another thread, someone says that this problem/bug is resolved since OMV 1.8. I'm afraid there no solution for me.
Is there any solution ? Do i have to backup my data and recreate the RAID5 in another way ?

Thank for your help and sorry about my bad english...

subzero79 · 19. Dezember 2015

You'll have to backup your data and format the array again. There is no solution to bypass this without recreating the file system

durthu · 19. Dezember 2015

Ok.

How can i do to create the filesystem in 64bits ?
Can i do that with the WebGUI ? Do i hate to use the CLI ?

Can i remove the last hard drive i have added ? I only extend the array and can't expand the FS.

subzero79 · 19. Dezember 2015

Omv now includes the flag for new ext4 file systems.

you can check with dumpe2fs/dev/md0 after you format the array again

durthu · 19. Dezember 2015

Thank you for the support and to answer very fast.

I don't understand why this happen again. In another thread, it says that it's a bug solved since OMV 1.8.

I've installed my new server last week with the last OMV. I suppose that i have to create the array in CLI or i will be in the same situation as now, right ?

subzero79 · 20. Dezember 2015

Zitat von durthu

I don't understand why this happen again. In another thread, it says that it's a bug solved since OMV 1.8.

I mean the problem was that the mkfs.ext4 script shipped by default in debian did not put the 64bit flag in drives or arrays smaller than 16TB.
This was solved by forcing the flag no matter what size the drive was.
If the flag wasn't added at fs creation you cannot modify it thus expand the fs.

So to be clear did you format your array last week with latest omv?

durthu · 20. Dezember 2015

Yes i installed OMV 2.1 the 6th or the 7th of decembre 2015.

This is what i see in the webGUI :

subzero79 · 20. Dezember 2015

But was the array formated on that date also? I mean it didn't come from another system

durthu · 20. Dezember 2015

Yes, i created the array when i build the server the 6th or 7th of december.

Do you need more information from CLI ?

subzero79 · 20. Dezember 2015

Please post

dumpe2fs -h /dev/md0

durthu · 20. Dezember 2015

this don't work...

Code

-dash: 2: dumpe2fs: not found

ryecoaaron · 20. Dezember 2015

Did you try the command as root?

durthu · 20. Dezember 2015

no ... but you're right, i have to use the command as root.
Here is the result :

Code

root@Nargothrond:~# dumpe2fs -h /dev/md0
dumpe2fs 1.42.5 (29-Jul-2012)
Filesystem volume name:   RAIDNARGOTHROND
Last mounted on:          /media/9a2c56c0-74bc-4704-ba92-ce46a4bd0f43
Filesystem UUID:          9a2c56c0-74bc-4704-ba92-ce46a4bd0f43
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:              488361984
Block count:              3906887168
Reserved block count:     0
Free blocks:              1942200230
Free inodes:              488343246
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      93
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         4096
Inode blocks per group:   256
RAID stride:              128
RAID stripe width:        256
Flex block group size:    16
Filesystem created:       Sun Dec  6 11:28:33 2015
Last mount time:          Fri Dec 18 17:27:01 2015
Last write time:          Fri Dec 18 17:27:01 2015
Mount count:              9
Maximum mount count:      -1
Last checked:             Sun Dec  6 11:28:33 2015
Check interval:           0 (<none>)
Lifetime writes:          7521 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:      60b31103-5f87-4ae1-be6b-f395069466c3
Journal backup:           inode blocks
Fonctionalités du journal :  journal_incompat_revoke
Taille du journal :         128M
Longueur du journal :      32768
Séquence du journal :      0x000154d7
Début du journal :         1

Alles anzeigen

subzero79 · 20. Dezember 2015

why are do you have dash there? are you accessing as root?

please type manually the command in terminal as root

subzero79 · 20. Dezember 2015

Seems ok to me, the flag is there, does the array report the new size?

cat /proc/mdstat with the new disk added

durthu · 20. Dezember 2015

Code

root@Nargothrond:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdg[5] sdc[0] sdf[4] sdb[3] sde[2] sdd[1]
      19534435840 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]

unused devices: <none>

subzero79 · 20. Dezember 2015

I think we missed a point in this bug, is that probably the current e2fsprogs shipped with debian does not allow the resize to 16TB because is too old.

What do you think @ryecoaaron ?

My guess is you'll have to boot systemrescuecd or gparted to resize the FS. But is ok, at least the flag is there so you shouldn't have problems.

ryecoaaron · 20. Dezember 2015

I don't remember now but I am pretty sure resize was the problem but maybe mkfs too. I would try the systemrescuecd route.

durthu · 20. Dezember 2015

Thanks,

i will try to resize with systemrescueCD tomorrow (i'm at work since tomorrow morning).

I'll let you know !!

durthu · 28. Dezember 2015

Hi everyone !!

i've just tried the systemrescueCD solution and it's work !!

I boot the NAS with systemrescueCD and launch a graphic session. Gparted resize succesfully the filesystem.

Will i have to do this way after each harddrive i will add ?

Jetzt mitmachen!