> 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.
I know. Neither are either. git is noticeably slower, the locking is untenable, the case-insensitivity is a source of bugs.
From the NT Design Workbook, oplocks.
> 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.
Both file systems support case sensitivity.
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.