On Fri, 5 Jun 2020 at 12:47:33, JJ wrote:
[]
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.

You mean when writing into clear space, it deliberately suddenly changes
before getting to the end of the gap? I didn't know that.

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

I wouldn't even have thought of that! Would only work, though, surely,
if the new gap it moved to was in the same "cylinder"?

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

I'll yield to your E there.

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.

I could see that always using the largest free fragment - especially if
the file size isn't known - would under certain circumstances result in
the size of available fragments reducing faster.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Imagine a world with no hypothetical situations...