Hacker News Reader

> The open-source client does not emulate operations like directory renames that would require many S3 API calls or POSIX file system features that are not supported in S3 APIs.

At this point I'd probably be fine with using a different API than the filesystem, perhaps one inside of whatever backend language I was using

Feels more fused than mounted

View on HN

Indeed, if you're getting that far away from historical file systems primitives then may as well use an API model that makes senses for the storage backend. Or just contribute direct to rclone and fuse.

You can open an s3 object as a 'file object' in python and it is at least seekable.

Other than that I think you're best to treat s3 as a huge kv store and not a filesystem at all.

Seek only works because the whole object gets downloaded into memory first.

Either that, or the Unix principle of many small files being better than a single big one (without the need to worry about inode exhaustion in S3).

S3 works best with a bunch of medium and similar sized files. It’s really not like a file system.

Reminds me of tape-based storage like the Sinclair QL or Exatron's "stringy floppy". Or Mitsumi's QuickDisk, a format I saw on the Sharp MZ series which is not a disk, but a spiral track that looks a lot like a loop of tape running past RW heads.

Right. Big and slow kv.

Reply on news.ycombinator.com