3 ms·

Thanks for the link. What an amusing band-aid. It's weird that they're mixing ReFS into it, as NTFS is not at all the problem. It feels like they're either usi

Thanks for the link. What an amusing band-aid. It's weird that they're mixing ReFS into it, as NTFS is not at all the problem. It feels like they're either using this as a random opportunity to air ReFS again, or as a decoy to make it sound like the dev partition is a fancy special filesystem optimization, rather than the more likely reality of it being duct tape on their weird VFS layer, likely doing away with stuff like in-line Windows Defender I/O interception as all the usage warnings and corp group policy references would suggest to be the case...

sedatk 2y ago
What’s weird about Microsoft’s VFS layer?
- arghwhat 2y ago
  The primary peculiarity and cause of issues is the Microsoft "filter driver" concept that allows I/O to be intercepted for a variety of purposes. A primary use-case for this is Just-in-Time anti-virus scanning, both for Windows Defender and third party products, which makes tasks that involve many small I/O operations (like compiling sources, using git, dealing with training sets or unzipping something with many files) very slow.
WorldMaker 2y ago
Yes, the major benefit of Dev Drive is that the default filter driver stack is minimized from OS drive defaults, including Defender's and other AV's realtime drivers. NTFS itself wasn't the problem. Microsoft seems to acknowledge that the filter drivers in the wild are a part of the problem, and a partition opt-out is useful. (Of course all those warnings about corp group policy also point out that Enterprises are given the ability with group policy to force turn on a lot of those filter drivers for Dev Drive partitions, because Microsoft loves giving Corporations ways to shoot their own feet in Group Policy. What would Group Policy even be if it wasn't just Footgun as a Service?) It does seem like this is some sort of "trojan horse" (but not in a bad way) play for ReFS. But I'm not sure it is for sinister reasons: Encouraging Developers to use ReFS for their main development partition is a good way to encourage lots of free app compatibility testing on top of ReFS and suss out the minor bugs in applications that assume all Windows runs solely on NTFS. It seems like a play to increase reliance on the VFS layer and its abstractions and further get away from code assuming NTFS specifics.

sedatk 2y ago

What’s weird about Microsoft’s VFS layer?

arghwhat 2y ago
The primary peculiarity and cause of issues is the Microsoft "filter driver" concept that allows I/O to be intercepted for a variety of purposes. A primary use-case for this is Just-in-Time anti-virus scanning, both for Windows Defender and third party products, which makes tasks that involve many small I/O operations (like compiling sources, using git, dealing with training sets or unzipping something with many files) very slow.

WorldMaker 2y ago

Yes, the major benefit of Dev Drive is that the default filter driver stack is minimized from OS drive defaults, including Defender's and other AV's realtime drivers. NTFS itself wasn't the problem. Microsoft seems to acknowledge that the filter drivers in the wild are a part of the problem, and a partition opt-out is useful. (Of course all those warnings about corp group policy also point out that Enterprises are given the ability with group policy to force turn on a lot of those filter drivers for Dev Drive partitions, because Microsoft loves giving Corporations ways to shoot their own feet in Group Policy. What would Group Policy even be if it wasn't just Footgun as a Service?) It does seem like this is some sort of "trojan horse" (but not in a bad way) play for ReFS. But I'm not sure it is for sinister reasons: Encouraging Developers to use ReFS for their main development partition is a good way to encourage lots of free app compatibility testing on top of ReFS and suss out the minor bugs in applications that assume all Windows runs solely on NTFS. It seems like a play to increase reliance on the VFS layer and its abstractions and further get away from code assuming NTFS specifics.