3 ms·

Filesystems are a database and have to deal with CAP Theorem trade-offs like everything else. Windows and NTFS both took a heavy focus on Consistency/(lack of)

Filesystems are a database and have to deal with CAP Theorem trade-offs like everything else. Windows and NTFS both took a heavy focus on Consistency/(lack of) Partitions over Availability. Most POSIX operating systems and their filesystems took a heavy focus on Availability at the expense of Eventual Consistency and Sometimes Partitions. Neither approach is wrong, they are just very different approaches with very different performance trade-offs. Also Windows' filesystem supports an entire plugin stack including user-space plugins, to support things like anti-virus scanners and virtual filesystems and all sorts of other things. Not all of Windows' "slow" filesystem is first-party problems, a lot of it can be third-party drivers and tools that are installed.

blibble 3y ago
a local filesystem that can only be mounted once and of which state is 100% controlled by one entity (the local kernel) is not a distributed system the CAP theorem simply does not apply Windows IO subsystem was simply designed for extensibility over performance
- WorldMaker 3y ago
  A) It's a useful analogy whether or not you think it technically applies or is a perfect analogy. B) The Windows filesystem (and to an extent the POSIX) isn't just "local", it also includes transparent and semi-transparent network file storage. C) Windows and POSIX are both multi-user and multi-process. They operate over multiple cores and multiple I/O buses. Even if it just one system API centralized in charge of all that, it still needs to be built on top of complex distributed dance of mutexes/locks/semaphores/other distributed control structures. Because of the nature of I/O control there are complex caches involved and transaction semantics of when data is actually pulled from/flushed to low level data stores. The transaction model in turn is reflected in what the files look like to other users or processes running at the same time. Windows and NTFS combined have strong transaction guarantees that other users and processes must see a highly consistent view of the same files. It makes heavy uses of locks by default even for cached data. POSIX favors the "inode" approach that favors high availability and fewer locks at the cost of eventual consistency and the occasional partition (the "same" file can and will sometimes have multiple "inodes" between different processes/users, many common Linux tools rely heavily on that). Those two different transaction models are most easily explained in analogy to CAP Theorem. They are very different transaction models with different trade-offs. Whether or not you see a single "local machine" or you see a distributed system of cores, processes, users, diverse I/O buses is partly a matter of perspective and will reflect how well you personally think CAP Theorem is a "perfect" analogy for a filesystem.
  - blibble 3y ago
    an NTFS volume can only be mounted by one entity at a time, the same as a zfs volume, ext4 volume, btrfs volume with 100% of the state managed by a single entity it is almost the definition of "not a distributed system" the fact there might be nfs/smb/ceph/... volumes bolted into the same namespace that happens to include it does not make it one (and neither does requiring transactions) > Windows and NTFS combined have strong transaction guarantees that other users and processes must see a highly consistent view of the same files. It makes heavy uses of locks by default even for cached data. POSIX favors the "inode" approach that favors high availability and fewer locks at the cost of eventual consistency and the occasional partition (the "same" file can and will sometimes have multiple "inodes" between different processes/users, many common Linux tools rely heavily on that). this is literally is not true, they are different abstractions and I suggest you observe the size of a large file being copied if you want to see how "strong" NTFS "highly consistent views" are https://devblogs.microsoft.com/oldnewthing/20111226-00/?p=8813 https://devblogs.microsoft.com/oldnewthing/20111226-00/?p=88...
godshatter 3y ago
I remember hearing that allocating space on NTFS on Windows takes a long time for a large amount of files and/or disk space compared to ext4 and the like on linux. Presumably they are built to write out 0's or something when they do that whereas in linux you're just updating inodes or whatever. I remember this was in reference to Steam allocating file system space for game files before downloading them. I don't know if it was the views of the designers of NTFS taking a different set of priorities or if it's more that NTFS wasn't designed as well as some linux file systems were.
- WorldMaker 3y ago
  That's my understanding: Windows doesn't want the security problems of people allocating disk space and trying to read back garbage deleted files left behind by other programs in the hopes of finding user secrets, so if you explicitly ask it to allocate a file of a certain size, it (slowly) fills it with 0s first. But also, Steam's allocation step seems an interesting relic of Windows 9X design patterns, smaller hard drives, worse cache/temp folder options, and (much) slower download speeds. It probably isn't necessary and they could maybe design something simpler and better from scratch today. (But it's probably a "not broke don't fix it" thing at this point.)

blibble 3y ago

a local filesystem that can only be mounted once and of which state is 100% controlled by one entity (the local kernel) is not a distributed system the CAP theorem simply does not apply Windows IO subsystem was simply designed for extensibility over performance

WorldMaker 3y ago
A) It's a useful analogy whether or not you think it technically applies or is a perfect analogy. B) The Windows filesystem (and to an extent the POSIX) isn't just "local", it also includes transparent and semi-transparent network file storage. C) Windows and POSIX are both multi-user and multi-process. They operate over multiple cores and multiple I/O buses. Even if it just one system API centralized in charge of all that, it still needs to be built on top of complex distributed dance of mutexes/locks/semaphores/other distributed control structures. Because of the nature of I/O control there are complex caches involved and transaction semantics of when data is actually pulled from/flushed to low level data stores. The transaction model in turn is reflected in what the files look like to other users or processes running at the same time. Windows and NTFS combined have strong transaction guarantees that other users and processes must see a highly consistent view of the same files. It makes heavy uses of locks by default even for cached data. POSIX favors the "inode" approach that favors high availability and fewer locks at the cost of eventual consistency and the occasional partition (the "same" file can and will sometimes have multiple "inodes" between different processes/users, many common Linux tools rely heavily on that). Those two different transaction models are most easily explained in analogy to CAP Theorem. They are very different transaction models with different trade-offs. Whether or not you see a single "local machine" or you see a distributed system of cores, processes, users, diverse I/O buses is partly a matter of perspective and will reflect how well you personally think CAP Theorem is a "perfect" analogy for a filesystem.
- blibble 3y ago
  an NTFS volume can only be mounted by one entity at a time, the same as a zfs volume, ext4 volume, btrfs volume with 100% of the state managed by a single entity it is almost the definition of "not a distributed system" the fact there might be nfs/smb/ceph/... volumes bolted into the same namespace that happens to include it does not make it one (and neither does requiring transactions) > Windows and NTFS combined have strong transaction guarantees that other users and processes must see a highly consistent view of the same files. It makes heavy uses of locks by default even for cached data. POSIX favors the "inode" approach that favors high availability and fewer locks at the cost of eventual consistency and the occasional partition (the "same" file can and will sometimes have multiple "inodes" between different processes/users, many common Linux tools rely heavily on that). this is literally is not true, they are different abstractions and I suggest you observe the size of a large file being copied if you want to see how "strong" NTFS "highly consistent views" are https://devblogs.microsoft.com/oldnewthing/20111226-00/?p=8813 https://devblogs.microsoft.com/oldnewthing/20111226-00/?p=88...

godshatter 3y ago

I remember hearing that allocating space on NTFS on Windows takes a long time for a large amount of files and/or disk space compared to ext4 and the like on linux. Presumably they are built to write out 0's or something when they do that whereas in linux you're just updating inodes or whatever. I remember this was in reference to Steam allocating file system space for game files before downloading them. I don't know if it was the views of the designers of NTFS taking a different set of priorities or if it's more that NTFS wasn't designed as well as some linux file systems were.

WorldMaker 3y ago
That's my understanding: Windows doesn't want the security problems of people allocating disk space and trying to read back garbage deleted files left behind by other programs in the hopes of finding user secrets, so if you explicitly ask it to allocate a file of a certain size, it (slowly) fills it with 0s first. But also, Steam's allocation step seems an interesting relic of Windows 9X design patterns, smaller hard drives, worse cache/temp folder options, and (much) slower download speeds. It probably isn't necessary and they could maybe design something simpler and better from scratch today. (But it's probably a "not broke don't fix it" thing at this point.)