In MySQL, how exactly does data flows from query to disk? I would like to have clarity on how exactly data flows from the the time of firing a query till it goes to disk. (I have rough idea it will go to buffers, then to redo logs then disk files) but then how about bin_log_cache is used.

I have googled this but didn't find much on this topic. I hope to have some explanantion here among the between people of this community.
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.