One of the many things I’ve been looking at recently includes a few instances of Open Media Vault 5. On my new (Atom) Intel Pentium Silver Quad Core NUC that I bought specially, a Pi4 with an SSD, and a VM on ESXI that I use to help with ESXI backups using GhettoVCB.
5TB USB portable hard drives have become my de facto choice. They’re versatile, low-power and can run directly from a Pi4, actually quite quick for sustained data, don’t require much space, and I can fit 4 of them inside a fairly small firebox. I’m using a few 5TB ones with OMV5 on the NUC along with a 1TB SSD inside the case, for NAS purposes. Booting from the SSD but I’ve also resized the partition for shares (OMV5 installation creates a tiny one by default – err – 8GB maybe it was). Back to the 5TB drives. Obviously these particular drives aren’t designed for this kind of thing at all but I reasoned to myself that they wouldn’t need to be on very frequently and I planned to have them spun down most of the time.
Wrestling with the OMV5 GUI settings didn’t help. The disks wouldn’t spin down. (Not OMV5’s fault … just the firmware in the external drive preventing usual techniques).
They’re ext4 formatted, and, /dev/sdb is also encrypted – I mention it just to reassure that this disk can be spun down too. Nb a Pi4 doesn’t have the hardware or oomph to effectively work with a LUKS encrypted USB drive but this Atom-powered NUC is fine.
Setting Spindown time to 5-minutes for testing here and other exploration in the GUI at least, proved unsuccessful.
I haven’t tested with S.M.A.R.T. enabled at all, wanting that to be as unambiguously not a factor as I could manage, but I set the Check interval to 4000 anyway as I anticipate setting a 1-hour spin down time as a compromise between power-cycles and constant spin for my use case.
Oh by the way … NFS and SAMBA shares are set-up on this drive.
In the future I’m planning to use remote Rsync jobs as part of a back-up “mesh” of devices trying to get as much bang for my buck, but not tested remote Rsync jobs on this instance yet, and I don’t have any monitoring jobs running that accesses the drive currently either. I’m assuming they’d just spin-up the drive when the cron-jobs kick in.
Following a suggestion I found in a forum, I installed this Windows dashboard.
And after replacing the drive and booting-up the NUC again, the drive didn’t spin down. Until I disabled the “Spindown time” for the drive in the OMV5 GUI. (Using touch to check for vibration from the drive – plus the lights on the drives dim).
Spin-up time seemed pretty quick when I tried accessing a file via a Samba share. Couple of seconds, seemed like subjectively.
Now that I’m happy drives will spin down, it seems reasonable to suppose I could add a USB3 powered hub in the future and continue to add these 5TB drives when I want to expand Plex library space for example. So long as filesystems can be mounted, the drives’ firmwares will handle the spin-down.
Portainer very much appeals to me as I tend to prefer visualisations and visually structured ways of finding things though I don’t really use it for much that I couldn’t simply do with Docker Compose text files.
docker run -d --name "Portainer" -p 9000:9000 -p 8000:8000 --restart=unless-stopped -v /var/run/docker.sock:/var/run/docker.sock -v /etc/ssl/certs:/certs -v /etc/ssl/private:/private -v portainer_data:/data portainer/portainer --ssl --sslcert /certs/openmediavault-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.crt --sslkey /private/openmediavault-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.key
version: '3' services: portainer: image: portainer/portainer:latest restart: unless-stopped ports: - 9000:9000 - 8000:8000 volumes: - /var/run/docker.sock:/var/run/docker.sock - /etc/ssl/certs:/certs - /etc/ssl/private:/private - portainer_data:/data command: --ssl --sslcert /certs/openmediavault-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.crt --sslkey /private/openmediavault-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.key volumes: portainer_data: external: true
The drive with the Docker path is the SSD. (Obviously I don’t use the “Shared Folder” path as anything that could hold a file open would upset OMV5 update scripts initiated from GUI actions – so I just use the alternative mount path).
Plex is running in a Docker container and that didn’t stop the spin down … though note the shared volume with Plex’s database is on the SSD too, and, when I opened a Windows Plex client and started playback of a classic Dr Who episode downloaded using the IA client, the drive spun-up fairly quickly. When I stopped playback and closed the client, the hard-drive spun down again after the set spin-down time.
By default, OMV including OMV5 adds “noexec” filesystem mount options to fstab. E.g. on mine:
Note that my “DATA” filemount does not have the “noexec” option. My Docker root path is based on there and so it would prevent my Plex Transcoder working, and the Portainer extension manager that invokes an executable to check licences (I use the Docker Registry Manager extension).
I can’t just edit it in fstab though as fstab gets rebuilt by OMV5 when adding new mounts. See https://openmediavault.readthedocs.io/en/latest/various/fs_env_vars.html
Instead, I just changed the <mntent> entry in /etc/openmediavault/config.xml for my purposes, removing “noexec”. However, at time of writing (2019, Dec, 19th) the docs haven’t been updated to reflect changes in OMV5 and “omv-mkconf” no longer exists. In order to rebuild fstab, we use: