You want to have your cake and eat it too:
If the fs is mounted 'sync' then the file is also intact, but this doesn't seem to be an ideal solution.
I realise that 'don't pull the power, use a proper shutdown' is a solution, but this cannot be enforced in the environment these are used!
It may be worth noting that there are no operating systems which can satisfy these criteria, period because it is a logical impossibility.
You do your best to ensure a proper shutdown. If the environment poses a problem, this may mean you need need to add circuitry and a small battery. Or...
You use a read-only filesystem. Or...
You keep the filesystem synced to hardware, which is a potential performance hit.
That's it. This is literally physics. There is no possibility for a magic bullet. There are no devices in existence which are a magical exception to this reality.
I'm not sure if using sync affects reads, but I would doubt it. The OS caches things like shared libraries in memory largely read-only to start with, so you should not suffer too much that way. It is only applications that have to write data to storage that will be affected.
a delayed sync by only a few seconds would be acceptable
This is plausible using an ext3/4 filesystem. Instead of using
sync in the mount options, use
commit=N, where N is a number of seconds. This is documented in
Start a journal commit every nrsec seconds. The default value is 5 seconds. Zero means default.
If you look under "ext4" in that manual page, you will see other options such as
max_batch_time; if you are doing a lot of writing, fine tuning these may be helpful.
Of course, since the default commit time is 5 seconds, this does not explain the behaviour you are seeing on the scale of minutes. That being the case, simply changing the time will probably not solve the problem. A potential complication is the use of "erase blocks" by SD media: These are commonly 4 MB or more. When a change is made to a file which doesn't occupy an entire block, the entire block where it resides is re-written, which could include pretty much anything from whatever filesystem (including metadata). If you suddenly kill the power to the card (which has its own microcontroller inside) during this re-write process, you stand to lose data in a random way. Unfortunately the cards are a black box to the OS, so there is no possible strategy here; even keeping the filesystem synced does not remove the risk. The only solution in this case is to either use a read-only system, or add power loss prevention circuitry.