MergerFS + Snapraid: balance data after adding a new disk

  • Hello,


    I might be in need of some help here!


    I just added a new 4Tb disk to my current pool.


    Until then I had :
    - 1x 4Tb parity disk
    - 2x 4Tb data disks
    - 1x SSD for the OS


    Using MergerFS & Snapraid, I'd like to use the mergerfs.balance tool to balance the data across the disks, as the other two disks are pretty much full.



    Problem is: I'm a bit confused on how to proceed.



    According to this thread, one way to install it would be through the command: wget raw.githubusercontent.com/trap…4c87/src/mergerfs.balance


    The things is, I get an "error 400: bad request"... Anyway, I'm stuck at this point.



    Thanks in advance!

  • The download via wget worked for me. Double check that you have the URL correct.


    Code
    https://github.com/trapexit/mergerfs-tools/blob/8b507e5e392cb1a9a76b2958eb7ca87ed6dd4c87/src/mergerfs.balance
    
    
    or
    
    
    https://raw.githubusercontent.com/trapexit/mergerfs-tools/8b507e5e392cb1a9a76b2958eb7ca87ed6dd4c87/src/mergerfs.balance

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • Thanks, that did the trick!


    As expected, after using the mergerfs.balance tool all the disks have pretty much the same amount of data.


    Except for the parity one. It's almost full... Any idea why ? Data disks have 1/3 of empty space.


    I did a sync in snapraid but that didn't help.

    • Offizieller Beitrag

    Except for the parity one. It's almost full... Any idea why ?

    This is why snapraid tells you to use the largest disk in your pool for the parity disk. Your parity disk should not be in your mergerfs pool. If it is, mergerfs will put data on it and snapraid will put the parity file on it. Hence why it is fuller than the other disks.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • List the files on the parity disk using ls -al and post the result.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • Thanks. Here is what I get :


    :~# ls -al
    total 32
    drwx------ 3 root root 4096 janv. 24 2018 .
    drwxr-xr-x 26 root root 4096 août 29 14:44 ..
    -rw------- 1 root root 1145 août 31 19:21 .bash_history
    -rw-r--r-- 1 root root 570 janv. 31 2010 .bashrc
    -rw------- 1 root root 0 janv. 24 2018 dead.letter
    -rw-r--r-- 1 root root 268 janv. 10 2018 .inputrc
    -rw------- 1 root root 26 août 29 16:54 .nano_history
    -rw-r--r-- 1 root root 140 nov. 19 2007 .profile
    drwx------ 2 root root 4096 janv. 10 2018 .ssh

  • Wrong directory. I asked for a listing of the parity disk.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • Maybe In that one?


    ls -al /srv/dev-disk-by-label-ParityDiskA/snapraid.parity
    -rw------- 1 root root 3691169447936 août 30 23:06 /srv/dev-disk-by-label-ParityDiskA/snapraid.parity

  • Run a snapraid sync now. I think the size of the parity will decrease.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • Ok, did a sync, nothing changed...


  • As before, do an ls -al to list the files on the parity drive. Then unmount the drive and run the ls -al again. Compare the two results. Don't forget to remount the drive.


    It's possible you have one or more other non-snapRaid files hiding beneath the mount. If this is not the case, you may have to delete the parity file and sync again.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • You would have to remove the parity drive in the snapraid plugin first, then unmount it, then add it back into snapraid. Personally, I wouldn't bother doing it that way, I would unmount it in the shell, do the ls -al, then mount it again in the shell and then verify that the OMV GUI shows it as mounted.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • First off, thanks gderf for trying to point me in the right direction!



    I think this time I found the solution (see attached).


    In short, if you are in the same situation, this command seems to be the one: Snapraid sync -R



    So basically I saw no change thanks to the 'ls -al' command after unmounting & mounting back the parity drive.


    I decided to wipe the disk and rebuilt the parity. This solution didn't fix anything, Snapraid immediatly allocated the exact same amount of space for this drive when using the sync command.


    Then, once rebuilt, I did a test: a simple transfer of data on the NAS. While the data disks available space decreased as expected, the parity one didn't change at all.


    In the end, I found a topic where someone made the following statement to another fellow who had the same issue: 'You had more data on the data disk in the past (in which case the parity space will be reused when you later add new data files)'



    The solution to get back to normal: Snapraid sync -R


    Snapraid immediatly decreased the used space on my parity drive, and it is now syncing.


    I still have to wait 5 hours or so before making a final check, but things look promising!


    ---
    About the Snapraid sync -R command, according to the manual:
    '
    -R, --force-realloc



    In "sync" forces a full reallocation of files and rebuild of the parity.
    This option can be used to completely reallocate all the files removing
    the fragmentation, but reusing the hashes present in the content file
    to validate data. Compared to -F, --force-full, this option reallocates
    all the parity not having data protection during the operation. This
    option can be used only with "sync".
    '
    ---

  • Thanks for the update and digging out the solution.


    Don't worry thought. Your parity file will grow again anyway :)

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • What to you think about:


    1) mergerfs.balance from pool subfolder to prevent snapraid content files from move
    2) snapraid dup (to see if snapraid detect the moved files)
    3) snapraid sync (the new files to protect current status)
    4) if n-way parity exist: (remove one parity disk from content file or do it over web-gui)
    5) format this harddisk for large files (mkfs.ext4 -m 0 -T largefile4 DEVICE - inode space improvement)
    6) add this emty disk new as n-parity disk
    7) snapraid sync
    8) Do the same with the other n-parity disk


    In this case, the file protection should be alive during the new parity calc and
    the parity disks are reallocated.

  • Thanks!


    Sync went well, all is up and running :thumbup:

    I came here for searching another :) thing. I'm new to OMV and Linux.


    First I read first topic and honestly I thought it is normal since snapraid thinks that you have deleted files in your two disks so maybe you would want to bring them back. This is why file size was so big.


    And Second it doesn't matter how big file size is. in one vay or another it will not get bigger than the biggest disk (wich is the same size in your case)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!