>SNIP
>>
>>Can you give any references and/or URLs to back up this POV? I've never seen any discussion that concludes that on-disk file fragmentation is a good thing.
>
>I can't, Al, because as I said, it's *my* opinion.
>
>I did succeed in showing the equivalent in a mainframe system many years ago, where there is reasonable control capability regarding fragmentation. There, in a nutshell, I showed that average job elapsed times were decreased significantly when purposely fragmenting (only 'temporary') files conpared to running the same jobs with contiguous space allocations. Temporary files are heavily used in M/F processes
>This was done by taking a number (around 100) of jobs that ran concurrently (between 6-10 partitions (which are 'run units' in M/F, not HD space)) in the midnight to 0800 shift. All jobs were changed from their regular contiguous space specifications to allocations of 10% (of regular) as primary and 10% as secondary. All other factors were left alone (scheduled starts, dependencies, etc.) and the last job finished just over an hour earlier than previously observed. The jobs were left that way.
>
>As I said too, because there is no way to control fragmentation in any way in PC systems (at least of the MS variety), the best one could really do is to laissez-faire, letting the natural fragmentation happen and not disturbing it.
>
>FYI, that wasn't the first counter-intuitive thing that was implemented in that shop. A much harder (and earlier) battle was convincing the Operations Dept. that cutting their partitions ('run units') from 15 to 6 would result in faster processing of the full workload. Once they finally agreed to try they were astounded to find that they gained more than 1.5 hours buffer in their critical 'window'.
>
>cheers

Hmmm... I'd be hesitant to extrapolate results you got on a mainframe "many years ago" to modern environments.