[HN Gopher] Show HN: MergerFS - A Featureful Union Filesystem
       ___________________________________________________________________
        
       Show HN: MergerFS - A Featureful Union Filesystem
        
       Author : thricegreat
       Score  : 32 points
       Date   : 2022-01-07 06:26 UTC (2 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | canadaduane wrote:
       | The "Why?" is hard to find, but I think this answer to "Why use
       | mergerfs over unionfs" is informative:
       | 
       | > UnionFS is more like aufs than mergerfs in that it offers
       | overlay / CoW features. If you're just looking to create a union
       | of drives and want flexibility in file/directory placement, then
       | mergerfs offers that, whereas unionfs is more for overlaying RW
       | filesystems over RO ones.
       | 
       | Also:
       | 
       | > What should mergerfs NOT be used for?
       | 
       | 1. databases: Even if the database stored data in separate files
       | (mergerfs wouldn't offer much otherwise) the higher latency of
       | the indirection will kill performance. If it is a lightly used
       | SQLITE database then it may be fine but you'll need to test.
       | 
       | 2. VM images: For the same reasons as databases. VM images are
       | accessed very aggressively and mergerfs will introduce too much
       | latency (if it works at all).
       | 
       | 3. As replacement for RAID: mergerfs is just for pooling
       | branches. If you need that kind of device performance aggregation
       | or high availability you should stick with RAID.
        
       | OJFord wrote:
       | Is this really a 'Show HN'? Anyway, I'm not affiliated with the
       | maintainer either, but if it's of use to anyone reading I do
       | maintain a Docker image for mergerfs:
       | https://github.com/OJFord/docker-mergerfs/
        
       | hello_there wrote:
       | If you find this interesting then you might also be interested in
       | SnapRAID: https://www.snapraid.it/
       | 
       | > SnapRAID is a backup program for disk arrays. It stores parity
       | information of your data and it recovers from up to six disk
       | failures.
       | 
       | > SnapRAID is mainly targeted for a home media center, with a lot
       | of big files that rarely change.
       | 
       | > If the failed disks are too many to allow a recovery, you lose
       | the data only on the failed disks. All the data in the other
       | disks is safe.
       | 
       | I'm not affiliated with any of the projects.
        
         | puddingforears wrote:
         | I've used MergerFS and SnapRAID for my media server for about
         | two years. Together they're really flexible and I've been able
         | to drop extra drives into the array as I've needed the storage.
         | On that capability alone I highly recommend using them.
         | 
         | I haven't had a failure yet but I imagine I wouldn't be in
         | trouble unless I lost a significant portion of my parity drives
         | at the same time.
        
       | sharmin123 wrote:
        
       | karlicoss wrote:
       | Cool tool, but recommend reading the policies [0] section
       | carefully, it did catch me off guard the first time I tried using
       | it.
       | 
       | E.g. say you have /a/foo.txt and /b/foo.txt, and you run mergerfs
       | /a:/b /merged
       | 
       | Now if you print or modify /merged/foo.txt, it would access
       | /a/foo.txt because the default policy for file access is ff
       | (first-found, as defined during the mount).
       | 
       | However, if you run "rm /merged/foo.txt", it would delete it from
       | _both_ /a and /b, because the default policy for unlink call
       | would be "epall" (existing path, apply to all).
       | 
       | [0] https://github.com/trapexit/mergerfs#policy-descriptions
        
       ___________________________________________________________________
       (page generated 2022-01-09 23:01 UTC)