Question: FCI technology uses windows clustering to start-up the sql server service on the secondary node and provides the secondary node with the data and log disks.

Assuming the OS on node 1 crashed, and the FCI failover started-up the node 2, then what is the guarantee of data consistency and integrity? For example - it could be that the OS crashed while working on the sql data and log files thereby causing corruption.

Answer: 
It depends, since there are multiple points where a crash can happen.

* SQL Server the process might crash
* Windows OS might crash
* VM host might crash
* SAN/disk controller might crash

Now, if the SQL Server crashes, Brendan McCaffrey's [answer](https://dba.stackexchange.com/a/312089/4511) outlines the process in detail.

What if it was Windows itself? Windows' NTFS is a journaled filesystem, so it should write whatever data SQL Server tells it to in consistent state, right? No, it does not guarantee that *user data* - which database files and transaction logs are - are intact. It guarantees that NTFS [internal data structures](https://devblogs.microsoft.com/oldnewthing/20130101-00/?p=5673) are robust. So, even if NTFS tells SQL Server that a transaction is written, it might not be if crash happens meanwhile.

What if the VM host crashes? This is more tricky. From Windows' point of view, it's a bit like someone pulls the power cord. The big "but" here is that VM systems hide the IO, so that Windows thinks it has made a successful write operation, but it's still cached on the VM host. And now the host crashes and the I-thought-it-was-written thing just disappears. What's the actual state on (virtual) disk? No one can tell. This was not too uncommon a failure, say, 10 years ago when virtualization wasn't that mature a technology.

What if the disk controller crashes? All bets are off. There's no way to tell what the controller actually writes on the disk, if anything. There are no guarantees it makes any sense. I've seen a few of these cases on HP EVAs, but those were rare occurrences.
> 
> For example - it could be that the OS crashed while working on the sql data and log files thereby causing corruption.
> 
> 
> 

You are talking about SQL FCI and OS has hardly role in *data consistency* here as the data and log files reside on shared drive. So basically if OS crashes and failover happens all infight transactions would be rolled back, committed transactions would be rolled forward and you would see that when DB comes online on other node.