|
Top-level
 @gudenau They cheat at the OS layer, we cheat at the driver layer because it'd be stupid not to. Our default flush interval is faster than macOS though, so your data is strictly safer on Linux (you can lose up to 30 seconds of work on macOS or so, only 1 second on Linux with default settings). None of this matters on laptops because you are guaranteed a flush when the battery is about to die or when you hold down the power button. This only matters for desktops, when you yank power. 9 comments
@gudenau Yeah, I haven't done any explicit stress tests yet but I've hard-rebooted (including the NVMe controller) these things hundreds of times and never noticed any unexpected corruption (just the usual things with NULL trailing blocks in files, which is normal for ext4 defaults) so I'm pretty confident if there is some problem lurking it's *really* hard to hit. @nicolas17 @gudenau @marcan I wrote a kiosk application in Electron that ran on a windows 11 system. The network would go down on a power outage about 200ms before the power that ran the system failed. That was enough time to stop writing data.  @gudenau @nicolas17 @marcan I was getting random corruption because my app updated persistent state when the network changed state. These were kiosks with large touchscreens in science museums. Took a while to debug this remotely because the network changing state occurred much more often than the power being randomly cut. @gudenau @nicolas17 @marcan there was an deterministic ordering for which systems shut down first and lucky for my needs the network shut down first. |
Gregory's Server
@marcan Or there is a power outage or whatever, at least they are both journal filesystems I suppose so it shouldn't matter too much...