Suppose you are doing a full speed write to disk in a linux pc box with ssd or mechanical disk (OS also on the same disk, there is no battery/UPS):
cat /dev/urandom > omg.txt
If the power losses suddenly during the process, or any other sort of ungracefully shutdown/reset.
Will the file be corrupted and unable to fix (i.e. none of any data can be recovered?), will there be a chance the file system be completely unable to boot?
Will the file be corrupted and unable to fix (i.e. none of any data can be recovered?)
Potentially, yes. There's 2 obvious routes via which this could happen.
Ext4 is a metadata journaling filesystem - it only journals the changes to the file's meta data (size, location, dates) - not the file contents (btrfs and zfs do full-data journalling at a big performance cost). So although you should never have to fsck the disk, it doesn't follow that every write operation betwen opening the file and closing + flushing the buffers will have completed. There is no transactional control over writes to the file data.
A second possibility is that the disk may be physically damaged by power spikes. Although the rest of the hardware tends to do a good job of isolating the hard disk, there will still be some leakage.
will there be a chance the file system be completely unable to boot?
That's a very different question - this is a lot less likely. Certainly the first scenario only applies if you happen to be writing the kernel, bootloader, ramdisk etc at the time of the outage.
See also this Q&A on unix.stackexchange
It shouldn't damage your filesystem (assuming that you use Ext4 and have barriers enabled - as it is by default).
Quote from https://ext4.wiki.kernel.org/index.php/Ext4_Howto:
Barriers on by default
This is an option that improves the integrity of the filesystem at the cost of some performance (you can disable it with "mount -o barrier=0", recommended trying it if you're benchmarking). From this LWN article: "The filesystem code must, before writing the [journaling] commit record, be absolutely sure that all of the transaction's information has made it to the journal. Just doing the writes in the proper order is insufficient; contemporary drives maintain large internal caches and will reorder operations for better performance. So the filesystem must explicitly instruct the disk to get all of the journal data onto the media before writing the commit record; if the commit record gets written first, the journal may be corrupted. The kernel's block I/O subsystem makes this capability available through the use of barriers; in essence, a barrier forbids the writing of any blocks after the barrier until all blocks written before the barrier are committed to the media. By using barriers, filesystems can make sure that their on-disk structures remain consistent at all times."
Some more reading: https://lwn.net/Articles/283161/.
It's not really about filesystem you choose, it's about write caching on your hard drive/raid controller.
If you lose your power, everything in cache is lost, it usually won't affect your OS, but the file can be corrupted, yes.
If you have critical data on your server, always use UPS or RAID controller with battery.
