3

This is something that has happened to me more than a few times and I finally decided to ask, as I cannot find any information on it.

I was downloading two different Linux distros, each were ~1.8GB .ISOs. I tried to write them to a 2GB USB stick and it fails saying the disk is not big enough. I tried using both Rufus and Etcher to write the files, with the same result.

I am assuming these "minimal" ISOs, which are all under 2GB, are designed to be small enough to fit on a 2GB USB stick, or am I wrong?

6
  • 1
    What does Rufus show in its log window? Were you writing the images "raw" (dd mode in Rufus) or were you letting the tool do its own arrangement of the contents? Jul 5, 2021 at 11:56
  • Rufus was using default mode, not DD
    – Keltari
    Jul 5, 2021 at 12:01
  • If those 2GB sticks have even a few bad block then you will lose capacity. Related to the fact that manufacturers use "metric" Gigabytes while computer people use Gibibytes I would never assume anything within about 10% of a size is compatible between manufacturers and computer users. google.com/search?q=2GB+to+GiB You might get about 1.86GiB of data on a 2GB stick, assuming the manufacturer was truly 100% honest (they usually aren't and love weasel words like "nominal capacity").
    – Mokubai
    Jul 5, 2021 at 12:03
  • 1
    Related: superuser.com/questions/504/…
    – Mokubai
    Jul 5, 2021 at 12:03
  • 1
    I wouldn't assume anything beyond "they made a minimal ISO". I doubt they considered where it would be copied at all and "hey this might fit on a 2GB stick" was probably a far lower priority than "what's the minimal set of packages we can put on and still make this vaguely useful". I also would trust those unbranded "branded" memory sticks for any kind of guaranteed capacity as far as I could throw the silicon foundry that manufactured them, lowest bidder parts with dog knows how many defects mapped out by the controller.
    – Mokubai
    Jul 5, 2021 at 12:26

1 Answer 1

3

In non DD mode, Rufus will convert from one file system to another, which means that there's no guarantee that what occupies less than 2 GB of content with one file system will also occupy less than 2 GB in the other. There are many elements that can make files take more space when copied from one file system to another, such a cluster size, fragmentation and so on.

Also, when Windows reports that an ISO is 1.8 GB, it means that it occupies about 1.8 x 1024 x 1024 x 1024 bytes = 1932735284 bytes of disk space. That's because Windows uses the historical definition of a kilobyte which is 1024 bytes. But when a manufacturer says a flash drive is 2 GB, it means that it can accommodate up to 2 x 1000 x 1000 x 1000 = 2000000000 bytes, because drive manufacturers use their own smaller definition of a kilobyte in order to make their drives look larger to unsuspecting consumers. So, in "manufacturer units", there's a difference of about 0.068 GB rather than 0.2 GB between the size of your drive and the size of your ISO, which isn't that much.

As such, it isn't surprising that the content from your 1.8 GB ISO may not fit on a "2 GB" flash drive when written in ISO mode. To make it fit, you may have to select DD mode when Rufus prompts you.

1
  • Technically speaking, Windows is using binary prefixes rather than decimal ones. I'd argue it's not as much historical as simply confusing. If we were speaking about RAM capacity, using binary prefixes would be appropriate. For persistent storage it depends. Specifying binary units explicitly (KiB, MiB, GiB…) could maybe make this less confusing.
    – gronostaj
    Jul 6, 2021 at 14:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .