I have to tell you that I don't really think this approach is a great idea. With unix filesystems, it's too hard to to keep a file precisely positioned in one spot. Unix wasn't meant to be used that way. But here are your answers...

In the olden days disks had a fixed geometry. The first track and the last track held the same amount of data. As disk manufacturers chased after greater data densities, they changed things so that the outer tracks now have more sectors than the inner tracks. Some disk optimization papers were written in those olden days. Every thing they say may no longer apply. This is the problem with exploiting disk geometry...it changes and suddenly your hack is now counterproductive.

But in the olden days, since each sector could be read with equal speed, your primary concern was getting the disk heads to your sector. This is why putting the data in the middle of the disk is a good idea. The heads cannot be more than half a disk away. So the mean seek time is as low as you can get it. But this assumes that the heads might be anywhere on the disk. If you can guarantee that the heads are positioned over your data, seek time becomes less of an issue. One way to do this is to use only the outer tracks of each disk drive and ignore the inner 90% of the disk.

If that's not possible, then it will depend on how much data is to be transferred. With large multi-sector transfers, the longer seek time may be compensated by the faster transfer time. The only way to be sure is to try it both ways and benchmark it.

And while you're at it, put the data on the inner tracks and benchmark that. That should be the worst case, longest mean seek time and longest transfer time. This will give you a feel for how little benefit you're reaping from a lot of work.