3 ms·

The problem with POSIX file APIs are the semantics in the presence of multiple concurrent writers. Object storage (kind of) gets around this because you can't r

by duped 3y ago

The problem with POSIX file APIs are the semantics in the presence of multiple concurrent writers. Object storage (kind of) gets around this because you can't really have multiple concurrent writers to the same object. Another classic example is that POSIX does not specify what happens when one program opens a directory stream and starts calling readdir/seekdir and then another program adds entries to the directory. Does the first program get entries in its stream for those members? Who's to say, that's up to the file system implementer. I don't actually know if S3 guarantees that if a new stream is created with ListBuckets/ListObjects that the stream will return any new bucket/object created before the stream is closed by the client. Are those semantics defined, or is it left up to the implementer too?

mjb 3y ago
> The problem with POSIX file APIs are the semantics in the presence of multiple concurrent writers. That sure is a problem with the file APIs, but far from the only one. Other issues include weird asynchrony, weird scatter/gather, lack of standard control over exposing parallelism to the device, broken fsync() and fdatasync() error semantics, just enough default buffering features to cause confusion but not avoid most performance bugs, lack of exposing device atomic write units, and many other things. It's an old API we've had for a long time. Made sense 40 years ago. But today it's just too low level to be easy, and too high-level to be fast.