|
Originally Posted by Howard2k
|
Thanks.
I believe you do this for your love of technology, not for huge sums of money. So don't be offended but what I'd REALLY like to see on this subject is:
* A well fragmented file system documented by the Windows storage tools showing both statistically and graphically the fragmentation of the storage card.
|
That's a nice idea! I'll definitely do some tests like this as soon as I have some free time!
|
Quote:
|
|
Lastly - some technical explanation why we're seeing a difference in performance. If there is no mechanical seek time, what IS causing such an obvious difference in speed?
|
My theory is the following: "if you copy a new file in a fragmented place, the FAT table seems to be written to without any kind of caching, unlike with the case of sequential writing (when it suffices to flush the new FAT addresses only once).
It seems the FAT table is written to only once if there's no fragmentation (that is, the consequent clusters are written to in a row); if there is, however, fragmentation, the operating seems to write to the file system when it needs to skip some memory area allocated to some other file.
This is really a pain in the back, particularly if the cluster size is small (say, 512 bytes - the default with a lot of FAT32 systems).
Think of it: if you copy a 100 kbyte-long file to a heavily fragmented memory and the FAT-based memory controller needs to write to new address information after transferring, say, every 512 bytes (the memory is so fragmented), then, the file copy will really slow down – in my case, easily to the 1/30th of the original, defragmented/freshly formatted speed."
I may be completely wrong though about this. Still, the above theory seems to be prolly the best fit, as far as the technical reasons for this behaviour is concerned.