From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
The I/O size is a reason why it's better to use cp than dd to copy an ISO to a USB stick. cp automatically selects an I/O size which should yield good performance, while dd's default is extremely small and it's necessary to specify a sane value manually (e.g. bs=1M).
With "everything" being a file on Linux, dd isn't really special for simply cloning a disk. The habit of using dd is still quite strong for me.
For me, I only got to 5 Gbps or so on my NVMe using dd and fine tuning bs=. In second place there was steam with ~3 Gbps. The same thing with my 1 Gbps USB Stick. Even though the time I saved by more speed is more than made up by the time it took me to fine tune.
Sorry for the nitpick, but you probably mean GB/s (or GiB/s, but I won't go there). Gbps is gigabits per second, not gigabytes per second.
Since both are used in different contexts yet they differ by about a factor of 8, not confusing the two is useful.
I think it is gigabits per second, but to be clear: Whatever dd reports as speed after finishing (or with status=progress)
That's in bytes. A modern NVMe drive can do about 7 GB/s (more than 10 for PCIe 5.0 drives). Even SATA could handle 5 Gbit/s, though barely.
Yup, my PCIe NVMe should be readable at 8 GB/s and writeable at 7 GB/s afaik. I can't reach that speed tho, no matter which bs.
Like i use to say; dd nowadays is best used as a scalpell (to cut bit sizes) not a shovel (to move chunks of data).
/ As of Jan 2034, 512KiB is determined to be the perfect blksize to minimize system call overhead across most systems.
as of Jan 2034 there are no humans so thus we can discontinue tools for humans
Feb 2034: grammer correction: there are no humans.
This is the best summary I could come up with:
One of the interesting improvements to note with GNU Coreutils 9.5 is that the cp, mv, install, cat, and split commands can now read/write a minimum of 256KiB at a time.
Previously there was a 128KiB minimum while this has been doubled in order to enhance the throughput of Coreutils on modern systems.
The throughput with Coreutils 9.5 thanks to this change increases by 10~20% when reading cached files on modern systems.
This default I/O size update was last adjusted a decade ago.
GNU Coreutils 9.5 also has fixed various warnings when interacting with the CIFS file-system, join and uniq better handle multi-byte characters, tail no longer mishandles input from /proc and /sys file-systems, various new options for different commands, SELinux operations during file copy operations are now more efficient, and tail can now follow multiple processes via repeated "--pid" options.
More details on all of the GNU Coreutils 9.5 changes via the release announcement.
The original article contains 263 words, the summary contains 155 words. Saved 41%. I'm a bot and I'm open source!
Btw do you know how uutils (rust rewrite of GNU coreutils) is doing?
Huh? Wasn't at least cp supposed to determine optimal block size automatically?
Btw, what was the tool again, that watches some kernel functionality to get progress for multiple such tools?