Nevermind. It's Been Fixed.

[frobnoid_]

"cp -pr" will indeed copy a filesystem. The snag is that it doesn't understand symbolic links, so if you have say
  libsomething.so, libsomething.so.1, libsomething.so.1.1
where the two former are a soft link to the latter, when you do the copy you'll end up with three files, not two.

tar is often the best way to copy a file system, as it can not only preserve ownership but also symbolic links:
  cd olddir
  tar cf - . | (cd newdir ; tar xf -)

cp -d will not dereference symlinks, that is, if the input is a symlink, the output will also be one.

[neuroshock]

Cybersphinx,

I just got back from a Christmas shop-a-thon with my daughter. I'm completely exhausted and headed for bed. I gave reading through your reply's a shot but with the formatting awry it just made my head spin trying to decide who said what, when, and where. Don't feel bad though the Quote bug has bitten us all a time or three.

I'm pretty confused on most of the questions and replys as sometimes what you say in your question seems to agree with what I said in the previous statement even though that would seem contradictory.  Several of the questions you posed are just a matter of clarifying as we're approaching the same beast from different ends.

There are a few things that jump out at me though. As you pointed out you are definitely correct in the generalization that the IDE controller is blind to partition Priorities as that is indeed handled by the OS and drivers.  I didn't proofread well enough and included that inside of the discussion about physical geometry limitations and head travel speed performance hits etc.  Rather that should have been specified as to being an exterior limiting process- that is indeed a facet that would NOT be a bottleneck of the IDE controller but rather a performance issue related more to the software of the drivers/OS but the overal mechanics are still the same and the priortization problem still exists and therefore the overhead that it creates very real nonetheless.

Um also I stand by the Extended partition track statement.  Since as far back as 1992 I cannot remember ever finding a single computing device that used an IDE HDD device with an extended partition on track one. With modern linux/unix variants I suppose it is possible but because of the overhead noone would intentionally do this. Yes, you might gain a meager speed boost by having an extended partition on track one just so that you can say you did it but you'll lose even more performance by introducing a Logical partition in that position for all the reasons I already stated. Theoretically yes. Real world - never. If you were correct and this would fix the performance issues it would be found everywhere.

