Haha I didn’t want to point this example but you are correct
From the statistics I gathered on my node (20TB drive, 14TB used by Storj data) most of the blob files > 2MB have between 2 and 10 fragments. It does not look like a lot but with millions of files it add ups and make the file system table much larger than it should be. The more data is deleted/added the worse it gets
The thing is that if you want to do this correctly it is very OS dependent, for Windows for example it’s a very specific call to create a file of a certain size and ask the system for this file to be reserved on a continues space if possible, even if empty. The default API call create an empty virtual file and blocks are reserved every time you flush data on it.
The default API call is faster because the OS doesn’t look for a continues space.
Again, the cache is not an issue. Fragmentation is.
Forcing Storj to move data between the “temp” folder and the destination cost double IOPs I know but it force the OS to create a files on a single flush (without fragments if possible)