No, bur for situations where writes are rare and/or tend to be in bulk (so you can perhaps buffer writes to avoid saving partial blocks and use variable sized b

No, bur for situations where writes are rare and/or tend to be in bulk (so you can perhaps buffer writes to avoid saving partial blocks and use variable sized blocks instead of always writing things in fixed-size blocks (though variable blocks implies some sort of index, that would need careful design to not be a massive source of contention particularly during write operations)) that effect is reduced. Everything is still very latency sensitive of course, even for reads, but still potentially usable. You could apply compression to the blocks and use a local S3 implementation so you now have a compressed block device upon which you can apply any filesystem: the S3 implementation will deal with managing the allocation and freeing of space reducing complexity and you now have a read/write compressed store (most compressed filesystems are make-once-then-read-only). Still not most efficient due to the extra layers, but the latency will be much lower due to locality and implementation of each layer is simpler because you need to make each aware of less (in fact you can use a pre-existing implementation for the filesystem and the object store).