Oh and the key word from your quote from the wikipedia is "current".  Really- try data transfers from Master to Slave vs Master to Master yourself. (oh and btw Master and Slave truly do NOT appear in the specs but they still appear on ANY IDE HDD you can buy on the market today.  It's an industry standard term recognized by every manufacturer in existance.) The proof is in the pudding.  The other piece of the "current" issue is that modern IDE controllers can usually be set up to a Cable Select arbitration. But IF the OS drivers cannot establish a Cable Select arbitration sequence then the Primary Drive's controller then does all translation services for BOTH HDD's. (Ever wondered why the jumpers were there on the IDE drives to choose between Master and Slave to begin with?) If indeed IDE controllers were completely serial as the partial Wike quote stated why would we need a Master and a Slave to begin with? The Wiki quote is a generalization on "current" devices.  But the IDE spec itself has default backward compatibility back to day one and when Cable Select arbitration doesn't pan out, (and it STILL often doesn't  - Maxtor and HP drives STILL many times will not Cable Select properly and make you end up manually jumpering one to Master and the other to Slave) we immediately get bumped back to "non-current" times.  Then my argument applies. Oh and this applies 100% of the time to Microdrives- ever wondered why manufacturer's can't put two Microdrives on one CF controller?  Because there IS no CS option - it MUST be setup as Master and Slave - and the Master/Slave performance hit makes performance between them so abysmal it's smarter to just add a second CF controller/slot.  Good quote- but only correct within the terms ("current") that it specifies. The best microdrives on the market still are only now adhering to ATA-33 standards. Sad huh? Nothing "current" about Microdrive implementations in a Zaurus.


Um we do know what tracks are the fastest as an OS is almost always installed on a fresh disk, and all disks start writing at the first track regardless of translation and continue writing to consequetive sectors unless it needs to fragment them because other files are in the way - and on a fresh disk there ARE no files to be in the way to start with. So Primary partition one and File one always sit on the first track. Always.

As for the rest of it, as I encouraged readers before- test these performance issues yourself in real world situations. Each and every one I listed is nothing new, very real, and easily repeatably tested and verified.  Old school stuff in the extreme.  Introducing theoretical exceptions are fine, but they are scenarios that are simply not encountered in modern computing.  Performance tests will bear out each and every  issue I discussed.

If my simple claim that performance can be increased by placing the most often used data and swap partitions in Primary partitions is incorrect, then I am in good company, since as of the time of this writing I do not know a single developer nor computer manufacturer or handheld computing device manufacturer  that do not configure their machines in this same manner in order to provide their user base with the fastest possible performance.  Real world performance testing and the Real World implementations of these technologies of the entire computing community support my claims. We may be wrong, but if we are then it's definitely pandemic. =)

Oh well, I'll try to give a more detailed response later when I'm not so tired and my head is clearer. I may just leave it as it is since the topics are so well known and such common knowledge issues that they pretty much stand on their own. They're somewhat like gravity. Nobody likes it, it can be painful as heck, but in the end after you've tested it six-ways-to-Sunday you just can't ignore the fact that it exists.

G'nite All,
-NeuroShock

Bam,
Sorry, almost missed your post. I would think you could put a directory/file on a Swap partition using a similar loopback device as you could with any other formatted partition. It's somewhat a mute argument because the only scenario I could think of wanting to do that would be if you needed more space for storage etc. and you prooobably wouldn't ever have a swap partition to begin with unless you felt you had enough space to justify creating one. Otherwise you would implement a Swap File instead.  Also creating a loopback device on top of a Swap Partition would inflict the performance hit of all loopback devices and therefore degrade the performance of the Swap Partition - and of course the reason for the Swap partition is to increase performance to begin with so that would be counter productive. Cool idea though, and I guess if under normal conditions the loopback device wasn't being accessed it wouldn't inflict hardly any noticeable performance degredation! Nice idea, and sneaky too. I like it. =) You've got a sharp mind bro.
But I assume it IS possible if someone knew how to code it properly (and THAT is WAAAY out of my league!)
Oh also you may wish to update your site with my edited post above rather than the original. I edited for clarity to address the fact that the OS and drivers held the blame for some of the routing issues (primary drives over extended) rather than the IDE HDD controller being solely to blame - as pointed out by Cybersphinx.
Be Well!,
-NeuroShock

[cybersphinx]

There are a few things that jump out at me though. As you pointed out you are definitely correct in the generalization that the IDE controller is blind to partition Priorities as that is indeed handled by the OS and drivers.  I didn't proofread well enough and included that inside of the discussion about physical geometry limitations and head travel speed performance hits etc.  Rather that should have been specified as to being an exterior limiting process- that is indeed a facet that would NOT be a bottleneck of the IDE controller but rather a performance issue related more to the software of the drivers/OS but the overal mechanics are still the same and the priortization problem still exists and therefore the overhead that it creates very real nonetheless.

OK, so I read that wrong - but I still think there is no performance impact in using extended/logical partitions instead of primary ones, at least not in principle. There might be operating systems (DOS etc. comes to my mind here) where access to a logical partition has to wait for access to a primary partition to be finished. I am pretty sure Linux isn't that braindead.

Um also I stand by the Extended partition track statement.  Since as far back as 1992 I cannot remember ever finding a single computing device that used an IDE HDD device with an extended partition on track one. With modern linux/unix variants I suppose it is possible but because of the overhead noone would intentionally do this. Yes, you might gain a meager speed boost by having an extended partition on track one just so that you can say you did it but you'll lose even more performance by introducing a Logical partition in that position for all the reasons I already stated. Theoretically yes. Real world - never. If you were correct and this would fix the performance issues it would be found everywhere.

Well, I think people tend to stick with what works, and thus some myths (which might once have been true) live far longer than they should. I don't have a microdrive (except a broken one) at the moment, else I'd test it: Make the whole drive one partition, and then test in every way I (or others) can think of. I am pretty sure there will be no difference in performance. Hm, perhaps I can test this with an old computer here when I find the time. If you want me to test something specific, just tell me.

Oh and the key word from your quote from the wikipedia is "current".  Really- try data transfers from Master to Slave vs Master to Master yourself. (oh and btw Master and Slave truly do NOT appear in the specs but they still appear on ANY IDE HDD you can buy on the market today.  It's an industry standard term recognized by every manufacturer in existance.) The proof is in the pudding.  The other piece of the "current" issue is that modern IDE controllers can usually be set up to a Cable Select arbitration. But IF the OS drivers cannot establish a Cable Select arbitration sequence then the Primary Drive's controller then does all translation services for BOTH HDD's.

But cable select is just to determine the master and slave roles depending on where on the cable the drive is connected, instead of using jumpers to do it. If the cable select doesn't work, then the master/slave roles will be undetermined and it's pure luck if it works. When cable select works, then the drive on the master plug of the cable will be the master, the same as when it's jumpered to master.

(Ever wondered why the jumpers were there on the IDE drives to choose between Master and Slave to begin with?) If indeed IDE controllers were completely serial as the partial Wike quote stated why would we need a Master and a Slave to begin with?

To distinguish the two drives, to give them addresses. The same as with SCSI, where every device needs an ID to be addressed.

The Wiki quote is a generalization on "current" devices.  But the IDE spec itself has default backward compatibility back to day one and when Cable Select arbitration doesn't pan out, (and it STILL often doesn't  - Maxtor and HP drives STILL many times will not Cable Select properly and make you end up manually jumpering one to Master and the other to Slave) we immediately get bumped back to "non-current" times.  Then my argument applies. Oh and this applies 100% of the time to Microdrives- ever wondered why manufacturer's can't put two Microdrives on one CF controller?  Because there IS no CS option - it MUST be setup as Master and Slave - and the Master/Slave performance hit makes performance between them so abysmal it's smarter to just add a second CF controller/slot.  Good quote- but only correct within the terms ("current") that it specifies. The best microdrives on the market still are only now adhering to ATA-33 standards. Sad huh? Nothing "current" about Microdrive implementations in a Zaurus.

OK. Perhaps the IDE implementation in the Zaurus is not current, and I don't know the specifics of CF cards etc.

Um we do know what tracks are the fastest as an OS is almost always installed on a fresh disk, and all disks start writing at the first track regardless of translation and continue writing to consequetive sectors unless it needs to fragment them because other files are in the way - and on a fresh disk there ARE no files to be in the way to start with. So Primary partition one and File one always sit on the first track. Always.

Well, I was a bit confused about the track issues when writing (and you also have it slightly wrong). I guess we can agree on the following: Regardless of where the tracks are actually placed on the platter, what the OS sees as first track is on the fastest area on the disk (doing it otherwise would be possible, but that's a rather theoretical point).

As for the rest of it, as I encouraged readers before- test these performance issues yourself in real world situations. Each and every one I listed is nothing new, very real, and easily repeatably tested and verified.  Old school stuff in the extreme.  Introducing theoretical exceptions are fine, but they are scenarios that are simply not encountered in modern computing.  Performance tests will bear out each and every  issue I discussed.

"Old school" - sure there are no myths or traditions in between?

If my simple claim that performance can be increased by placing the most often used data and swap partitions in Primary partitions is incorrect,

I think it is. Like I said, I don't have a microdrive here, only some older parts to build a testing computer from (but that'd need some time).

then I am in good company, since as of the time of this writing I do not know a single developer nor computer manufacturer or handheld computing device manufacturer  that do not configure their machines in this same manner in order to provide their user base with the fastest possible performance.  Real world performance testing and the Real World implementations of these technologies of the entire computing community support my claims. We may be wrong, but if we are then it's definitely pandemic. =)

I think it's tradition to put the system in a primary partition, since that's the only thing DOS supported (and the first tracks are usually the fastest). Else why'd you bother with logical partitions at all (if you don't need more than four partitions)? Just make some primary partitions instead of the logical ones for non-system drives.

