Thread refresh

SRE graph scrying test:

I'm backing up a bunch of files to S3, there's moments where the throughput goes down and moments where it goes up.

Assuming no network activity in a way that matters, why would the throughput number be going up and down like this?

@cadey The numbers going down mean lots of little small files. Going up means big long transfers.

@glitchf Correct!

@cadey @glitchf some of the better s3 tooling (eg rclone) have ways to mitigate this via more concurrency

@cadey disk go brr vs disk go 🥶?

@luciano What makes you think that?

@cadey @luciano
on a side note, it might be close being correct. A drive can show this access pattern at some point of us life, usually before death.

Here's your unscheduled reminder to check if smartd is configured properly)

@Mikle_Bond @luciano I mean I'm also doing a ZFS resilvering because a drive died lol

@cadey is there some kind of rate limiting or throttling going on?

Kinda reminds me of https://www.schneems.com/2020/07/08/a-fast-car-needs-good-brakes-how-we-added-client-rate-throttling-to-the-platform-api-gem/

@Schneems Nope! The remote service (which is like S3 but not S3) is able to accept data at my NAS' line rate, and my drives are able to supply data also at line rate.

@cadey super weird.

@Schneems Biblical amounts of small files, there's more overhead in creating lots of little files than there are creating very few big files

@cadey @Schneems
The difference in throughput becomes even more drastic with SMB on windows and even more educational.

@cadey lots of small files vs small number of big files?

@andrew Correct!

@cadey a LLM is generating `aws s3 cp` commands for each file and different filenames (presumably that parse into more tokens) take longer for the model to generate commands for

@cadey Copying kernel source or some similar pile of tiny files?