Grew RAID5 cant grow filesystem, only spare?

    • OMV 3.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Grew RAID5 cant grow filesystem, only spare?

      Hello,
      I added a drive to my RAID5, and I hit the "Grow" button. It only added it as a spare, cant really expand my file system. Any thoughts?

      Source Code

      1. Update Time : Wed Apr 12 12:08:56 2017
      2. State : clean
      3. Active Devices : 4
      4. Working Devices : 5
      5. Failed Devices : 0
      6. Spare Devices : 1
      7. Layout : left-symmetric
      8. Chunk Size : 512K
      9. Name : nas:raid5
      10. UUID : b286e9a0:429fbb83:4c6996b0:f10becad
      11. Events : 28921
      12. Number Major Minor RaidDevice State
      13. 5 8 32 0 active sync /dev/sdc
      14. 7 8 48 1 active sync /dev/sdd
      15. 6 8 16 2 active sync /dev/sdb
      16. 4 8 64 3 active sync /dev/sde
      17. 8 8 80 - spare /dev/sdf
      Display All
    • blindguy wrote:

      Did you ever figure this out? I'm having the same exact problem.

      I can't find a check box 'add as spare' or anything


      First, to add a disk to a RAID array, under "Physical Disks", it must first be "wiped".
      Then, to add the disk to an array as a spare, in "RAID Management", click on the array line and the "grow" button.
      If you have a free wiped physical disk, it shows up. Check the box to add it. Now, under RAID management, "Details", it shows up as a spare.
      It will remain a spare until a disk in the RAID array fails.
      (This does not apply to a striped RAID 0 set up. One failure there and it's over.)

      I have OMV set up in a virtual machine so I can create numerous RAID array scenarios. I've experimented with RAID 1 and 5 arrays degrading them by failing drives, adding disks as spares, doing recovery's etc. While I've used the "Grow" button under RAID management to add drives as spares, it doesn't grow the actual capacity of the array. If I add 2 drives, I get 2 spares. I've even built RAID 1 arrays with 2EA 10GIG drives, populated the array with data, failed disks one at at time, and replaced them one at at time with 20GiG drives. After that process, I have yet to use the "GROW" button, in "File Systems", to successfully enlarge the file system to use the extra capacity.

      It could have something to do with how Virtual Hard Drives are created / structured in a Virtual machine that may be different from physical hard drives. I don't know for sure. In any case, from these tests, it appears that "Grow" button in the files systems menu may be intended for other purposes.

      Note that ZFS pools and BTRFS can grow their files systems in various RAID configurations. On the other hand ZFS and, to a lesser degree, BTRFS have learning curves associated with them. Lastly, there are a few other possibilities in OMV that can grow disk capacity under one device name or, at least, give that appearance. UFS is one example.

      (Unless someone on the forum can provide a missing detail, or something more specific, the above are my observations on the topic.)

      Hope this helps.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
    • Did all that stuff and wiped the drive and still no luck.

      I have used OMV for many years and over the years I have grown my RAID by using the Grow button.

      When I add the drive, OMV even pops up a button that says 'After the RAID has been grown you can resize the containing file system' but the RAID is never grown it is added as a spare.

      You used to be able to see the progress % as it was rebuilding with the new drive. Now adding a new drive as a spare seems to take 12 seconds.

      I think something in OMV has changed.
      NAS Details: New Server Build
    • You may be right. When I was testing, I thought "grow" would do as you suggest, particularly in a RIAD1 set where both were replaced with larger disks. I even went to the point of trying to use Gparted, in the RAID1 array, to expand dev/md0. When I did it appeared that all space was allocated (even if 50% was unused). I also got an error about the Superblock which might have had something to do with the way Virtual Box creates virtual hard drives. I can't verify it, either way, because I simply don't have that many physical drives or the hardware to connect them.

      Humm, maybe I'll load up an earlier version of OMV to check it out.

      What version level allowed you to "grow" an array?

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
    • Noob alert input.... :) what if the "grow" option in v3 is being implemented as expand would this not explain why the additional drive is being added as a spare, expand being 'increasing drive capacity by using larger drives within the array'

      I'll go sit in the corner if I'm talking a load of tosh.
      Raid is not a backup! Would you go skydiving without a parachute?
    • geaves wrote:

      Noob alert input.... :) what if the "grow" option in v3 is being implemented as expand would this not explain why the additional drive is being added as a spare, expand being 'increasing drive capacity by using larger drives within the array'

      I'll go sit in the corner if I'm talking a load of tosh.
      This is not a NOOB thing,, but,, being a NOOB myself,, I might not be able to recognize a NOOB remark 8| ...
      (But the Flashing Red Tex screen thing... :whistling: )
      __________________________________________________________

      With a nod toward Blindguy's experience in the matter; your note is legitimate "speculation" among, shall we say, "newbies". (That's important - when speculating - make sure to state it. We don't want to lead anyone down the garden path.)

      On the other hand, since nothing is "broken" in OMV per say, this is an issue I wouldn't bother the moderators with unless they decided to chime in on their own. (They're already jumping through hoops.)

      Looking at it from another angle, Blindguy has been running OMV for a good while. Since virtualization doesn't "exactly" replicate physical hardware, I can't come up with or verify a work around (like using Gparted on a RAID1 array.) As it seems, something in earlier versions may have been different. Alternately, something in later versions may have been changed and there may be good reason(s) for it.

      I went looking for command line possibilities among the various Linux errata pages and found the following from 2010:
      (I highly recommend that no one actually tries this.)
      mdadm --add /dev/md0 /dev/sde1
      mdadm --grow /dev/md0 --raid-devices=4

      Here's the link - > Grow RAID 5 Read into the tread a bit. **It seems there are real risks associated where large drives are concerned. This may be why this feature was discontinued in OMV.**

      I'll give these command lines a try in a virtual machine, with drives populated with data, and see what happens. It's probably going to break OMV's GUI. That's the problem with doing certain operations from the CLI. OMV may not be aware of them.

      In any case, being able to chose to "expand" a RAID5 array, after the initial build, would be a great feature. But with today's stupendous sized drives, it may not be practical anymore.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
    • I actually found this which is what started me thinking about 'growing' and 'expanding' I have noticed with linux that some things are specific...like case sensitivity, get it wrong and it doesn't work.

      According to Oxford English Dictionary;

      expand; to increase in size, number
      grow; to increase in size or amount

      So taking that as literal the 'grow' on the raid option; to grow the amount of space, what you actually want to achieve is to expand it.....however, the linux interpretation may be different ^^
      Raid is not a backup! Would you go skydiving without a parachute?

      The post was edited 2 times, last by geaves ().

    • geaves wrote:

      I actually found this which is what started me thinking about 'growing' and 'expanding' I have noticed with linux that some things are specific...like case sensitivity, get it wrong and it doesn't work.
      Yep, the way Linux see's things, backup, is not BACKUP, is not BackUp. All are legitimate folder names that could live together. The same applies to passwords as well.

      Man, that article is just over the top. OMG,, Gparted from the command line. The possibilities for disaster, from a fat finger error, boggle the mind.
      ____________________________________________________________________________

      This is one of the reasons I don't use RAID, because it's not backup at all. At best, it adds some "fault tolerance". RAID provides some protection (not absolute) from the weakest link in a PC - it's greatest probability of failure - the "Hard Drive". But it provides zero protection from other possibilities like the loss of a MOBO, a power supply, or an event that takes out the entire RAID array (a virus is but one example). A power surge can take out the whole thing.
      (This is why I have "whole house" surge suppression on my power panel. I want to keep my electronics.)

      Instead, I use nested full data backups.
      Right now I have 1 active file server with network shares (with it's own, on board, full data backup drive). I have the Raspberry PI with OMV that is actively Rsyncing all changes to the server's data directories and a shared directory on one of my clients. (The R-PI is also imaging 2 clients with UrBackup.) The R-PI sync's the file server shares once a week. Where the R-Pi is concerned, I have full boot drive backups (SD cards) and, since it's cheap at $29 a pop, I have a hardware spare for the PI as well.
      In this scenario, the weak links are, both are on 24x7 (could be zapped in a power surge) and the drives in both servers are still aging, leading to eventual failure.

      I'll note here that a hard drive can last a very l-o-n-g time, if it's not running 24 x 7 or spinning up everyday. They key is run a hard drive at least a few times a year, to keep the spindle bearings lubed and prevent them from drying out.

      With that noted, I have a 3rd server that's "cold", or off. I fire it up once every few months, sync it to the online server, and shut it down. It's about 12 years old now and it's been hop scotching through time.

      All three of the above are completely independent of each other and any one of them could be used to restore my "stuff". As a result of having true backup, I have data files that date back to Windows 95.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
    • flmaxey wrote:

      This is one of the reasons I don't use RAID, because it's not backup at all. At best, it adds some "fault tolerance". RAID provides some protection (not absolute) from the weakest link in a PC - it's greatest probability of failure - the "Hard Drive". But it provides zero protection from other possibilities like the loss of a MOBO, a power supply, or an event that takes out the entire RAID array (a virus is but one example). A power surge can take out the whole thing.
      That's just made me feel a lot better, :P

      flmaxey wrote:

      Instead, I use nested full data backups.
      I'm not even gonna ask what that is :/
      Raid is not a backup! Would you go skydiving without a parachute?
    • (Maybe I could have picked a better term.)
      When I say "nested", I mean each platform is physically seperate and independent of the others. They're linked but each represents a level of backup that is separated by "time". With a cold backup, I can go back in time before a serious virus infection for example. The cold backup is also protection from a voltage surge. When we finish our move, I plan to move the cold server backup out to a shed, so all of them are not under one roof. (Fire, leaking roof, busted pipe?)

      As you might imagine, I used to noodle this stuff through at work, back in the day. If one wants IRON CLAD backup, I it should be done in 3 levels with one of them being off site. The R-PI and OMV makes that goal easy and inexpensive. I have a 4TB backup for about $160, that runs on 15 watts. That's hard to be beat.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
    • flmaxey wrote:

      The R-PI and OMV makes that goal easy and inexpensive. I have a 4TB backup for about $160, that runs on 15 watts. That's hard to be beat.
      Ah!! now you have my interest, because I have wondering whether to look at Pi + USB backup......hopefully the school I do work for is going to agree to a wireless upgrade.....if they do then one of 1Gb switches will not be required ;) (I've only got 10/100 at home)
      Raid is not a backup! Would you go skydiving without a parachute?
    • My R-PI rig consists of what is in my signature, below, complete with prices. (In USD.) But the R-PI family is limited to 100MBS.

      If you want something that's faster, but still economical, OMV has ready made SD card images for the Odroid-UX4. The UX4 is about $50 more but it's much faster, has 2GB ram versus 1GB on an R-PI, 1 GB net.int. versus 100 MBS, USB3.0 versus USB 2.0. On the other side of it, the R-PI 3 has built in wireless - the Odriod doesn't. Here's a comparison. Odriod UX4 ver R-PI 3

      I'm running a 4TB WD passport which draws its' power from the R-PI USB port. It's a shame I'm limited to USB2 on the R-PI. The passport supports USB3 which is a lot faster. But, I have no complains.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk

      The post was edited 1 time, last by flmaxey: - ().

    • flmaxey wrote:

      My R-PI rig consists of what is in my signature, below, complete with prices. (In USD.) But the R-PI family is limited to 100MBS.

      If you want something that's faster, but still economical, OMV has ready made SD card images for the Odroid-UX4. The UX4 is about $50 more but it's much faster, has 2GB ram versus 1GB on an R-PI, 1 GB net.int. versus 100 MBS, USB3.0 versus USB 2.0. On the other side of it, the R-PI 3 has built in wireless - the Odriod doesn't. Here's a comparison. Odriod UX4 ver R-PI 3

      I'm running a 4TB WD passport which draws its' power from the R-PI USB port. It's a shame I'm limited to USB2 on the R-PI. The passport supports USB3 which is a lot faster. But, I have no complains.
      We should move this to off topic really we're diversifying from the original OP's thread for which I apologise, I'll work out how to paste the link.
      Raid is not a backup! Would you go skydiving without a parachute?
    • (Sorry about getting off the tread topic.)

      So, to be sure that I understand exactly what you did.
      (After you confirmed the "grow button" worked in a OMV 2.1 VM.)

      1. In your 2.1 build, you physically added a drive to PC.
      - At that point, was the drive automatically added as a spare in your RAID5 array? (Yes / No?)
      (OR)
      2. When you clicked on the "grow" button (from what you said in your post) the drive was integrated into the array (not as a spare) and the array rebuilt to include the new drive.
      - If #2, above, is what happens when clicking on the "grow button, is there some other provision to add a drive as a spare?
      ______________________________________________

      In any case, it's a curious change of behavior between versions that, hopefully, one of the moderators / programmers will look at.
      ______________________________________________

      I've been out of town, so I have yet to try the command line option for growing an array in 3.X. I'm curious, just to see what happens. I hope to get to it soon.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
    • flmaxey wrote:

      1. In your 2.1 build, you physically added a drive to PC.
      - At that point, was the drive automatically added as a spare in your RAID5 array? (Yes / No?)
      (OR)
      2. When you clicked on the "grow" button (from what you said in your post) the drive was integrated into the array (not as a spare) and the array rebuilt to include the new drive.
      - If #2, above, is what happens when clicking on the "grow button, is there some other provision to add a drive as a spare?

      1 - No, nothgin happened automatically. I had to press the button to grow and delected the new drive and it was NOT added as a spare it was added as an additional drive to the array

      2 - Yes when I clicked Grow the drive was added to the array as an additional drive, NOT a spare and the array rebuilt and included the new drive.

      I let it grow for about 24 hours and kept checking via cat /proc/mdstat and once it was complete I went to the filesystem tab and then press the button to resize the filesystem and that process took another hour or so and once I was done everythgin worked fine.
      NAS Details: New Server Build
    • In a VM of OMV 3.0.73

      ((In the VM, I used "fixed size" disks, versus dynamically sized disks.))
      _____________________________________________________________

      I started with 4 data drives.
      dev/sdb
      dev/sdc
      dev/sdd

      They were 5GB each and created a RAID5 array of just under 10GB.
      (I created a 4th 5GB drive, dev/sde, to add later.)

      I created a folder share, built a Samba share on top of that, and populated the array with a bit over 1GB of data to try to simulate something real world. All worked fine.

      Then I ran the following command lines to add a 4th drive, dev/sde, to the array and "grow" it.

      mdadm --add /dev/md0 /dev/sde
      mdadm --grow /dev/md0 --raid-devices=4

      ______________________________________________________________

      In the GUI, in RAID management dev/md0's state was "clean". After the above commands it changed to "clean/reshaping".
      (*As it seems these mdadm commands, from the command line, won't break OMV's GUI interface.*)

      Observations
      - During the "reshape", the share and it's files were available. (I played an MP3 from the share while the array was reshaping.)
      - While I didn't time it, integrating a 5GB drive took roughly 10 to 15 minutes in a VM which is not capable of 100% CPU utilization. (I'd assume that full access to the VM's host CPU or a faster physical CPU might do the job faster.) Regardless, if this scaled, using roughly 12 minutes for restripeing 5GB drives into 15GB, adding a 1TB drive to an array of 1TB drives would take a heck of a lot longer.

      At the end of the array reshape, the array was just a bit below 15GB.
      I went into <File systems>, clicked on "resize" and this operation ended with an ext4 at 14.69GB

      While the above probably wouldn't cover all situations or possibilities, adding a drive to a RAID5 array in this manner was straight forward and, seemingly, painless.

      As a last detail, I created one more 5GB disk, to see the result of the "add" command.
      I ran
      mdadm --add /dev/md0 /dev/sdf
      A 5GB hot spare was "added" to the array without affecting it's size.
      ___________________________________________________________________

      Given your experience in running RAID arrays in OMV 2.X, it's probably time to ask the moderators what has changed.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk

      The post was edited 1 time, last by flmaxey ().

    • I asked the question OMV 2 versus OMV 3 - Growing RAID 5, in a new thread. Here's to hoping one of the programmers, a moderator, or other subject matter expert takes a look.

      OMV 2 Versus OMV 3 - Growing RAID 5

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk