On Wed, 3 Jun 2020 22:39:25 +0100, J. P. Gilliver (John) wrote:

If I understand you rightly, "deliberately" is overstating the case a
teeny bit: not deliberately fragmenting, just not moving to the first
huge gap when writing starts. Again, not practical for
continuously-growing files, like a recording. Or log, though those _are_
usually smaller.

I _can_ see the advantages for certain kinds of use.

No, I meant deliberately fragmenting the file. I could understand when the
driver might choose a non optimized starting cluster for a new file, because
it doesn't know how big the file can be. What I meant is that when a file is
growing and the next cluster is still free, the next appended data is not
written into that next free cluster. Thus, fragmenting the file.

The only reason I could think of as for why it behaves like that, is for
performance - by minimizing the HDD actuator movement.

As for the starting cluster of a new file, IME, in most cases, it chooses
the next cluster of the previously written cluster - no matter which file
owns that cluster. Instead of choosing the largest free fragment. And only
if the next cluster is already occupied, it would either choose the first
free cluster - even though it's not in the largest free fragment.