My experience of embedded systems is that: 1) you can destroy the disk if power is lost during the write and 2) a lot of development effort can go into protecting that disk.
As stated FTL and wear leveling mean that you don't know where the data is.
Its important to minimise writes and/or control when writes are made.
Microsoft use the EWF mechanism to ensure reliable embedded device operation by blocking writes to disk (transparently holding the writes in RAM with an option to commit).
I am not aware of an equivelant Linux filter.
Your risk depends on the frequency of writes, the duration of a write and how often you pull the plug.
Its worth noting that Linux often has quite a lot going on in the log department, more so than Microsoft.
You can do a lot to minimise your risk by following the posts in this forum which show you how to configure Linux for use with a flash card, e.g. directing the most frequent logs to a RAM disk which also saves the flash card from wear. Downside, you loose your logs.
JamesH is right, this issue is not unique to the PI and [email protected]
#t does happen. When the [email protected]
#t does happen though the SD card could well be fried.
Short term the answer is to minimise the number of writes (get logs onto a RAM disk) and drill the kids to shutdown. Buy a stack of disks and setup a good cloning system.
I would imagine that the battery powered community will come up with something that does what you want, performs an orderly shutdown on lose of power.
It won't makes economic sense to buy/make a small UPS though even with naughty school kids. Flash corruption is only an issue where the end user cannot easily replace the card, MIL systems etc. Thats assuming that the most frequent log writes have been taken out.
Don't store your home work on the disk that is receiving all the log writes, unless you can get away with "the PI ate it" excuse.
I don't have data at hand but I once went looking for this problem, setup an automated jig with embedded computer logging with random power cycling. The fault does happen but its not very likely.
The disks were near empty so wear was not a factor.