A Google of "peter zaitsev" file systems buffering double write gives several good references (Peter Zaitsev works for Percona who are big hitters in the MySQL world.
Of these, I picked out 4 as being of particular interest[1, 2, 3, 4].
In the first reference, Zaitsev gives a great précis of the various reasons why partial page writes might occur (section entitled "Now lets talk a bit about partial page writes").
Zaitsev then goes on to a section about how double write works, but I think that a better explanation is to be found in reference 2 - in particular this bit:
If a partial page write occurs in the data files, InnoDB / XtraDB will
check on recovery if the checksum of the page in the data file is
different from the checksum of the page in the doublewrite buffer and
thus will know if the page is corrupt or not. If it is corrupt, the
recovery process will use the page stored in the doublewrite buffer to
restore the correct data.
If a partial write occurs in the doublewrite buffer, the original page
is untouched and can be used with the redo logs to recover the data.
Basically, this behaviour is controlled by a system parameter called innodb_flush_log_at_trx_commit. This section is too big to be quoted in its entirety here, I'll just quote the bit about the default value: (I strongly recommend that you read it in full to get a good overview).
◾ The default value of 1 is required for full ACID compliance. With
this value, the contents of the InnoDB log buffer are written out to
the log file at each transaction commit and the log file is flushed to
disk.
However, this section of the manual also says:
Controls the balance between strict ACID compliance for commit
operations, and higher performance that is possible when
commit-related I/O operations are rearranged and done in batches. You
can achieve better performance by changing the default value, but then
you can lose up to a second of transactions in a crash.
In plain English this means that "ye gets what ye pays for" - i.e. there's a balance to be struck between data integrity and performance. Despite searching high and low however, I haven't been able to find any more than this in terms of detail - unless you want to go rummaging round the code (above my pay grade I'm afraid :-) ).
You can switch off the parameter innodb_doublewrite and then this leads one to another system parameter innodb_flush_method - again it's all about performance vs. data integrity. My references 3 and 4 go into detail on this - basically the debate in these two references is about whether it is a good idea to switch off doublewrite if you have a transactional file system.
The consensus appears to be that if you're using ZFS (and other, perhaps esoteric, file systems/devices), you're safe switching off doublewrites - assuming RAID with battery operated disk caches. Reference 4 IMHO suggests that the debate is still open as to whether ext4 is safe - also see here.
The diagram below provides a good overview of the MySQL's InnoDB architecture.
