2 ms·

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 the

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...

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...