Windows 8 team blog on updating the copy dialog UX[3].
[1] https://devblogs.microsoft.com/oldnewthing/20040106-00/?p=41...
[2] https://web.archive.org/web/20120608005952/http://blogs.tech...
[3] https://learn.microsoft.com/en-us/archive/blogs/b8/improving...
Cat6A can do 10Gbps at 100m. Cat7 and Cat8 can do higher speeds in short runs but those technologies are DEAD in DC tech now. 40G is legacy tech using four lanes of 10G, replaced by 100G which is four lanes of 25G. Copper patch cables are not used with these, everything is fiber or DAC.
If you use a Cat7 or Cat8 cable the higher MHz support listed on the spec will never be used. When using a real cable of these qualities all you are really getting is better protection from outside interference.
When buying premade patch cables only buy Cat6A. Anything you see online saying Cat7 or Cat8 has probably never been properly tested by the manufacturer.
When buying a spool of wire do your research on the manufacturer. There's plenty with false labels out there. I once saw a spool of 'Cat6e' which is not a real standard.
When paying others to run cables find out what brand and what warranty the installer is providing. If they only use Cat7 and cannot provide a good explanation on why they might not actually know as much as you should be expecting them to.
> so you have no idea what you're actually getting
As Cat 7 is only sold by the meter on a roll, you know just as much what you're getting as with Cat 6A, spec-compliant network cables.
PowerShell has some "interesting" design choices...
Another fun one is Extract-Archive which is painfully slow while using the System.IO.Compression.ZipFile CLR type directly is reasonably fast. Powershell is really a head scratcher sometimes.
I tried to look into the whole Expand-Archive thing, but as of https://github.com/PowerShell/Microsoft.PowerShell.Archive/c... I can't even find the Expand-Archive cmdlet source code anymore. The archive files themselves seem to have "expand" be unimplemented. Unless they moved the expand command to another repo for some reason, it looks like the entire command will disappear at one point?
Still, it does look like Expand-Archive was using the plain old System.IO.Compression library for its file I/O, though, although there is a bit of pre-processing to validate paths existing and such, that may take a while.
That "up to a point" is crucial. Storing chunks in memory up to some max size as you wait for them to be written to disk makes complete sense. Buffering the entire download in memory before writing to disk at the end doesn't make sense at all.
Harassing the creator/team for years because a thing you don't use doesn't work the way you want it to work? That is.
They removed it in PowerShell core 9 years ago! 9 years! And you're still fixated on it!
The alias confuses people that are expecting to run curl when they type "curl" (duh) and also causes headaches for the actual curl developers, especially when curl is actually installed!
Why the hostile tone? Pretty rude of you to claim I'm fixated on the issue for years and harassing the powershell development team with zero evidence.
For robocopy, for example, if you're copying small files/bunch of directories use the /MT:$number flag. It's so much massively faster it's not like the same application.
Also is this a newer version of Windows that supports smb3, Explorer is likely using that to copy more in parallel.
You can use Powershell.
$shell = New-Object -ComObject Shell.Application
$shell.Namespace("C:\Source").ParseName("myfile").InvokeVerb("copy")
$shell.Namespace("C:\Destination").Self.InvokeVerb("paste")Even someone who has never seen a Windows PC in their life could guess what this script does.
Linux and Unix shell commands use completely arbitrary single letter parameters that must be looked up or memorised. That’s not a virtue.
I have been considering a move back to Linux. It is only Microsoft Teams on Windows that I have to use daily that is holding me back.
I‘m very sorry.
Me too. I've not tried this yet, but will soon: https://github.com/IsmaelMartinez/teams-for-linux
Performing parallel copies is probably the big win with less than 10 Gb/s of network bandwidth. This will allow SMB multichannel to use multiple connections, hiding some of the slowness you can get with a single TCP connection.
When doing more than 1-2 GB/s of IO the page cache can start to slow IO down. That’s when unbuffered (direct) IO starts to show a lot of benefit.
https://www.codesector.com/teracopy
(I have certainly forgotten at least one...)
It’ll happen if your U.2 ports route through DMI 3.0 PCH/Chipset/PCIe switch rather than directly to the CPU PCIe lanes. Easiest to just check motherboard manual, but you can use hwinfo to inspect the PCI tree and see if your U.2 ports are under a “chipset” labeled node. You might have different ports on the mobo that are direct, or possibly bios changes to explore. Sometimes lots of options, sometimes none. Worst case a direct PCIe adapter will resolve it.
Windows Server 2025 is somewhat better on reads but only at low parallelism.
There’s no difference on writes.
What does iperf say about your client/server combination? If it's capping out at the same level then networking, else something somewhere else in the stack.
I noticed recently that OS X file IO performance is absolute garbage because of all the extra protection functionality they've been piling into newer versions. No idea how any of it works, all I know is some background process burns CPU just from simple operations like recursively listing directories
Windows has weird behaviors for copying. Like if I pool some SAS or NVMe SSD in storage space parity (~RAID5) the performance in CrystalDiskMark is abyssal (~250MB/s) but a windows copy will be stable at about 1GB/s over terabytes of data.
So it seems that whatever they do hurts in certain cases and severely limits the upside as well.
There's definitely something off about OP's setup, though I have no idea what it could be. I'd start by checking the latency between the machines. Might also be the network adapter or its drivers.
This isn't even going into WSL. I specifically stopped using WSL and moved to a separate linux devbox because of all the weirdness and slowness with filesystem access across the WSL boundary. Something like listing a lot of files would be very slow IIRC. Slightly tangentially, the whole situation around sharing files across OSes is pretty frustrating. The only one that works without 3rd party paid drivers on all 3 major OSes is ExFAT and that is limited in many other ways compared to ext4 or NTFS.
Sometimes it's interference, sometimes the backing SSD is just a lot slower than it says on the box. I've also seen large file transfers (hundreds of gigabytes) expose bad RAM as caches would get filled and cleared over and over again.
You should be able to go into the Windows settings and reduce the drive cache. Copying will be slower, but behaviour will be more predictable.
Then, when the copying happens, this seems to be the code that actually copies the file, at least when copying from remote to local, using the default file system provider: https://github.com/PowerShell/PowerShell/blob/master/src/Sys...
Unless I've taken a wrong turn following the many abstraction layers, this file copy seems to involve connecting to a remote server and exchanging the file contents over a base64 stream (?) using nothing but a standard OutputStream to write the contents.
This means that whatever performance improvements Microsoft may have stuffed into their native network filesystem copy operations doesn't seem to get triggered. The impact will probably differ depending on if you're copying Windows-to-Windows or SAMBA-to-Windows or Windows-to-SAMBA.
I'm no PowerShell guru, but if you can write a (C#?) cmdlet to invoke https://learn.microsoft.com/en-us/windows/win32/api/shellapi... with a properly prepared https://learn.microsoft.com/en-us/windows/win32/api/shellapi... rather than use the native Copy-Item, I expect you'd get the exact same performance you'd get on Windows Explorer.
However, the other measurements do show some rather weird slowdowns for basic filesystem operations over SFTP or WSL2. I think there's more at play there, as I've never seen sftp not reach at least a gigabit given enough time for the window sizes to grow. I think the NAS itself may not be very powerful/powerful enough to support many operations per second, limiting the output for other copy tools.
As an alternative, Windows contains an NFS client that can be tuned to be quite fast, which should have minimal performance overhead on Linux if kernel-NFS is available.
I think that's not the right code because it's in "PerformCopyFileFromRemoteSession" and that sounds like it's for Copy-Item -ToSession ... -FromSession ... which are for New-PSSessions (PowerShell remoting/WinRM). Those are already Powershell-serialized-in-XML-in-WinRM-XML (I think) and copying file data plausibly goes into Base64 to go inside that.
That can't be what happens if you do Copy-Item -Destination \\server\share\
Yea, I have a workload that has to delete millions of directories/small files on occasion and we wrote a cmdlet to spawn a huge amount of threads to perform the delete to keep the IOPS saturated and it performs much better than explorer or other deletion methods.
FWIW, I previously spent some time trying to get the maximum possible throughput when copying files between a Windows host and a Linux VM, and the encryption used by most protocols did actually become a bottleneck eventually. I expect this isn't a big factor on 1gbps ethernet, but I've never measured it.
HPN-SSH[1] resolves this but isn't widely deployed.
filesystem should be faster in WSL2 but not if the file resides in the windows path I think