If you noticed that your hard drives don’t spin down while PhotoStructure is running, you’re not alone.
PhotoStructure has several periodic health checks that run commands like df which also may spin up disks. These health checks run every minute or two, which prevents drives from spinning down.
The solution is to have sync and web determine when they are idle, and “hibernate” automatically.
Know that this is a known issue and that I hope to fix this soon.
If I set up PhotoStructure for Docker on a system with both HDD and SSD, would I be able to let the discs spin down if I mounted only certain volumes on the SSD? For example my photo library stays on the HDD, but I could put /ps/tmp and /ps/logs on the SSD.
I ask because the new Synology DS923+ officially supports using the M.2 NVME SSD spots as a storage pool instead of just cache as on previous models.
Of course you can create a storage pool with the M.2 slots with the command line on previous models, but it’s not officially supported and it would be annoying to have an update delete the data. Doesn’t matter to me if it’s just /ps/tmp and /ps/logs on the SSD that were lost, but it would be annoying if I had to store /ps/library on the SSD to let discs sleep and I had to rebuild my PhotoStructure library after a Synology update that disabled the workaround for these older models.
I’ve added a file-based caching layer with settings-based TTL to the volumes() function, but that cache was only available to the worker processes. I’ve changed it to accept cache if the mountpoints match what’s currently inn
I just realized that if I add a configurable cache to mountpoints(), update it to include mount points so a bigger value (say, 24h) will let HDDs idle.
To minimize hits to df (which may wake drives), set volumeMetadataTtlMs=0 and mountpointsTtlMs=0 which will cache volume metadata indefinitely.