Bam,
Sorry, almost missed your post. I would think you could put a directory/file on a Swap partition using a similar loopback device as you could with any other formatted partition.[div align=\"right\"][a href=\"index.php?act=findpost&pid=107681\"][{POST_SNAPBACK}][/a][/div]

Not possible. A swap partition has no file system, so you can't put files on it, and you'd need a file for a loopback device.

cybersphinx

[bam]

hmmm, bummer, was hoping to set up a swap partition but I believe that the z needs the files on hdd1 to operate properly, but I will double check.

[neuroshock]

hmmm, bummer, was hoping to set up a swap partition but I believe that the z needs the files on hdd1 to operate properly, but I will double check.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=108374\"][{POST_SNAPBACK}][/a][/div]

     He's incorrect concerning the Swap Partition. A Swap Partition must have a format like any other partition even though it's rudimentary in comparison. Even if the partition only has one file as he is inferring the file must still be addressable. If indeed the scenario you were hoping for was as you mention above then you are still correct that it won't work even though Cyber is wrong. IF you could install the file at all it would only be through a loopback device and loopback devices do not get initialized usually until much too late in the boot process to accomplish your goal. Even when they do get initialized they of course are given a unique device identification by the OS and since it cannot be hda1  because that identification would already be taken it would never work anyway.  From outside the folder before the loopback is initialized the files in question would just be jibberish.  Still sharp thinking to have contemplated the idea to begin with but in the end....still bummer. You're right it would have been a cool way around the Partition situation on the C3100.

     As for the rest of Cyber's replies - Please. Do us all a favor and grab C3100, C3000 (whichever you own is fine) and a  3, 4, or 6gb Retail Hitachi Microdrive and make yourself a script to do thorough benchmarking.  Then take your script, process, and results and post them here so that others can see your results and can easily verify that your testing process has integrity and that your results are duplicatable. I know you truly honestly believe I am completely off my rocker with every claim I've made and that all of the reasons that the computer industry still does these things is because we are mired in tradition and habit. But until you can illustrate otherwise there's no point in replying to every patient reply and explanation I make that you once again "think" I'm wrong. I'd love for you to catagorically prove me wrong and in doing so allow me to get ahold of the performance gains for myself that you say can be had by placing our most used partitions on loopback devices located on extended partitions that themselves sit on logical partitions with a physical location late on the physical drives geometry.

     Besides - if your benchmarking bears your claims out then I won't have to rework the awkward partitioning strategy that Sharp has forced upon me once we know how to get rid of the dependence on the first two vestigial partitions - if it turns out that way I'll already HAVE the optimal performance setup and can relax that I'm already as optimized as I can be. But you won't. About the best result you can hope for is to demonstrate while your way DOES cause a performance hit, it is minimal enough that most people aren't heavily affected. But as for me - every little bit of performance that I can squeeze out of my Zaurus is worth the effort. Especially when its just a matter of partitioning.

     Throughout this thread I have very carefully replied with post after post patiently and as clearly as possible I have explained how these issues directly affect Real World performance on our Zaurii as well as gone into enough detail that anyone could follow the history, development, implementation, and Zaurus specific software/hardware issues that are at the heart of the problem. My explanations are sound, well presented and reflect my own experience as a robotic engineering technician in a manufacturing facility that did (and still does) fabricate proprietary commercial computing devices that are centered around ATA IDE HDD's and the experience of the engineers that designed these devices.  We worked directly from the recommendations that were presented to us by engineers from IBM, Seagate, and Quantum who actually designed the drives themselves. The claims I've made are also validated by EVERY associated manufacturer in the last decade.

     Despite all this you still believe that I'm absolutely - almost catagorically wrong in regards to each and every one of them.  Believe it or not, I actually don't have a problem with this at all – you are of course entitled to your opinion.  What I DO have a problem with is that members with less experience will inevitably stumble across this post and in their desire to better the performance of their Z's they may be tripped up into being completely misled by someone who simply disagree's based upon untested theories and who offers a vigorous argument to the contrary and singlehandedly stands in opposition to every manufacturer, engineer, and benchmark that has been established concerning IDE ATA-33 device interface since its inception as well as everything currently known in the community about how the device is integrated with Zaurii. This runs completely counter to the reason that these forums exists - we are here to help other users by sharing proven facts and realistic solutions to Real World problems. If it were not for this I would have quit posting in this thread quite a while ago, but it's the junior members who'll be hurt by misleading claims not the senior experienced ones and I remember all too well how often I was tripped up by similar sincere but incorrect claims during that steep learning curve we all went through as a new Zaurus owner!

     So please, before you repost time and time again on a subject matter that is well established in the community that you disagree with please take the time and make the effort to do the benchmarking, find Engineers, Technicians, Manufacturers, personal life experience, or SOME form of factual evidence to support such a broadsweeping claim that everyone in the industry is wrong because they are myopic and mired down in tradition and historical "habit".  It's one thing to make a claim against a theory or idea someone is presenting that is yet unproven. It's quite another to single-handedly defy every bit of conventional wisdom regarding a well documented and researched field and then back it up by saying that you know for sure that they are wrong and backing yourself with a theory you've postulated but never tested even for yourself.

     You may be right. You very well may indeed be the next "David" that slays the tradition-bound "Goliath" with his theoretical "sling".  Just remember - David couldn't have done it without a stone. Get your Zaurus, Get your Hitachi Microdrive, Make your scripts, do your benchmarking, post your process and controls and then your results so they can be checked for integrity and found duplicatable.  Alternately find a Manufacturer, a IDE Design Engineer, or SOMEONE from a creditable background that will verify your claims in each of these areas and have them present evidence that as a whole the industry has been sincerely misguided in their conclusions. But until you can and do, we'll just have to go with the hardearned knowledge we currently have.

     To YOU the reader of this thread and post - as I urged in my first posting. If you wish to learn more concerning these issues you can find much of it right here on the forums just by doing simple word searches. Bettery yet choose one of the several techniques that are also well documented on the forums here to test drive and processor/system performance in the areas related to the issues in this thread.  Share your process with others here on the boards so they can also help to check and make sure your process was clean and then let the results speak for themselves.

      I've exhaustively and as clearly and as patiently as possible explained, defined, and clarified every aspect and angle of the performance issues I originally presented. If I have not been clear enough or if my explanations lacked logic or reason then I present my sincerest apologies to the community here. I have honestly given the best effort possible to illuminate the facts and present factual, reasonable evidence on this subject. Regardless I offer it freely to all with the hopes that some may benefit from it.  I was quite excited at the beginning of this post when the opportunity presented itself for me to be able to share pertinent information that would actually help others in a real and tangible way. I am very weak in so many other areas (programming, cross-compiling, etc. etc. etc.) that it felt great to be able to offer something back to the community that I take so much from.  

     That feeling has been quite extinguished at this point. I find myself completely demoralized by Cybersphinx's reply's as they seem more aimed at denouncing the legitimacy of my claims than they are in finding evidence to the contrary and facts to back it up. If I cannot present facts in such a manner as to convince one person of evident truth's concerning such a well founded topic matter as this then I obviously should bow out of this issue entirely and let the facts either speak for themselves or let someone else speak for them. This will be my last post in this thread.  I didn't expect this thread to devolve to a "I'm right"/"You're wrong" fest.  I'm not into the verbal combative posting thing so I'm calling it quits before it boils all the way down to a flaming match.

     I think I'm gonna drop back to being a "quietly watch from the sidelines" member and quit publicly posting altogether, It’s just not worth an argument over the most fundamental facts imagineable.
HOWEVER:Thanks to everyone who participated in a positive way in this thread and gave meaningful information that furthered it. As it managed to pull a LOT of good information forward I still cannot make myself regret having started it. However having said that, there is ZERO chance of  any further posting from me on these forums. I lack any desire whatsoever to spend as much time as I do in my posts in the attempt to make sure they are clear, well researched, and comprehensible just to have it all drowned in pointless confrontation. I realize there are many members who are more knowledgeable and much more brief and yet also still more concise in their posts but I do the best I can. I'm finally starting to understand the frustration and reluctance to post in length that the developers and more knowledgeable members feel. All too often their posts immediately become riddled with reply's from ppl who are disagreeing just for the sake of disagreement and producing theoretical but completely impractical evidence as test cases to prove their stance. Any good that can possibly come from my posts is far outweighed by the diatribe that must be endured as a result.

I come away from this post feeling like I just told my best friend that I believed the world to be round rather than flat.  I know my theory of the world being round sounds totally crazy, but If one more person tells me I’m incorrect and that it truly is flat then I’m going to run and jump right off the edge of it just to get away from them!

Whoever wants the last word can have it. You've already had mine.



Be Well My Friends,

-NeuroShock

[adf]

Merry christmas to you too  

I just can't refrain from pointing out that partitioning is a non-issue in pdaxrom.  ATM my 3100 (incompletely setup since the feeds are down and I need hostap ipks) internal md has 1 ext3 partion mounted at ide (so long as I don't boot with a card/drive in the cf slot) and 1 128 meg swap partition. nothing else. works great.

