Move from MergerFS to BTRFS?

  • I am currently using MergerFS to crerate a single logical volume over my two physical HDDs. Coincidentally, my drives happen to use BTFRS. From what i read i understand that BTFRS already supports drive pooling and no need to use union file systems tools like mergerfs. However, this BTFRS drive pooling does not seem to be supported by the OMV GUI. MergerFS works fine, but has quite a performance overhead where my old HP microserver is struggling a bit, so i'd rather use something supported directly by kernel instead of FUSE.


    So the question is: is a data migration like that supported in OMV and can be done without data loss on the existing drives?


    Thanks

    SuperMicro CSE-825, X11SSH-F, Xeon E3-1240v6, 32 GB ECC RAM, LSI 9211-8i HBA controller, 2x 8 TB, 1x 4 TB, 1x3TB, MergerFS+SnapRAID

    Powered by Proxmox VE

  • Mergerfs doesn't do anything to your drives. If you don't want to use it anymore, just stop using it.

    --
    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.

  • I'm not speaking from a point of wisdom here. Just a luser.


    I use btrfs because it's just so d*mn convenient.


    BTRFS raid1 makes sure all of your data is written to at least two devices. If your devices are different sizes, it still does that. It can't work miracles. If, for example, you have one 1TB drive and one 3TB drive, you can only get 1TB of usable storage volume out of that. I you have one 1TB, two 2TB and one 3TB drive, you can use all (well, half, i.e 4TB) of it, because there is space for 2 copies of everything on two separate physical devices.


    If your 3TB drive (as in our scenario) fails, you better shut the system down real quick and replace the failed drive, because your redundancy has just degraded massively. Recovery also puts really heavy read loads on the surviving devices, so if THEY also are on their last legs, they might fail during recovery, and then you're DOOMED (don't fret, not you, the data on that volume). This isn't something distinct about BTRFS, that's just how redundancy in general works.


    Plug in an additional hardware device, add it to the btrfs volume and, flash!!!aahaaah!!!, you're done. (See calculator for further information)


    Your post suggested you're only interested in fully duplicated data. If that's right, you're not going to get any more useful knowledge from what follows and you should save yourself some headache and stop reading where it says NOW.


    NOW


    Go away, it's for your own good.


    NOW


    OK, if you've read on, that's totally your own fault, don't blame me.


    It might sound tempting to use raid5 or raid6 modes on BTRFS because, who doesn't like a lot of extra space, but I wouldn't go there. Some failing device taking with it some very important part of the metadata destroying ALL of the real data is not a place I'm willing to go, yet.


    I've read a lot of info about the write hole (that's a term, really, look it up if you care) not being a problem, recoveries working just fine, and all that good stuff. BUUUUUT: Would you bet your stepmother's data on it? How about your own?


    If it worked reliably (BTRFS parity raids that is), I'd be all BOOYAAH! and ever only use something better ever again.

  • guys, it seems you seriously misunderstood my question.


    i am not interested in any data duplication like RAID1/5/6. all i want is to access the data located on different disks from a single shared folder spanning trough multiple drives. this is what MergerFS is doing right now, and is doing it fine (except for the performance penalty). Now I keep reading there is a native way in BTRFS to pool disks together (*NOT* via RAID 0/1/5/6) that may perform better. my question how OMV is supporting this BTFRS drive pooling, since there does not seems to be any reference to it in the gui, and @votdev stated several times that OMV should be used from the web interface and not from the command line.

    SuperMicro CSE-825, X11SSH-F, Xeon E3-1240v6, 32 GB ECC RAM, LSI 9211-8i HBA controller, 2x 8 TB, 1x 4 TB, 1x3TB, MergerFS+SnapRAID

    Powered by Proxmox VE

    • Offizieller Beitrag

    all i want is to access the data located on different disks from a single shared folder spanning trough multiple drives.

    What you are looking at is Raid0 this can be done using btrfs but I think it can only be created from the CLI, Raid0 can also be created in OMV's GUI Raid Management.
    There is one caveat to using Raid0 one drive fails and all your data is gone. I use the MergerFS plugin but I have not noticed any performance penalty and I am using a HP N54L, @gderf uses the UnionFS which he uses manually and I know from some of his previous posts that it's a good size setup.

  • no, i am not interested in Raid 0. i am interested in exactly the same functionality as MergerFS is providing, but implemented natively through BTRFS, because it seems more straightforward. when copying files mergerFS process is having a quite significant cpu consumption

    SuperMicro CSE-825, X11SSH-F, Xeon E3-1240v6, 32 GB ECC RAM, LSI 9211-8i HBA controller, 2x 8 TB, 1x 4 TB, 1x3TB, MergerFS+SnapRAID

    Powered by Proxmox VE

    • Offizieller Beitrag

    when copying files mergerFS process is having a quite significant cpu consumption

    Unless there is someone on the forum that can help you get this set up your best option is google and from what I have read this has something to do with subvolumes.


    But going back to your mergerfs and cpu usage, I have tested just over 8GB of files from my W10 to a folder on my mergerfs mount point the cpu maxed at 50% with the copy time well under 2 mins, for home use I'm satisfied with that.

Jetzt mitmachen!

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