GNU Coreutils 9.5 Can Yield 10~20% Throughput Boost For cp, mv & cat Commands

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.
- 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).
- Interesting. Is this serious advice and if so, what's the new canonical command to burn an ISO?
  
  Recently, I learned that booting from a dd'd image is actually a major hack. I don't get it together on my own, but has something to do with no actual boot entry and partition table being created. Because of this, it's better to use an actual media creation tool such as Rufus or balena etcher.
  Found the superuser thread: https://superuser.com/a/1527373 Someone had linked it on lemmy
  
  As I understand it, there isn't really a canonical way to burn an ISO. Any tool that copies a file bit for bit to another file should be able to copy a disk image to a disk. Even shell built-ins should do the job. E.g. cat my.iso > /dev/myusbstick reads the file and puts it on the stick (which is also a file). Cat reads a file byte for byte (test by cat'ing any binary) and > redirects the output to another file, which can be a device file like a usb stick.
  There's no practical difference between those tools, besides how fast they are. E.g. dd without the block size set to >=1K is pretty slow [1], but I guess most tools select large enough I/O sizes to be nearly identical (e.g. cp).
  [1] https://superuser.com/questions/234199/good-block-size-for-disk-cloning-with-diskdump-dd#234204
  
  # cp /path/to/image /dev/disk
- 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.
- Do cp capture the raw bits like dd does?
  Not saying that its useful in the case you're describing but that's always been the reason I use it. When I want every bit on a disk copied to another disks, even the things with no meta data present.
  
  As long as you copy from the device file (/dev/whatever), you will get "the raw bits", regardless of whether you use dd, cp, or even cat.
- For those that like the status bar dd provides, I highly recommend pv
  pv diskimage.iso > /dev/usb

/ 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?
- Wrong license still but I just read an article saying they are making progress on compatiabity with the GNU coreutils
  
  What means wrong license? Does it need to be GPL(v3)?
- From their readme
  https://github.com/uutils/coreutils?tab=readme-ov-file#gnu-test-suite-compatibility

This is a good example of how most of the performance improvements during a rewrite into a new language come from the learnings and new codebase, over the languages strengths.

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?
- progress https://github.com/Xfennec/progress
  
  Thanks! Name of the tool checks out, lol.