Word to Tebibyte

A word's size depends on the CPU architecture. In x86/x64 (Intel/AMD) documentation: word = 16 bits, DWORD = 32 bits, QWORD = 64 bits. In ARM 32-bit: word = 32 bits. In most modern 64-bit systems (excluding x86 documentation): word = 64 bits. When reading technical documentation, always check the architecture's definition, as "word" is not a universal fixed size.

In Windows API documentation and x86 architecture, a DWORD (Double Word) = 32 bits = 4 bytes, capable of holding values 0–4,294,967,295 (unsigned) or -2,147,483,648 to 2,147,483,647 (signed). DWORD is the most common fixed-width integer type in the Windows API, used for flags, handles, and return codes. The equivalent in modern C/C++ is uint32_t (unsigned) or int32_t (signed).

A CPU's word size determines: (1) the maximum addressable memory — a 32-bit CPU addresses up to 4 GiB (2³² bytes); a 64-bit CPU addresses up to 16 EiB (2⁶⁴ bytes); (2) the precision of integer arithmetic — a 64-bit word handles numbers up to ~18.4 × 10¹⁸ in a single instruction; (3) performance — operations on data smaller than the word size may require extra sign-extension instructions on some architectures.

Modern x86-64 CPUs (Intel Core, AMD Ryzen) have 64-bit general-purpose registers, so their native word size is 64 bits for most operations. However, x86 documentation maintains the legacy definition: "word" = 16 bits, DWORD = 32 bits, QWORD = 64 bits. This creates a confusing terminology mismatch between the architectural naming convention and the physical register size.

Memory alignment means storing data at addresses that are multiples of the data's size. A 32-bit word should be stored at an address divisible by 4 (bytes); a 64-bit word at an address divisible by 8. Misaligned access is either forbidden (causes a CPU fault) or penalised (requires two memory reads instead of one). Compilers automatically align variables; manual struct packing can create misalignment that causes subtle performance issues or crashes on strict architectures.

TB (terabyte) = 10¹² bytes = 1,000,000,000,000 bytes (SI decimal). TiB (tebibyte) = 2⁴⁰ bytes = 1,099,511,627,776 bytes (IEC binary). TiB is 9.95% larger. The practical consequence: a 1 TB hard drive (decimal) holds 0.9095 TiB. This 10% gap is the primary reason drive capacity appears lower in the OS than on the box.

ZFS and Btrfs are copy-on-write filesystems designed for TiB-scale pools with built-in features that traditional filesystems lack. ZFS supports inline deduplication — a 10 TiB pool with 40% duplicate data might show 6 TiB of logical usage but only consume 3.6 TiB physically. Btrfs offers transparent compression (zstd), where a 4 TiB dataset of compressible log files might occupy only 1–2 TiB on disk. Both support snapshots that initially consume zero extra space, growing only as data diverges. These features make "used space in TiB" surprisingly complex to report accurately.

Yes. Linux tools (df -h, lsblk) display storage in IEC binary units: KiB, MiB, GiB, TiB. df -h output showing "1.8T" for a 2 TB drive is reporting 1.8 TiB. Modern Linux distributions correctly label these as TiB in technical contexts. This is one of the areas where Linux is more technically precise than Windows or consumer storage labels.

RAID arrays lose capacity to redundancy: RAID 1 mirrors two drives (50% efficiency); RAID 5 loses one drive worth of capacity; RAID 6 loses two drives. A 4-drive RAID 5 array of 2 TB drives has 3 × 2 TB = 6 TB raw usable (decimal), ≈ 5.46 TiB, minus filesystem overhead. Enterprise storage also reserves space for spares, snapshots, and wear levelling, further reducing usable TiB.

No. A tebibyte (TiB) = 2⁴⁰ bytes = 1,099,511,627,776 bytes — about 1.1 trillion bytes. Exactly one trillion bytes = 10¹² bytes = 1 terabyte (TB, decimal). The tebibyte is approximately 10% larger than a trillion bytes. "Terabyte" is often casually used to mean "1 trillion bytes"; "tebibyte" is the precise binary equivalent at 1,024 gibibytes.