If you are really that concerned about the partition issues on the 3100, there is a simple solution.

[Meanie]

The C3100 really does not need /hdd1 and /hdd2. Only rc.rofilsys want to see them because Sharp just copied it from the C3000 which really needed them. So all you need to do is hack rc.rofilsys and remove the annoying dependancy. The tiny files in /hdd1 and /hdd2 are used only for recovery, ie when you do a factory reset and it wipes your /home and /hdd3 it uses those files to regenerate the directory structure and put sample files back but you really dont need those samples since they are japanese templates, etc.. nothing you would really miss.
Since I hate this factory reset feature anyway, I hacked it not to wipe hdd3 and not use those files.

[loc4me]

Stop renaming the topic, editing posts that were written several days ago and then later removing them. It is really annoying. Dont say things in the first place if you find you are wanting to remove your post afterwords. The converstations between Neuroshock and Cybersphinx are helpful in revealing misconceptions. Please dont remove useful information.

[neuroshock]

Stop renaming the topic, editing posts that were written several days ago and then later removing them. It is really annoying. Dont say things in the first place if you find you are wanting to remove your post afterwords. The converstations between Neuroshock and Cybersphinx are helpful in revealing misconceptions. Please dont remove useful information.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=108567\"][{POST_SNAPBACK}][/a][/div]

