> Because the NT OS/2 I/O system is asynchronous by nature, the ability to make a request and then have it completed at a later time makes it natural for implementing oplocks. Further, because synchronization is required by the file system to determine when the caller has completed its oplock update transfers, the file system can use this feature to block open requests to a file by queueing the I/O Request Packet (IRP) to its internal file control structure until the oplock owner lets it know that it is finished.

Use DevDrive in a virtual disk or secondary volume, there are significant performance gains for things like git, nodejs modules, etc.

It helps to know the system. The perf would be an issue with any file system on Windows due to the file system filter architecture.

Locking is a function of the NT executive and not of the file system. It was a design decision. I’ll see if I can dig up the reasoning later.