i would say most certainly… loosing the entire database tho survivable sounds horrible… thus any partial restoration of the database should only make the time difference from corruption / loss to when the database was backup matter…
thus lets say your node, deletions we will assume won’t matter because deleted files must be able to be caught somehow at a later point… that leaves uploads and downloads… downloads are irrelevant again because they don’t make us miss any actual data… which leaves the uploads.
which for the lost time period would then supposedly be unrecorded, meaning these files would be stored for free, which i would see a little punishment instead of like alexey suggests that all the files stored when the database becomes corrupt would essentially become free…
not sure if this is realistic, because why would a storagenode ever accept to this… would most likely be more worthwhile to simply kill the node and start over, or thats what it almost sounds like to me…
and odds seem to be that it might happen anyways with the loss of the db’s
also the database isn’t the live data, so it doesn’t impact the erasure coding… if a satellite needs the data and knows it stored it on your node, then it sounds like it would simply retrive it based on it name on the files system… thus erasure codes would be unaffected, so the uploaded files that miss database entries would still work for the network even if they might be freely downloaded…
i would take a few freely downloaded files like if we say 1 file a second so 3600 an hour so in 4 days it would be about 100 hours so 360000 files, and the loss of lets say even 30 minutes would only result in 1800 files… which is a minimal part of the whole…
and then comes the closing on 8000000 files i currently have and keep track of… loosing track of 1800 vs the whole database… seems a trivial matter that will at worst cost me well lets see what is 1800 of 8m … less than 0.25%
actually seems like a pretty solid solution, and since a node can survive without the db’s then the ability to restore our databases at a level of 99.75% should be quite a nice ability to have.
the real problem is if we don’t notice it’s gone bad and the node keeps running and writing in a corrupt database or something like that… ofc doesn’t really change anything aside from how long a period one looses information from…
hell even a backup a day would make the world of a difference for a 3 month old node thats nearly only 1% loss of records…
not familiar with tmpfs
why would you restore data on power failure… zfs should take care of all that… it’s basically built in
only if you db is corrupted or such will a backup be useful… not sure how to automate database corruption and correction, but i suppose the logs could trigger it… or atleast send an alert…
like ZFS when you pull a non redundant raidz drive… it doesn’t go all crazy… it waits until it can speak to the drive again… and thus basically it waits for the drive to reconnect by itself or for a sysadmin to be alerted to the issue and take care of it… and when it detects the drive is back the pool is allowed to continue.
one might want to simply shutdown the node rather than keep it running with a bad DB, this also keeps any weird automatation issues from happening… such as the db was replaced with a backup because the stuff was triggered by mistake.
atleast for the first long while i would keep sysadmin action to let the system automation not make semi possible costly action all by its own until one understands how the coding will behave over time and in real world usage.