You did IIRC, was actually trying spark recollection of previous exchange, and you're welcome.I have argued before netbooks & old PC's are performance is fine, same as tablets, for everyday web, email, spreadsheets, video, music, etc... but I agree we need not vector off here.
The rest inline... On Fri, Aug 9, 2013 at 5:59 AM, Thane Sherrington <[email protected]> wrote: > At 05:25 PM 08/08/2013, Joshua MacCraw wrote: <snip> > >> Because mydefag does not do exhaustive defrag, because multiple passes >> produce varying landscape even so the files themselves DO end up >> defragmented (and in their zone) even if not totally sorted within the >> zone optimally assuming the correct logic and options are applied by the >> MYD script writer and sufficient free space to move in. > > > But it's not just MyDefrag that does this. Every program I've tried will > move files on repeated defrag passes, suggesting that it wasn't done > properly the first time. Perhaps that's just Windows creating fragmentation > continuously, but if that's true then that decreases the value of > defragmentation. > > I'm going to give MyFragmenter a shot and see if I can actually benchmark an > improvement. I'd be happy to be proven wrong on this. No simple answer for you, if you do a MyDefrag script that does a "Defragment()": A file will be contiguous BUT there will be gaps between files and files will not be grouped/sorted in any way. Run it again & nothing should move on an otherwise static volume because there is no fragmentation. Still there are gaps so add/modify data could result in fragmentation which running the script would show. Take the exhaustive approach to make zone, sort, defragment, compact, & add gap for groups of files. For example "C:\Program Files" defragged into a zone, sorted by full path+filename results in contiguous, stacked end to end files with buffer gap padded to the end for future growth. Yes, the end of zone would fill over time with both zone member & non-member file fragments. Yes, add/change of zoned files could move fragments outside the zone and/or create gaps. Point would still be that unchanged in zone stay optimized, add/modified can quickly be brought back into the zone, same for moving non-member fragments outside, and if buffer gap is big enough the zone following would not need to be disturbed. Over time or excessive data churn this process would have to be done from scratch but monthly or longer intervals while faster clean up scripts maintain order on a more frequent rotation. The more shortcuts you take, the faster the a defrag runs but the more likely you are to see things continue to shuffle pass after pass depending on the a scripts criteria. The why is gaps, files that contiguous space couldn't be found for (within selected limits) on previous passes, and back fill/shuffle efforts. So best effort vs. completeness to save time is the balance, strategy for which is being chosen in most cases by other defrag software automatically using hidden logic. The persistent value is that for little effort after initial optimization it's easy to maintain and does shave time multiplied by huge amounts of access. Measurable? Don't know how but it is obvious under uses I stated and can speed up windows *IF* sufficient amounts of regularly accessed system files have fragments scattered at extremes. To test that my guess would mean tracking perfmon variables related to Disk I/O.