Thank you. I was wondering about that myself. Irritating, I had to go back through my email just to find this post now. I thought the author of the initial post was the only person (other than the moderator) who could change thread names.At this point I'm either assuming the Mod has chosen to do this for some reason or someone knows something that I don't.  Either way I plan on copy/pasting EVERY post (yup even the ones I find irritating) and post them on my website and create a link to it in a new thread in case anyone needs/wants to refer to it in the future.

Imho, no-one's posts should be edited by anyone other than the Moderator or him/her self (the author) for any other reason than clarity or accuracy issues with exceptions only given to extreme racial/cultural/personal slander as we've seen unfortunately from time to time. While I disagree with him Cybersphinx and myself have both brought up valid points and the whole point of a forum is to be able to share and find information, facts, and opinions on topics and altering them without notifying the reader in the post or making the post difficult to find is a disservice to the community.

-NeuroShock

[speculatrix]

Imho, no-one's posts should be edited by anyone other than the Moderator or him/her self (the author) for any other reason than clarity or accuracy issues with exceptions only given to extreme racial/cultural/personal slander as we've seen

I think it's find to move a thread between topics.

And people SHOULD change the topic in a for-sale when the item's been sold.

Otherwise, I agree

[PaulBx1]

I found this interesting thread when poking around. On the controversy between neuroshock and cybersphinx, I have to say I come down mostly in the latter's camp.

