Is there some reason you want to have both a snapraid pool and a mergerfs pool?
Sorry, when I said part of the snapraid pool, I meant that the mergerfs mount point would reside on one of the drives that is part of snapraid. I'm not using snapraid pooling, only mergerfs pooling.
Snapraid will just see separate disks. The single HDDs are not changed by mergerfs, take one of them out and put in inside another PC and your data will still be there.
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.
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
/srv/dev-disk-by-label-disk1/union12
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:
mv /srv/dev-disk-by-label-disk1/union12 /sharedfolders/disk1
and then they appear in a subfolder of the shared folder disk1 and all is fine. Am I missing something or is this how it is?
Thanks
N
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
N
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
N
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.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
