Align GET requests on 8MiB boundaries

[zrleblanc]

Mountpoint for Amazon S3 version

mount-s3 1.21.0

AWS Region

any

Describe the running environment

Running on EC2 instance Ubuntu 24.04 connecting to a S3 caching solution. Credentials are passed using a local profile.

Mountpoint options

mount.mount-s3 my-bucket --profile my-profile --endpoint-url=http://my-caching-system.com --force-path-style mount-s3/

What happened?

The first GET request for a file is 1MiB in size. Then all subsequent requests are 8MiB in size.
Request 1: 0-1MiB
Request 2: 1MiB-9MiB
Request 3: 9MiB-17MiB
Request 4: 17MiB-25MiB
...
Boto client and every other S3 client always works on 8MiB boundries:
Request 1: 0-8MiB
Request 2: 8MiB-16MiB
Request 3: 16MiB-24MiB
...
Our caching system is caching at 8MiB chunks to match the request size, but the difference in offsets means that there are overlaps between mountpoint-s3 and every other S3 client.

My recommendation is to make the second request 7MiB so that all other requests fall on the same boundaries used by all other S3 clients. This is not causing breaking issues, but like SSD and file system partition alignments, makes things operate much smoother.

Relevant log output

[passaro]

Hi @zrleblanc, thanks for opening the issue. I'll mark it as an enhancement request and adjust the title accordingly, since request alignment is not currently expected in Mountpoint.

Your recommendation makes sense and we are considering it for future improvements to the prefetching logic, although with some additional flexibility to support reads that start at arbitrary offsets, e.g. when starting to read at 5MiB offset:

Request 1: 5-6MiB <- first small request (note: actual size is currently 1.125MiB)
Request 2: 6MiB-8MiB <- adjusted second request to align to part boundary
Request 3: 8MiB-16MiB
...

As a possibly shorter term solution, we are also considering offering the option to disable the initial small request and immediately start downloading in 8MiB chunks. This option would trade off latency (especially on random reads) for some (minor) throughput improvement on sequential reads. Additionally, when reading sequentially from offset 0, it will also result in 8MiB aligned requests. Would such an option be viable for your use case?

[zrleblanc]

Our caching solution works on 8MiB chunk boundaries. So any any partial chunks are fetched in full by our system for the first request. In the normal case right now we get a 1.125MiB request (0-1.125MiB) and we request 0-8MiB from AWS S3. When the client requests 1.125MiB-9MiB, we already have the first ~8MiB in RAM and serve that out in less than half a millisecond. We then request the next chunk 8MiB-16MiB to cover the rest of the range and it repeats.

So being able to disable the first chunk would work, I take the stance that I can't control the clients, so if it's not the default, then I don't expect it to happen. We have defensively programmed against this pattern (and the 70 requests in a single millisecond when it appears to try and determine the bandwidth and basically goes to "infinite", likely due to our system being able to respond so quickly between requests).

This was more of a nice to have in the long run as we are getting ready to put this into wide scale use end of Jan 2026.