Make it an option. Even with a UPS, sometimes the OS crashes or hardware messes up. Sometimes even a UPS fails and not all of them have a bypass mode.
Data that was not written will be lost, but any data that has been written and sync’ed should survive a crash.
This is wishful thinking. Filesystems that are not CoW don’t guarantee that. Moreover, some storage devices, such as SSDs without PLP absolutely can destroy old data if new data write is not complete, by design. There is nothing applications or filesystem can do.
Those are catastrophic rare events. It makes no sense to design to tolerate them: nothing is free, and overhead will be experienced by everyone, just to save shitty setups and/or handle once-a-decade os hang.
If I take, say, a MySQL server and mount its data partition in a way that ignores sync() calls, would I lose more data after I pull the plug or the same amount?
There is a difference between “cannot guarantee” and “less likely”. Sure, something like ext4 may not guarantee it, but data loss would be less likely and with something like zfs the data loss would be even less likely.
To run a Storj node you should not buy new hardware, just use what you have and what you already keep online anyway, but buy a UPS, a server with two power supplies and make sure nobody can pull the plug on it.
The overhead would not be experienced by eeryone if it is an option. Something in between the current way of doing things and mounting the data partition with sync option.
I don’t think this is what elek implied. There’s a saner route—still operate without flushes, just have an automated way of recovering what’s easily possible after a crash. Like, if a node would lose last ten minutes of uploads, nobody will cry, this is <1% of a single day, well within operational requirements for a storage node.