NTFS filesystem fragmentation & other influence vs database files As probably everybody knows, NTFS has a flaw in design which causes fragmentation during filesystem usage. On the other side, MSSQL uses files as database storage method, and what is more, typical practice is to put several, big, databases on the same filesystem.  Database grow gives perfect example of fragmentation, and it definitely has some influence on SQL server performance.

Question: is there any information about fragmentation of filesystem influence on database/MS SQL Server performance? Or there are  hidden proprietary layers of optimisation of NTFS for MS SQL Server database storage? Are SQL server databases really ordinary files on NTFS or OS treated it as special objects? 
What if disk checkdisk working on NTFS changes some filesystem structure? In typical situation it may change content of the filesystem data ( once I lost Oracle database during such, automatic after BSOD reboot check. Yes, it was on physical raid. Yes it was automatic checkdisk filesystem reparation which destroyed rollback logs). Is there any know safety mechanism preventing such accident for MS SQL to occur?
There are know technologies of raw partition storage, but MSSQL don't have such technology build in.

I do not want to start flame war on obvious statements, question is about technical details and about relationships between two addopted by MS products: NTFS and MS SQL Server.
is there any information about fragmentation of filesystem influence on database/MS SQL Server performance?


AFAIK the only thing we have is about error 665 (NTFS metadata fragmentation) which is more of an error than a performance issue.


  Or there are hidden proprietary layers of optimisation of NTFS for MS SQL Server database storage?


There are not. SQL Server is installed on any system just like it is. It also runs on ReFS.


  Are SQL server databases really ordinary files on NTFS or OS treated it as special objects?


Yep, treated as normal files. Nothing special going on. For real.


  Is there any know safety mechanism preventing such accident for MS SQL to occur?


Nothing stopping the underlying filesystem from doing something bad because of corruption, write caching, etc. We do have some built in mechanisms such as write ahead logging (WAL) but nothing specific for NTFS. That's below our purview as an application on Windows. We tell Windows we want to do something, using normal Windows API... what happens after that is anyone's guess.

Related documentation:


Database Files and Filegroups
SQL Server Transaction Log Architecture and Management Guide