I have spent a lot of time working on things like disk I/O. The last thing I did before retiring, was working as a system engineer for Sequent (which IBM swallowed), testing and troubleshooting fiberchannel storage area networks. Sequent was always at the top of the charts for benchmarking on really big systems, so we had to spend a plenty of time worrying about performance. So we did do a lot of benchmarks, and worked constantly with disk manufacturers. I spent many an hour sitting in front of a fibrerchannel analyzer looking at I/Os and figuring out why they were not working, or working too slow. Fiberchannel of course implements a scsi-based protocol for disk storage, so what I say may not apply completely to IDE, but a lot of it will.

The line neuroshock was taking actually was more true in the old days when systems and storage was simple, when people could understand the whole picture and when they had the tools to lay things out so that performance could be enhanced (and they needed to, because those systems were slowwww). But those days are long gone. I/O is extremely complex now, the systems and drives and I/O controllers all do so much optimization and reworking of the command stream that there is very little control over what can be done or how it can be optimized.

Just to give an example, this notion of putting stuff inside or outside of a drive platter, having an effect on performance. First, it is laughable because of all the remapping that goes on in the disk controller. You never really know where stuff is physically going on the platter any more; only the firmware writer knows that. And even if there were no remapping, you still couldn't know for sure! I remember way back, when testing a system where there was no remapping, where the performance was better with data coming off the slow part of the disk, or maybe it was with a slower disk compared to a faster one, can't remember exactly. Here's how that happened:

Those old drives had simple, smallish memory buffers interposed between the platter and the cable. When the DMA speed on the cable is closely matched to the data speed coming off the platter, the transfer proceeds at top rate. However when the data comes off the platter faster, what happens? The transfer goes slower! It does this because the data fills up the buffer, and then has to stop entirely, losing a rotation before starting again. So your transfer is full of lost rotations by the platter, which ends up being slower overall than if the two speeds were matched. If I could have slowed that platter rotation speed down, I could have sped up the transfer rate!

Now, who knows if this holds any more (probably not - buffers might be big enough to swallow the whole file in one gulp - many read requests never actually go to the platter because the file is still in the buffer). But the point here is that there are SO MANY FACTORS affecting I/O performance, it is virtually impossible (outside of a few very simple things like preferring a 10x sd card to a 4x one) to predict with any assurance that the machinations you are going through are going to do any good.

So just use your hardware and don't get yourself too torqued about extracting the last bit of performance out of it. The firmware and OS writers have taken care of that. "Don't worry, be happy!"