Do that.  The time taken will, amongst other things, be affected by the number
of levels of indirection in the on-disk datastructure necessary for the file
system to manage the blocks of data in the file.  To me it seems quite feasible
that the extra level(s) of disk access needed to find block X in a 100Gb file
could make the operation (whatever it is ;-) slower.

Don't forget that this will be different according the file system in use.

If (as you say) disk seek time is going to be an issue, and if your application
is (or can be) multi-threaded, then you should get higher throughput by putting
the data on many physical disks.

If (as you hint) IO bandwidth is going to be an issue then it may be worth
considering compressing the data.  In some cases this can be a biggish win.

   -- chris

see http://mindprod.com/jgloss/martha.html

here is an essay I wrote back in the OS/2 days on the idea.

Martha, a new class of disk accelerator software

Martha Stewart is an American TV homemaker whose idea of a
good time is to sort and organize her attic.

So I name this new class of disk accelerator software
after her:

A Martha is a program that runs at low priority in the
background.  It examines the LAST ACCESS date of HPFS
files.  It moves files that have not been used in a long
time to the outer two edges of the disk drive.  This frees
up space near the centre.  As a side effect , it moves
files recently accessed toward the centre.  The net effect
is reducing the head travel to access the current working
set. of files, which might have equivalent effect of a 3
times faster hard disk.

It may be difficult to implement an effective Martha
because I don't think HPFS makes any provision to move a
file in active use by another process.  However, even a
Martha that only worked while everyone else slept could
still be very effective.

Hardware Implementation of a Martha

Not to worry.  This idea is prior art in the public
domain.  I have posted this idea electronically many times
over the last decade.  The BIX electronic conference
maintains a record of all postings.  The idea needs a
small processor in the SCSI disk drive and a CMOS memory.
Its operation is totally transparent to the operating
system.

For simplicity of explanation, I will presume there are an
equal number of sectors in each track.  You "timestamp"
each track into an array indexed by logical track number
stored in CMOS each time you access a track.  This is not
an actual time of day, just an incremental counter.

Whenever the disk is idle, you physically swap tracks so
that tracks that have not been accessed in a long time are
near the outside edges, and ones accessed recently are
near the middle.  You maintain an index by logical track
number translating to physical track number in CMOS. You
also store the logical track number on each track on disk
along with the timestamp so that the CMOS table can be
reconstructed in case it is damaged.  You can make the
thing crash proof by always making the copy before you
update the CMOS table.

The net effect is to migrate the rarely accessed junk
dynamically to the outer edges.  This means that in
practice the disk head will most of the time only have to
traverse a very small part of the entire travel.  No
matter how the disk is logically organized, it moves
toward an efficient layout.

You can even swap tracks on the fly by having a low
priority background process clear out old junk from the
central tracks and schedule any full track write directly
to the freed central tracks, then post a "free" to its old
position in the CMOS table.

I'm sure you can handle the implementation details,
complications and refinements.  The key is, the disk could
be three times faster without any improvement to
mechanicals or changes to the operating system drivers.
It would work better than a "Martha" utility optimising a
single partition since the Adaptec method would work
globally across multiple partitions on the same physical
disk even if they ran under differing operating systems.

Most users are ZIP file packrats and have a ton of
material rarely accessed.  Even active applications have
huge amounts of material rarely accessed -- such as help
files or initialization code.  The effects may be much
more spectacular in practice than you would hope for.

In any case, they would make you look extremely good on
any benchmark!