How much storage do your files really need?

Nothing is missing. The manufacturer counts a terabyte as 1,000,000,000,000 bytes (decimal), while Windows divides by 1024 at every step (binary) and calls the result GB. One decimal terabyte is 1,000,000,000,000 ÷ 1024³, which is 931.32 binary gigabytes. Both figures describe exactly the same drive.

GiB is the unambiguous binary unit: 1 GiB = 1024³ = 1,073,741,824 bytes. GB, strictly speaking, means 10⁹ = 1,000,000,000 bytes. In practice most operating systems display binary quantities but label them GB, which is precisely where the confusion comes from. The gap is about 7.4% at the gigabyte and 9.9% at the terabyte.

Divide by eight, since there are eight bits in a byte. A 300 Mbps connection tops out around 37.5 MB/s of payload, and in practice a bit less after protocol overhead. This is the single most common mix-up in anything involving download times, and it makes a factor-of-eight difference.

The capacity of all your disks minus one. Four 4 TB disks in RAID 5 give 12 TB usable, with 4 TB consumed by parity, and the array survives one disk failing. RAID 6 costs two disks instead of one but survives two simultaneous failures, which matters increasingly as disks get larger and rebuilds take longer.

No, and treating it as one is how people lose data. RAID protects against a disk failing. It does not protect against a deleted file, ransomware, a corrupted filesystem, a failed controller, theft or fire — all of which are replicated instantly and faithfully across every disk in the array. You still need a separate copy, ideally offsite, and you need to test restoring from it.

Because it is already compressed. MP4, JPEG, PNG, MP3 and similar formats have already had their redundancy removed by a codec designed for that specific kind of data, so a general-purpose compressor finds almost nothing left to exploit — typically 0–3%. Text, code, logs and CSV are the opposite case and routinely shrink by 70–95%.

It depends entirely on the content, so the ratio is only meaningful against a comparable baseline. Plain text and logs commonly reach 4:1 to 10:1. Source code lands around 3:1 to 5:1. Already-compressed media sits near 1:1. A poor ratio on media is not a broken tool — it is a signal that compressing it was not worth the CPU time.

Because .git holds every version of everything ever committed, not just the current state. Git compresses and delta-encodes aggressively, so text history is cheap, but a large binary committed once stays in the object database forever and is downloaded by every clone. Deleting the file later does not remove it from history — only rewriting history does, and that breaks every existing clone.

As soon as you know binaries are coming, and ideally before the first one is committed. LFS stores large files outside the normal object database and pulls only the versions actually checked out. Adding it from the start is easy; retrofitting it means rewriting history and coordinating a re-clone across everyone using the repository.

Three reasons stack up. The advertised figure is in bits, so divide by eight for bytes. Protocol overhead removes a further 25–40%. And the slowest device in the chain sets the ceiling — a USB 4 port writing to a mechanical hard drive runs at hard-drive speed, around 100–150 MB/s, and no port upgrade changes that.

Every file carries fixed per-file costs: directory entries, metadata writes, and on flash media an erase-block penalty. Those costs are paid once per file rather than once per gigabyte, so ten thousand small files can take several times longer than a single archive of exactly the same total size. Packing them into one container first is usually the fastest route.

At USB 3.0 speeds of roughly 400 MB/s, about 4.3 minutes per 10 GB, so around 43 minutes for 100 GB — assuming the destination drive can keep up. On USB 2.0 at about 35 MB/s the same 100 GB takes close to 50 hours, which is why USB 2.0 external drives were unusable long before they disappeared.