OMV 3.X versus OMV 2.X; "Growing" a RAID 5 array

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

    • OMV 3.X versus OMV 2.X; "Growing" a RAID 5 array

      (Per a forum user conversation in another thread) Grow RAID 5

      After testing RAID 5 scenarios in VM's of OMV 3.0.73, versus a real world platform running OMV 2.1:
      _______________________________________________________________________

      It seems that the behavior of the "Grow" button in <System>, <RAID Management> has changed between OMV versions 2.X and 3.X.

      Where the "Grow" button in OMV 2.1 triggers an array restrip operation that integrates a new drive, the "Grow" button in 3.X versions simply adds a drive to the array as a hot spare which is more in line with the mdadm --add command line.

      To integrate a disk into an OMV 3.x array (Grow it) it was necessary to do it from the command line (as follows).
      mdadm --grow /dev/md0 --raid-devices=4


      Perhaps there's a reason for the change?
      ______________________________________________________________________

      If restriping (or Growing) a RAID 5 array is to be supported in OMV 3.X , it makes sense to attach the CLI operation (mdadm --grow /dev/md0 --raid-devices=4) to the Grow button in RAID Management.
      Similarly, when adding a hot spare to an array, it would be more intuitive if a new GUI "Add" button is attached the CLI operation (mdadm --add /dev/md0 /dev/sde).

      Are we off base or are we missing something? In any case, any information or an explanation would be appreciated.


      Thanks
      Good backup takes the "drama" out of computing
      ____________________________________
      OMV 3.0.99 Erasmus
      ThinkServer TS140, 12GB ECC / 32GB USB3.0
      4TB SG+4TB TS ZFS mirror/ 3TB TS

      OMV 3.0.99 Erasmus - Rsync'ed Backup
      R-PI 2 $29 / 16GB SD Card $8 / Real Time Clock $1.86
      4TB WD My Passport $119
    • It's still outstanding but I've come to understand why. When it comes to growing an mdadm RAID array, users tend to "click" without contemplating the consequences and get in over their heads. Then, with a dead or dying array (usually without backup), they return to the forum after compounding the problem. Often, it's unsolvable.

      If you want to grow your array, you can find the command lines to do it here. - > mdadm RAID 5 - 3 disks to 4 disks

      If something goes wrong (that's not critical), here's a resource to recover your array.
      Recover array (There's good general reading at this site.)

      _______________________________________________________

      With the above noted - if you don't have a full backup of all the contents on your array, or at least the data that you can't afford to lose, don't try to grow it. Arrays die in these processes all the time. You can search this forum and others for more than a few examples.
      Good backup takes the "drama" out of computing
      ____________________________________
      OMV 3.0.99 Erasmus
      ThinkServer TS140, 12GB ECC / 32GB USB3.0
      4TB SG+4TB TS ZFS mirror/ 3TB TS

      OMV 3.0.99 Erasmus - Rsync'ed Backup
      R-PI 2 $29 / 16GB SD Card $8 / Real Time Clock $1.86
      4TB WD My Passport $119
    • flmaxey wrote:

      It's still outstanding but I've come to understand why. When it comes to growing an mdadm RAID array, users tend to "click" without contemplating the consequences and get in over their heads. Then, with a dead or dying array (usually without backup), they return to the forum after compounding the problem. Often, it's unsolvable.

      If you want to grow your array, you can find the command lines to do it here. - > mdadm RAID 5 - 3 disks to 4 disks

      If something goes wrong (that's not critical), here's a resource to recover your array.
      Recover array (There's good general reading at this site.)

      _______________________________________________________

      With the above noted - if you don't have a full backup of all the contents on your array, or at least the data that you can't afford to lose, don't try to grow it. Arrays die in these processes all the time. You can search this forum and others for more than a few examples.
      Thanks for taking the time to reply, appreciated.

      Yes I've already manually got my RAID array reshaping in the background (additional 6Gb disk = couple of days likely!), just wanted to see whether or not this was a bug as, like other posters, I've done this several times before all in the GUI. Makes sense what you said and no drama to revert to the command line - fingers crossed my additional storage will satisfy me for a while (as additional storage at this sort of size starts to get expensive!).

      Thanks again.
    • Here's to hoping nothing goes south during the reshape. (It's not over until it's over.) If it comes out alright, as a last step you'll have to go into Storage, File Systems and "Resize" your file system to use the additional space.
      _______________________________________

      If adding a 6TB disk, I'm guessing you have a sizeable array. In any case, give some thought to backup even if that would mean backing up individual shared folders to an external drive or host. (They're making reasonably priced 8TB externals these days.)

      Keep in mind - the more disks you put into the array AND, as the existing drives grow older, the probabilities of a catastrophic failure increase. Just a thought, not a sermon. :)
      Good backup takes the "drama" out of computing
      ____________________________________
      OMV 3.0.99 Erasmus
      ThinkServer TS140, 12GB ECC / 32GB USB3.0
      4TB SG+4TB TS ZFS mirror/ 3TB TS

      OMV 3.0.99 Erasmus - Rsync'ed Backup
      R-PI 2 $29 / 16GB SD Card $8 / Real Time Clock $1.86
      4TB WD My Passport $119
    • Users Online 1

      1 Guest