|
|
|
|
|
|
by formerly_proven
1795 days ago
|
|
|
It's not (just) a NTFS problem, but larger design issues around the centralized object handling in NT, (intentional) lack of a caching VFS layer [1] and of course filter drivers (which are a public kernel API and enjoy a lot of use). There's a fairly lengthy explanation of these issues with Windows I/O somewhere on one of the WSL bug trackers. > Again, not true. No one can know everything that MS is doing, ... You're right of course - there is a number of releases yet to come. What I meant is that the focus is elsewhere (VS Code) and that the platform isn't going anywhere. [1] In the design of typical unixen the file system is central and the kernel does a lot (central VFS, kernel resolves paths to inodes by itself if cached, in Linux the FS can even tell the kernel the extents of an inode to delegate that IO entirely etc.), while the NT design is a "generic tree of objects" (combined with "every action is an IRP, which can traverse any number of filters and such") where file systems are nothing really special; file system stuff is the file system's problem. |
|
|