Re:There are only four billion floats, so test them all (2014)
by MertsA on Monday October 12, 2020 @07:23AM
(#24753305)
>I would simply use the equivalent of rsync -Pa /ramdisk /disk in a loop
That's probably a bad idea. rsync isn't going to copy over writes in the same order they were written by the DB. Most DBs assume that when there's some crash that at least the disk would have been in a logically consistent state with respect to the order of certain writes separated by e.g. fsync and barriers.
Re:There are only four billion floats, so test them all (2014)
by AI_WAIFU on Sunday October 11, 2020 @08:22PM
(#24750317)
Does anyone know the risk of radiation bit flips in this case? I don't think it's an issue with ecc ram, but if it's not that could be a problem for certain applications.
Re:There are only four billion floats, so test them all (2014)
by count on Sunday October 11, 2020 @10:01PM
(#24750791)
A friend of mine wrote a 'chaos engineering' tester for this specific issue:
http://github.com/enferex/cme
Randomly inject bit flips into a target process memory space, so you can see/test how your software handles it (if at all).
Re:There are only four billion floats, so test them all (2014)
by sillysaurusx on Sunday October 11, 2020 @09:15PM
(#24750566)
Exactly! I was wondering about that. It seems like it's so rare as not to matter, but that's no guarantee it won't matter.
The main problem I was uneasy about was, I would simply use the equivalent of rsync -Pa /ramdisk /disk in a loop, which seemed to ensure safety in the event of a poweroff. It never broke, but I wouldn’t say it was a good idea, necessarily.
Sure speeds up most things though. The benefits are pretty crazy for I/O bound programs.