Closed errolt closed 4 years ago
As a temporary solution you can override tmp directory location using property: "server.tmp.directory".
But that will have a drawback: rtl_sdr will write to it instead of /tmp which by default is ramdisk.
/tmp can not be in ramdisk. Because then you get same AtomicMoveNotSupportedException when recording is copied from tmp to data folder, because data folder is not in ram disk. satellites.basepath.location and server.tmp.directory must be on same drive and it must be same drive as pi home folder. From troubleshooting guide:
Check filesystem. r2cloud doesn't support /tmp on a separate filesystem. If "/tmp" and "/home/pi/r2cloud" are on different filesystems (mounts), then configure tmp directory in ~/.r2cloud to be:
server.tmp.directory=/home/pi/r2cloud/tmp
Current work around is to change schedule in web UI then manually copy new config file to .r2cloud
/tmp can not be in ramdisk
Ah makes sense. Why "server.tmp.directory" doesn't work for you?
I mount external disk under /home/pi/r2cloud/data/satellite then satellite data is external satellites.basepath.location=/home/pi/r2cloud/data/satellites/
But then I get AtomicMoveNotSupportedException error after record when moving data from temp to data folder. So I put tmp folder also on external disk: server.tmp.directory=/home/pi/r2cloud/data/satellites/tmp
But then I get AtomicMoveNotSupportedException if I change schedule.
If I move server.tmp.directory to same disk as ~ then change schedule works but recording gives AtomicMoveNotSupportedException error. If I move server.tmp.directory to same disk as satellite data then recording works but changing schedule gives AtomicMoveNotSupportedException.
So, server.tmp.directory disk and satellites.basepath.location disk and ~ disk must all be same disk, else something does not work and give AtomicMoveNotSupportedException.
Got it. Will fix it ASAP.
Fixed. Now user settings do not use tmp directory, so it is safe to have:
server.tmp.directory=/home/pi/r2cloud/data/satellites/tmp
I need to perform some tests to verify if temporary observation data can be written directly to satellites.basepath.location
folder.
Great! Thank you! Tested and working perfectly.
Currently the temp folder and the satellite data folders must be on the same volume due to the atomic copy from temp to data folders. This is OK.
But why must the settings file copy be atomic? This copies the settings file "user.properties.tmp" from the temp folder to the ~/.r2cloud file and thus forces the temp folder, and by extension the satellite data folders, to be on the same volume as ~
The result is that the temp folder and the satellite data folders can't be moved to an external disk. If you move temp and satellite data to external disk and you try to update the schedule then you get:
This makes it harder to use ssd along side SD as suggested in Troubleshooting guide: