TUTORIAL: Defragment (reformat) your built-in File Store from time to time!
I haven't ever formatted/initialized my File Store ever since I've bought my Pocket Loox 720 (some 14-15 months ago) and, when I started making some explicit tests to see how fast it is, I was really frightened to see it was about 30 (thirty) times slower to write to than after a reformat. Indeed it's worth reformatting the File Store in order to gain back the lost speed!
While nobody would dispute the fact that formatting makes a difference, I didn't see any hard firm numbers showing the differences in performance on a fragmented file system vs. an unfragmented file system.
Are they there somewhere?
__________________
Always read stuff that will make you look good if you die in the middle of it.
While nobody would dispute the fact that formatting makes a difference, I didn't see any hard firm numbers showing the differences in performance on a fragmented file system vs. an unfragmented file system.
Are they there somewhere?
Well, I have done quite a few benchmarks with both the above-mentioned Loox - the 30-times speed difference, for example. I've also made intentional fragmentation by copying hundreds of small files into my iPAQ 2210's FS, deleting half of it, recopying, redeleting some other half of it, and then, benchmarking the copy a big file to the above-way fragmented FS.
You can also try the same - just benchmark a long (at least 15-20 Mbytes in size) file transfer over ActiveSync to the File Store; then, defragment the filestore and do it again. Most probably, you'll see a performance (speed) increase, which can be pretty dramatic if your FS was heavily fragmented.
BTW, I've updated the article in the meantime - simply moving all the files to, say, your desktop computer and copying back will do the trick. You don't even need to format the File Store.
EDIT: sorry, my second word should have been 'have', not 'haven't' - I haven't read the answer before senfding it
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.
* Copy a large file to the storage card - as you said, perhaps through AS is good enough.
* Further documentation on the storage card, paying special attention to the location of the new large file and the updated statistics. It should be graphically present on the storage tools windows.
* Then a comparison of the file being copied to a blank (and therefore unfragmented) storage card.
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?
I don't have a card reader, otherwise I'd be more than happy to do this myself. There seems to be so much confusion about this whole thing it'd be great to get some clear and firm answers, and I think you're ALMOST there. :)
__________________
Always read stuff that will make you look good if you die in the middle of it.
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.
You're correct about the FAT entries. Each fragment would have its own entry. That's certainly true. I don't know if it would cause THAT much delay though.
It'll be interesting to see if you have the time :)
__________________
Always read stuff that will make you look good if you die in the middle of it.
Follow Us
RSS Feed
Follow on Twitter
Facebook
YouTube
Uber Member
Addicted Member
