If you have a mergerfs pool which you are exporting there have been issues reported. If you are merging NFS exports... no issues.
New build ZOL 24TB
- Thread starter Arrogant
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
No. What issue with Samba? The only known issue is not a mergerfs thing... it's a SMB/CIFS client thing related to renaming of files. You can read the details of the issue in the mergerfs readme.
As an FYI, I export a mergerfs pool with NFS4 on Ubuntu with no issues. I just checked Github for any issues about NFS exports and I don't see any open issues.
I export my mergerfs pool via SMB without issue as well. If you are trying to pool SMB or NFS mountpoints, there shouldn't be any problems either.
Thanks...
renaming issue on SMB/CIFS.
will try to mount on NFS 4.X and run simple unit testing to emulate read/rename/copy....in iteration.
Just out of curiosity could you set up a few nodes with let's say 4 hdds each and then share each via nfs mounts separately and then use mergerfs on another node and pool all those mounts into one pool, correct?
If done on a gigabit network would it be reasonable to assume that you could saturate a gigabit connection on reads and writes this way?
Would it be possible to set this up with a wol or ipmi command when querying drives from one of those nfs mounts to turn on the node? I have implemented a script on a ddwrt router to wol a plex server on lan or wan when the server is queried and by a specific port. I assume nfs runs over a specific port or something that can be used to identify traffic. How long would mergerfs pause while things boot or would it crash hard?
This theoretical exercise is mainly because this could be a pretty cool way to create a large pool with extremely low power use and only spin up nodes on demand and then shut them down on idle.
All of the pooling portion of the above should work, but I have no idea about mergerfs' ability to wait for an OS to start up and share out the disks correctly. I don't have any extra hardware to try this out right now unfortunately. It seems like a cool experiment.
You would' need to worry about ports with NFS as mergerfs would just pool the underlying NFS mounts via mount point.
You would' need to worry about ports with NFS as mergerfs would just pool the underlying NFS mounts via mount point.
It depends on the write policy and where on the pool the reads need to come from. I would expect to have a fair amount of disk spinup in this scenario as mount points would not be available to query if they were off.
Trapexit, the author of mergerfs, is investigating some mechanisms to reduce the potential for disk spin ups even further. If you have questions, just post on his Github page, he is extremely responsive. Although, this and my example above are pretty big leaps from what mergerfs is really designed to do (a simple pooling solution with write modes).
Trapexit, the author of mergerfs, is investigating some mechanisms to reduce the potential for disk spin ups even further. If you have questions, just post on his Github page, he is extremely responsive. Although, this and my example above are pretty big leaps from what mergerfs is really designed to do (a simple pooling solution with write modes).
Last edited: