On Wed, 9 May 2018 10:04:34 +0200, R.Wieser wrote:
JJ,

Obviously, the one which is fragmented, would take longer to
read the whole file data.

Not quite obviously I'm afraid. I think we may assume that an SSD is
random access. That means that the time between reading two sectors next
to each other does not take more time than reading two sectors far apart.

... has zero seek time ...and it contains 2 files occupying the same
number
of clusters. One file is not fragmented, and the other has 1 million or
more
fragments.

That depends: Are you requesting the sectors one-by-one, or are you doing a
bulk request ?

You see, in the first case any kind of SSD-induced delay will be rather
unnoticable even in regard to the request itself - let alone in regard to
the ammount of returned data.

In the second case you are cheating, as there AFAIK is no way for the
computer to request a non-sequential set of records. :-)

Besides that, what do you think is the chance that the SSD will try to
predict the next sector you will want to fetch and pre-cache (into RAM,
because SSD storage memory is rather slow) ?

In short, while its busy returning the requested sector it will also be busy
pre-resolving the most likely next requests - effectivily reducing the delay
you're referring to to zero for whomever is looking at the returned sectors.

Regards,
Rudy Wieser

I think you misunderstood. I'm not talking about the storage device, storage
controller, or bus speed, here. I'm talking about the file system. If the
file is not fragmented, the system doesn't need to determine the next
cluster number, when reading a file for e.g. copying. i.e. when reading
data, it only need to increase the next cluster number by one, each time. If
the file is fragmented, it needs to determine the next cluster number from
the cluster allocation list of the file (if NTFS, otherwise from FAT).