I could also use NTFS, if it works much better. However, my preference is for exFAT, because then I can write to it from Linux as well, without needing to partition it. That might be a lazy argument, though.
So I would expect lots of around 16MB and smaller files. Anecdotally that’s what I see when poking my head into a random ../data directory in a mature repository.
You could tune for larger pack sizes, and that might be worth it for your big multi TB repository, but there are some potential “gotchas” to go along with that; the doc page I linked above has details.
However, my preference is for exFAT, because then I can write to it from Linux as well, without needing to partition it.
NTFS is a better choice for accessing it from Windows, worse when accessing from Linux. Unless you specifically need to access the repository from both OS though, picking a filesystem native to the OS you’re using is the optimal choice IMO. Otherwise, exFAT seems the least bad option for dual OS access.
If you really want to optimize it, start with the lowest allocation size, run a test without compression and time it. Do the same with the next allocation unit size up. You’ll likely see a trend where the smallest ones are slower, with bigger ones netting more speed - up to a point. Then it will stay about the same. That point is what you want. Larger allocation units waste space. But the speed boost in the sweet spot is worth it.
Restic may not be fast enough to saturate the speed - if so, use something like CrystalDiskMark instead.
I realized, while accessing the drive from Linux, I do so from WSL2 via drvfs (9P). That works totally fine with NTFS. No need for exFAT then.
With that in mind, I just switched the drive to NTFS, and I got an unexpected performance boost. Compared to exFAT, backup speed almost doubled. I am talking about backing up a 176GiB Windows directory using restic.exe.
For anyone reading this thread in the future 16384 kilobyte allocation size may sound like a good idea because its exactly 16 megabytes, however usually the packfiles are a tiny bit over 16Megabyes and still take two allocation units each.