<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://www.smartphonemag.com/cms" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>Smartphone &amp;amp;amp; Pocket PC magazine - Comments for &quot;Regularly defragment your built-in File Store!&quot;</title>
 <link>http://www.smartphonemag.com/cms/blog/9/regularly-defragment-your-built-file-store</link>
 <description>Comments for &quot;Regularly defragment your built-in File Store!&quot;</description>
 <language>en-US</language>
<item>
 <title></title>
 <link>http://www.smartphonemag.com/cms/blog/9/regularly-defragment-your-built-file-store#comment-2294</link>
 <description>&lt;p&gt;Nope, those results have been all measured in the ideal (non-fragmented) case. In fragmented case, they may have been much more different. That is, the only show the effect of the actual file system used in a FS to give a hint on the differences caused by different file systems - in the optimal case.&lt;/p&gt;
&lt;p&gt;As it&#039;s almost impossible to reliably and reproducably repeat the tests with heavily fragmented FS&#039;s so that the results are comparable, i haven&#039;t made quantitive tests of the latter. I do think, however, than 512-byte blocks would have performed much worse than, say, 4 kilobyte-ones. I&#039;m not 100% sure, of course - that&#039;s only the case if my theory is right about the fat constantly upgraded during a file copy.&lt;/p&gt;
</description>
 <pubDate> <key>pubDate</key>
 <value>Sat, 11 Feb 2006 22:16:41 -0600</value>
</pubDate>
 <dc:creator> <key>dc:creator</key>
 <value>Werner Ruotsalainen</value>
</dc:creator>
 <guid> <key>guid</key>
 <attributes> <isPermaLink>false</isPermaLink>
</attributes>
 <value>comment 2294 at http://www.smartphonemag.com/cms</value>
</guid>
</item>
<item>
 <title></title>
 <link>http://www.smartphonemag.com/cms/blog/9/regularly-defragment-your-built-file-store#comment-2292</link>
 <description>&lt;p&gt;The cause for the speed degradation with heavily fragmented FS&#039;s is very simple - 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).&lt;/p&gt;
&lt;p&gt;It seems the FAT table is written to only once if there&#039;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.&lt;/p&gt;
&lt;p&gt;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). &lt;/p&gt;
&lt;p&gt;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 &lt;b&gt;so&lt;/b&gt; fragmented), then, the file copy will really slow down â€“ in my case, easily to the 1/30th of the original, defragmented/freshly formatted speed.&lt;/p&gt;
&lt;p&gt;I&#039;m just making the WM5 fragmentation tests. Will keep you posted as soon as they&#039;re all done. It takes some time because I also test whether WM5 still slows down when the WinCE databases are full (the case of, say, synchronizing thousands of Outlook mails to the Pocket PC via ActiveSync).&lt;/p&gt;
</description>
 <pubDate> <key>pubDate</key>
 <value>Sat, 11 Feb 2006 14:47:54 -0600</value>
</pubDate>
 <dc:creator> <key>dc:creator</key>
 <value>Werner Ruotsalainen</value>
</dc:creator>
 <guid> <key>guid</key>
 <attributes> <isPermaLink>false</isPermaLink>
</attributes>
 <value>comment 2292 at http://www.smartphonemag.com/cms</value>
</guid>
</item>
</channel>
</rss>


