I'll try again. Let's say sda,sdb,sdc,sdd,sde make up a snapraid pool. a,b,c are data and d&e are parity. Let's say I've created a merger-fs mount that combines a directory on sda and sdc. Now, can I put the mergerfs mount directory on sda or sdb or sdc without confusing snapraid? Or must I exclude that directory from snapraid?
I have physical data disks sda, sdb, sdc, sdd, and sde. OMV is on a small SSD sdf.
I set up SnapRaid using the plugin with data disks sda, sdb, sdc, and sdd; parity is on sde.
I setup mergerfs by hand in /etc/fstab (the plugin will not allow me to use directories as sources, it only allows entire drives to be used).
I have the megerfs mountpoints on sdc.
I do not exclude the mergerfs mountpoints from SnapRaid, and there have been no problems.
If there were going to be problems with this (I suspect you are thinking of a circular reference type situation), then I would have put the mergerfs mountpoints on the rootfs which is not seen by SnapRAID at all.
Thank you gderf. That answers my question. (I was thinking about the possibility of a circular reference) My configuration is very similar to yours. I would put the mergerfs mountpoints on the rootfs, but then OMV doesn't allow you to share them! At least not through the webui - one could always edit some conf files and make it happen I suppose.
I have a new and much simpler question about mergerfs which I hope somebody can put me straight on... I think I must be missing something somewhere.
Let's say I use the mergerfs plugin to create a file system called union12 combining two devices with labels disk1 and disk2.
I then create a shared folder from union12, share it with samba and copy a few files into it.
These files now show up in
/sharedfolders/union12 and also
So union12 is being treated as a shared folder resident on disk1 - all OK so far.
My question then is, what happens if I now decide to remove the union file system without deleting its contents? How do I then access the files that were uploaded to union12? I understood that this is one of the strengths of mergerfs...
Deleting the unionfs results in the removal of the folder /sharedfolders/union12 but the files still exist in /srv/dev-disk-by-label-disk1/union12.
However without some cli fiddling they are no longer accessible with smb. Is that how it is meant to be?
I can only access them again if I move them like this:
Indeed, I can always recreate the symlink and/or share the union12 folder directly but it seems kind of messy. Maybe that's just how it is?
I had expected all files in the union12 share to show up in the disk1 share AS WELL - but it doesn't seem to work that way
EDIT - If I understand you correctly, you would indeed have to share the path to the individual disks if you want this to work.
You mention that you expected the files to show up in the disk1 share as well, but it sounds like you didn't actually create a share to that folder. Also, the write policy you select when creating the pool determines which device the files are written to. In some instances, disk1 is not filled before files start being saved to disk2, so your files could be split equally between the two devices.
The post was edited 3 times, last by flvinny521 ().