I tested this with inotifytools which is a disk level copy on write. The problem is in why the primary write fails in the first place, since the backup will break too. A failure boils down to being unable to read the latest state.
Reality is that a production routing node can't be allowed to have storage fail, period... Else it's dead.
Use nvme raid and you'll have bigger problems to worry about.
What I'm trying to anticipate is a failure that isn't based on a disk write fail, but let's say you forward a transaction, write your db to disk, and then a few minutes later (before any new transactions are sent to your node), your node catches fire and dies in a heap of ash? In that case, the last write to the channel.db was great, it's just that you can't get it anymore.
reply
You have no way of being sure that the db got the latest tx, and when shit goes sideways it's often a panic when writing, so no this isn't a great option... You risk loss of your funds if you ever have to use it for recovery which is why scb is the way it is
reply