• thejml@lemm.eeEnglish
    4·
    3 months ago

    / As of Jan 2034, 512KiB is determined to be the perfect blksize to minimize system call overhead across most systems.

  • Chewy@discuss.tchncs.de
    4·
    3 months ago

    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.

      • PlexSheep@feddit.de
        3·
        3 months ago

        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

        • Violet_McQuasional@feddit.uk
          1·
          3 months ago

          Wow. I’ve been using dd for years and I’d consider myself on the more experienced end of the Linux user base. I’ll use cp from now on. Great link.

        • JubilantJaguar@lemmy.world
          0·
          3 months ago

          Thanks for the tip. Not that I plan to read up on the matter and make the next cold installation even more anxiety-inducing that it already is. Sometimes Linux would really benefit if there were One Correct Way to do things, I find. Especially something so critical as this.

        • Killing_Spark@feddit.de
          0·
          3 months ago

          Huh thanks for the link. I knew that just dd’ing doesn’t work for windows Isos but I didn’t know that it was the Linux distros doing the weird shenanigans this time around

      • Chewy@discuss.tchncs.de
        1·
        3 months ago

        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

    • fruitycoder@sh.itjust.works
      1·
      3 months ago

      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.

      • Snarwin@kbin.social
        2·
        3 months ago

        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.

    • 30p87@feddit.de
      0·
      3 months ago

      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.

      • exscape@kbin.social
        1·
        3 months ago

        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.

  • echo64@lemmy.world
    2·
    3 months ago

    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.