"polygonum" wrote in message
...
On 28/03/2016 10:02, 764hho wrote:

And it doesnt really matter if those log files do get quite
fragmented, because they are hardly ever read from end
to end except when browsing them, when you reading
much more slowly than the file can be read anyway,
so extra seeks between fragments dent matter at all.

Unfortunately, in my experience, it can matter.

Not very often when fragmentation of them matters tho.

One particular application I used to deal with had such files. And they
were regularly accessed. The difference achieved from a simple move of
such a file was often very obvious to a user.

Then the use of that log file was done badly. It should have
been properly indexed so that there was no need to access
the entire file serially and so see the extra head movements
that fragmentation produced.

It can also matter because in time, as other files are created and
deleted, the fragmented log file can mean that any free space is
fragmented.

Sure, but with some linux file systems the free space is deliberately
fragmented
to minimise the fragmentation seen with files that grow over time.

One area of NTFS I have either forgotten or never read up is how it knows
where fragments of files reside. Based on another file system which I did
know well, there was a file which contained lots of records something
like:

File number ! Fragment number ! Starts at block ! For so many blocks

In that old system, locating the block required shuffling through this
file and counting. The amount of work this required was very closely
related to the number of fragments and hardly at all to the absolute size
of the file. To find the last block of a severely fragmented file would
require reading through lots of these small records. (Of course, some or
all of this might be cached - though probably not then. This file would be
a prime candidate for holding in memory.)

It isn't like that with NTFS.