Jos,
>Hi Jim
>
>Surely your point is partly based on the assumption that the data in the files is randomly created and randomly accessed (retrieved) - such as a client database which grows as clients are added. There are other databases whose data is often accessed sequentially and would therefore benefit from having as many sequential records close together as possible. For instance, we have one app which stores stock market data (trade prices). This data is always required in sequential order and therefore if the file was (a) defragmented and, even better, (b) sorted in datetime order the access speed would be faster.
>
>In other words isn't the question to defrag or !defrag (a file or entire HD) actually case dependent (at least partially)?

If considering ALL possible PC applications, then yes. If considering database applications, I would still say no (though there **might** be individual exclusions possible - they would be rare and very special cases as I see it.

REMEMBER...we have NO CONTROL over fragmentation, so this is all academic.

First, think about how those records in your example would be stored. Since they occurred as time passed, they would be in the 'order' needed anyway, regardless of fragmentation. Now that table likely has a CDX associated with it, and other tables are likely also involved in the application, records being written to those tables during the same period.
So each time one of the subject records was written, all these newer records - those since you last defragged and sorted the specific table - would be written to fragmented space anyway. But more importantly, since you had to defrag the whole volume to get the subject table defragged, so would the newer records in its own CDX as well as all the new records for other tables in the application. So at 'this' point in time you have a largely defragged set of application tables along with a bunch of fragmented records for the whole set of application tables.
Now as the application proceeds, assuming of course that it also has need to inspect and possibly update any of those EXISTING (in defragged areas) records, it faces WIDE head movements across the defragged areas to isolate the required records for the current processing. This is guaranteed in such a case and is worse depending on the number/size of all tables involved.
If, however, you had left ALL tables (and thus the whole volume) fragmented since application inception, you would have the situation I described in my earlier post.

Now there might be cases where a specific task (a report?) was needed to be processed faster than it does (say for an antsy boss wanting real-time reporting on the whole table X).
In such a case it *might* be helpful to make a copy of the relevant table and use that in the report processing, just to meet the boss' anxiety (copied minutes before the boss need the data).
In such a case you should keep in mind that copying it will have impact on the on-going regular processing in the application. And it is best done to a separate partition or HD (to that boss' HD would be best, I suppose) so as to minimize that impact.

It comes down to this: Fragmentations has always been said to be BAD. Apparently, in fact, NTFS takes steps to minimize fragmentation. But WHERE IS THE PROOF THAT IT IS BAD? Especially in today's world...especially in a database application.

It looks strongly to me that fragmentation can be very good, to the point that we would benefit from built-in capabilities to specify/control fragmentation by file and by groups of files.

cheers

>
>Jos
>
>
>
>SNIP
>>With fragmented files, b2.cdx and b2.dbf records would be within a few clusters at most from a1.cdx/a1.dbf/a1.fpt records and from c3.cdx/c3.dbf/c3.fpt records. The chances that RELATED records would be in close proximity are high.
>>
>>Now with contiguous files (defragged to the sequence/layout seen above) a middle record of b2.cdx is about 410 megs away from its b2.dbf record and that record is around 1480 megs from its related a1.cdx record, which is 195 megs from its a1.dbf record, and that one is 525 megs from its a1.fpt record. It is also then 820 megs from its related c3.cdx record, which is 360 megs from its c3.dbf record and that one is 795 megs from its c3.fpt record.
>>
>>In both cases there would be a minimum of 7 head movements.
>>
>>In the case of fragmented files, that head movement would cover a few megs of data at most.
>>In the case of contiguous files the accumulated head movement amounts to covering 4585 megs.
>>Which sounds better to you?
>>
>>Possibly, in the old days, a fragmented file required additional head movements back to the file system area to learn where the next piece is. *IF* that is the case I've just gotta believe that NTFS (at least, and probably FAT too) has been improved to load/keep such information for any "opened" file in RAM by now (M/F systems did, even way back then < s >).