QUOTE (GrofLuigi @ Jul 15 2008, 04:19 PM)

I see that Mark Russinovich's article quoted very often. Have you read it entirely?
No, I just like to paste URLs to articles I haven't read

QUOTE (GrofLuigi @ Jul 15 2008, 04:19 PM)

OK, this might be the fault of Server 2003 or the slow network. (But it didn't stop Microsoft taking good money for 5 years for Server2003. Shouldn't they at least issue a hotfix?)
From what he says, it's the combination of Win 2003 + slow network, and the issue is with Win2003 itself. They made Vista SP1 use a somewhat slower transfer (smaller blocks) to prevent a problem with Windows 2003's cache manager, instead of fixing Win 2003. I'd hardly blame Vista or this... Besides, just how much difference does it make in real life? 10% slower perhaps? And how often is your network that bloody slow that it affects your servers? And again, would you really rather have a somewhat faster transfer, and then your Win 2003 server crashing because of it?
QUOTE (GrofLuigi @ Jul 15 2008, 04:19 PM)

And this would be... what... the most frequent case of copy operation a normal user would issue?

Again, it's not that simple. A lot of design decisions are tradeoffs. Smaller I/O buffers, for a more responsive system, or bigger chunks for a slightly faster transfer, but a not as responsive system? The problem only applies when you copy to/from the same disk, which is actually not all that common. Most of the time when you do something on the same disk, you move files, not make copies of it, and if it's 2 different drives, then it doesn't increase seeking anyways. It's not like it will make a HUGE difference either (one could make a small app to benchmark a file copy like that with different buffer sizes in no time at all). And again, like he says, this is more of an issue with older disks that don't have NCQ and such. Disk fragmentation itself could easily have a lot more effect than this (increasing seeking lots more). It's really not that bad, and if it makes the system more responsive, then why not?
Another screenshot, about this specific "issue", that speaks for itself (and I really ought to defrag sometime):

I think this is still very acceptable. We're still a VERY long shot from his 10KB/sec file copy issues (by a factor of about 10 thousand)
QUOTE
to restore most copy scenarios to at least the performance of previous versions of Windows
That was a problem with the RTM, which needed some tweaks, and as he says:
QUOTE
Unfortunately, the SP1 changes, while delivering consistently better performance than previous versions of Windows, can be slower than the original Vista release in a couple of specific cases.
As in, it's always faster at all file operations than XP and below, with a couple minor exceptions where it's slower than Vista RTM (where performance isn't bad anyways, just reduced a tiny bit). Notice he doesn't say anywhere that XP is actually faster at anything anywhere. I don't think that really sounds bad.
QUOTE
My understanding of Mark's article is they have (re)invented square wheels with Vista, and with SP1 they've made them oval - drastical improvement.
How's that reinventing the wheel? Using caching (nothing new), tuning buffer size (like any app that does file I/O does), auto RWIN resize (a VERY good thing for your network at high speeds, we used to have to do that by hand), and the next version of the plain old SMB protocol. What's so drastically changed? I'm just not seeing it. It works just fine.