Azure Deployment Experience - Series 3 - Bizarre behaviour in ReFS drive

In my previous post, I described a failure in a ReFS drive. In spite of claiming to be a Resilient one (Re stands for Resilience), we could not recover from bad sectors or corrupted sectors and we had to abandon that drive. 

Wonder why the C and D drive of Azure VMs are still NTFS based and why not ReFS. Does it mean Microsoft itself are skeptical to roll out ReFS for C and D drives.

Yet another problem we faced in one of the ReFS drives in one of the VMs. Here it goes

• Took a Windows OS based VM (D2 series), allocated Disks and created two logical drives - F and G, both with ReFS.
• Hosted the application in F drive (Web based application over IIS).
• Any modification to any of the files in the Web Application folder does not effect in the application. E.g. aspx file modified with some changes. The date time gets updated, but in the application, it does not reflect
• Do a App Pool recycle (of that web app) and then it reflects.
• Hosted the application in C and D drives (NTFS) and the changes work immediately (which is the expected behaviour).
• Hosted the application in G drive (ReFS) and the same problem like the F drive
• Tried a few other VMs, which has a ReFS drive but it worked.
• Create a new logical NTFS drive, repeat the test and it works (w/o app. pool recycle).

I guess, ReFS is not really resilient or fool-proof, especially in Production or sensitive environments. One-off case has occurred at least twice in our case. In the above case, at least we are able to do a work-around.