What's So Bad About Posix I/O?
Some of the claims in this article are total nonsense.<p>The article points out that file descriptors are stateful - they have a current offset associated with them, and I&#x2F;O syscalls update that offset - then claims that this &quot;stateful model&quot; could be a &quot;scalability bottleneck&quot; with &quot;billions of processes&quot; in parallel filesystems.  Except that each of those billions of processes will have its own file descriptor with its own offset!  The only case where this could cause contention is if multiple threads in a single process are trying to read from the <i>same</i> file descriptor, which would be a really bad idea in the first place, precisely because file descriptors are stateful.  Just open multiple descriptors - or use pread&#x2F;pwrite, which have existed for a long time.  Perhaps the process-wide statefulness of many POSIX APIs is a bad design in a world with threads, but it has nothing to do with the concurrent-file-open benchmark in the article, or really any other performance problems with parallel filesystems.<p>Anyway, file descriptors are just per-process handles used for communicating with the kernel.  At least in principle, there&#x27;s no reason that remote filesystems should know or care about file descriptors on the client end, unless clients are using file locks (well, except those aren&#x27;t file-descriptor-based anyway, although they should be).<p>Later, the article claims:<p>&gt; While the POSIX style of metadata certainly works, it is very prescriptive and inflexible; for example, the ownership and access permissions for files are often identical within directories containing scientific data (for example, file-per-process checkpoints), but POSIX file systems must track each of these files independently.<p>[..]<p>&gt; Supporting the prescriptive POSIX metadata schema at extreme scales is a difficult endeavor; anyone who has tried to ls -l on a directory containing a million files can attest to this.<p>POSIX access bits are literally 15 bits per file.  uid and gid are a few bytes.  The overhead of storing these for each file definitely isn&#x27;t what&#x27;s making ls -l slow.  Perhaps there&#x27;s some system where time spent <i>checking</i> them all, at access time, is a bottleneck, but I&#x27;d be very surprised if modern Linux was such a system; that kind of problem sounds easy to solve with some basic caching.<p>The article calls out created and modified times as another part of the metadata, thereby amusingly missing the only one of the three POSIX file timestamps - access time - that actually can cause big scalability issues (if left enabled).<p>Also, apparently the author has not heard of either ACLs, which are in POSIX, or xattrs, which are pseudo-POSIX (multiple systems have roughly compatible implementations based on an old POSIX draft) - both of which try to improve flexibility compared to classic POSIX metadata.  There are problems with both of them, but you&#x27;d think they&#x27;d at least deserve a mention in the list of alternatives.