I am very pleased to finally see not only Greyhole ported to OMV 0.5 but also SnapRAID. I have actually been using both of these programs with OMV 0.3 for months now and I was putting off updating my OMV server until at least MySQL and Greyhole were ported. Thanks to all who helped to bring this very useful functionality to an already great product.
However, while running through a basic setup of the new SnapRAID plugin on an OMV 0.5 VM, I noticed that there is a software check that prevents one from placing a copy of the content file on a parity disk. Is there a specific reason for the plugin to impose this restriction or can this check be removed?
From the online SnapRAID manual:
Quote
The list of files is saved in the "content" files, usually stored in the data, parity or boot disks. These files contain the details of your backup, with all the checksums to verify its integrity. The "content" file is stored in multiple copies, and each one must be in a different disk, to ensure that in even in case of multiple disk failures at least one copy is available.
I currently have an OS drive, 3 pooled data drives (using Greyhole), and a single parity drive. I prefer to use my pool drives for data only and so I keep copies of my content files on my OS drive and my parity drive. I understand there is some concern with running out of space on the parity drive, but this can be mitigated by use of the exclusion list rules.
On a side note,
Quote from "viald"
According to me Greyhole is not the best choice, because you don't obtain a virtual file system but a CIFS share which of course it's not view by the system the same way.
For example if you want to add a path to your Plex configuration, I think that you can't do it using greyhole, because Plex lists only all file systems even if they are virtual.
FYI, in my experience Greyhole has worked just fine with a Plex, minidlna, or MythTV server on the same machine. Greyhole uses a CIFS/SMB share which in turn is tied to a shared folder (aka landing zone) in the file system. Greyhole then maintains that shared folder with symlinks to the actual files in your pool after moving files out into the pool. As long as there are not any issues with following symlinks then just point whatever program (Plex, etc.) to the shared folder that is associated with your Greyhole CIFS/SMB share. Note that this method is primarily for READ ONLY access since writes directly to the shared folder are not processed by Greyhole. Additionally, having my Greyhole "landing zone" on an SSD essentially acts as a cache drive to greatly speed up writes to my pool (ie. I am only limited by either the source medium or gigabit ethernet speeds) all while letting individual drives spin down when idle to save power, etc.
A better option is probably to locally mount the CIFS/SMB share directly. One quirk of directly accessing the shared folder is that creating new files doesn't seem to trigger Greyhole to properly copy them into the actual pool. A simple check for orphaned files in Greyhole will trigger a "cleanup", but this essentially introduces a manual or scheduled secondary process. As an alternative, the link below describes a quick way to mount a Greyhole share locally, which I plan to do while migrating my OMV from 0.3 to 0.5.
https://github.com/gboudreau/G…e/wiki/MountSharesLocally
Quote
Mounting your Samba shares locally is useful when you are using Greyhole, and want to write or in any way work with those files locally. Greyhole data should only be accessed through shares, so mounting those shares locally is an easy way to work with Greyhole data safely.