I was running through a partioning problem recently and I couldn't find out which utility was using MB or MiB, and why they couldn't be consistent in all three utilities.

For example, in fdisk, when you print out the partition table, the sizes are in M or G (which I assume are megabytes and gigabytes ??) And in gdisk, they are printed out in MiB or GiB (which are mebibytes and gibibytes)... And in resize2fs it actually specifies in the man pages that it is in MB (which is megabytes). And parted, well i haven't even looked at it yet...

Now, keeping in mind that 100 MB is totally different from 100 MiB and that this info is crucial for not losing all your data, what is the actual rule of thumb?


1 Answer 1


Many programs follow the same conventions about size units, or "block size". But it's not a universal rule, each program can generally "do what it wants", so definitely read each tool's man or info page to be sure.

For partitioning I'd definitely go with gparted, it should avoid any confusion, showing you what units it's using pretty clearly.

My man resize2fs actually doesn't say it uses only MB (one million bytes), but rather this:

   The  size parameter specifies the requested new size of the filesystem.
   If no units are specified, the units of the size parameter shall be the
   filesystem blocksize of the filesystem.  Optionally, the size parameter
   may be suffixed by one of the following  the  units  designators:  's',
   'K',  'M', or 'G', for 512 byte sectors, kilobytes, megabytes, or giga‐
   bytes, respectively.  The size of the filesystem may  never  be  larger
   than the size of the partition.  If size parameter is not specified, it
   will default to the size of the partition.

   Note: when kilobytes is used above, I mean real, power-of-2  kilobytes,
   (i.e.,  1024 bytes), which some politically correct folks insist should
   be  the  stupid-sounding  ``kibibytes''.   The  same  holds  true   for
   megabytes,  also sometimes known as ``mebibytes'', or gigabytes, as the
   amazingly silly ``gibibytes''.  Makes you want to gibber, doesn't it?

fdisk shows sizes in sectors, according to whatever the device examined says a sector is. Here's an example output for a small device, the size is reported as 3997 MB, 3997171712 bytes, which is using the manufacturer's preferred "bigger" 1MB = 1,000,000 bytes:

$ sudo fdisk -l /dev/sdb

Disk /dev/sdb: 3997 MB, 3997171712 bytes
17 heads, 16 sectors/track, 28702 cylinders, total 7806976 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            8192     7806975     3899392    b  W95 FAT32

You may notice it's telling me the only partition is 3899392 blocks, but subtracting the end from the start yields twice that... that's strange and incorrect, but man fdisk does say "fdisk is a buggy pro‐ gram that does fuzzy things - usually it happens to produce reasonable results. Its single advantage is that it has some support for BSD disk labels and other non-DOS partition tables. Avoid it if you can."
It does recommend cfdisk, which more accurately shows (in 512 byte blocks):

$ sudo cfdisk -P s /dev/sdb
Partition Table for /dev/sdb

               First       Last
 # Type       Sector      Sector   Offset    Length   Filesystem Type (ID) Flag
-- ------- ----------- ----------- ------ ----------- -------------------- ----
   Pri/Log           0        8191*     0#       8192*Free Space           None
 1 Primary        8192*    7806975*     0     7798784 W95 FAT32 (0B)       None

parted shows MB=1,000,000 bytes by default, but that can be changed with this:

Model: Multi Flash Reader (scsi)
Disk /dev/sdb: 3997MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      4194kB  3997MB  3993MB  primary  ext3

but the units can be changed with it's units command:

unit unit
  Set unit as the unit to use when displaying locations and
  sizes,  and for interpreting those given by the user when
  not suffixed with an explicit unit.  unit can be  one  of
  "s"  (sectors),  "B" (bytes), "kB", "MB", "GB", "TB", "%"
  (percentage of device  size),  "cyl"  (cylinders),  "chs"
  (cylinders,  heads, sectors), or "compact" (megabytes for
  input, and a human-friendly form for output).

However, gparted shows sizes in (my preferred) M or MiB (powers of 1024), and it can do all the moving/shrinking/resizing/formatting too if you like, or you can only create partitions with it, and format them later yourself using the "entire" partition and not worry about the exact sizes.

enter image description here

You might want to read the coreutils.info page on Block size:

2.3 Block size

Some GNU programs (at least 'df', 'du', and 'ls') display sizes in "blocks". You can adjust the block size and method of display to make sizes easier to read. The block size used for display is independent of any file system block size. Fractional block counts are rounded up to the nearest integer.


An integer block size can be followed by a suffix to specify a multiple of that size. A bare size letter, or one followed by 'iB', specifies a multiple using powers of 1024. A size letter followed by 'B' specifies powers of 1000 instead. For example, '1M' and '1MiB' are equivalent to '1048576', whereas '1MB' is equivalent to '1000000'.

A plain suffix without a preceding integer acts as if '1' were prepended, except that it causes a size indication to be appended to the output. For example, '--block-size="kB"' displays 3000 as '3kB'.

The following suffixes are defined. Large sizes like '1Y' may be rejected by your computer due to limitations of its arithmetic.

'kB' kilobyte: 10^3 = 1000.

'k' 'K' 'KiB' kibibyte: 2^10 = 1024. 'K' is special: the SI prefix is 'k' and the ISO/IEC 80000-13 prefix is 'Ki', but tradition and POSIX use 'k' to mean 'KiB'.

'MB' megabyte: 10^6 = 1,000,000.

'M' 'MiB' mebibyte: 2^20 = 1,048,576.

'GB' gigabyte: 10^9 = 1,000,000,000.

'G' 'GiB' gibibyte: 2^30 = 1,073,741,824.

'TB' terabyte: 10^12 = 1,000,000,000,000.

'T' 'TiB' tebibyte: 2^40 = 1,099,511,627,776.

'PB' petabyte: 10^15 = 1,000,000,000,000,000.

'P' 'PiB' pebibyte: 2^50 = 1,125,899,906,842,624.

'EB' exabyte: 10^18 = 1,000,000,000,000,000,000.

'E' 'EiB' exbibyte: 2^60 = 1,152,921,504,606,846,976.

'ZB' zettabyte: 10^21 = 1,000,000,000,000,000,000,000

'Z' 'ZiB' 2^70 = 1,180,591,620,717,411,303,424.

'YB' yottabyte: 10^24 = 1,000,000,000,000,000,000,000,000.

'Y' 'YiB' 2^80 = 1,208,925,819,614,629,174,706,176.

Block size defaults can be overridden by an explicit '--block-size=SIZE' option. The '-k' option is equivalent to '--block-size=1K', which is the default unless the 'POSIXLY_CORRECT' environment variable is set. The '-h' or '--human-readable' option is equivalent to '--block-size=human-readable'. The '--si' option is equivalent to '--block-size=si'.

  • Ok so, reading the resize2fs man, it talks about K, M, G...etc. and refers to it as megabytes and gigabytes?? Isn't that odd?? Shouldn't it be mebibytes and gibibytes? Or am I still missing something?
    – Matt
    Apr 1, 2017 at 22:25
  • Yeah, just missing the strange naming argument between megabyte meaning 1,000,000 byes (that manufacturers like to use since it's "bigger", and the "mega" prefix implies), or 1,048,576 bytes (that computers have generally used for decades). I tend to agree with the resize2fs man page author (Theodore Ts'o? Probably not) and think the "byte" in megabyte gives it the power-of-2 more than a million bytes meaning, and the "ib" in kibibyte, mebibyte, gibibyte is rather silly. Reminds me of the "Linux isn't really called Linux, you should call it GNU-Linux because... reasons?" argument
    – Xen2050
    Apr 2, 2017 at 4:30
  • 1
    The author states "some politically correct folks insist should be the stupid-sounding..." But WE ARE IN LINUX, not in the windows world, so we shouldn't have these ambiguities. Especially when using a powerful low-level disk partitionning tool !
    – Matt
    Aug 24, 2017 at 9:38
  • Well, what's in a name anyway, a disk by any other name would still crash as hard...
    – Xen2050
    Aug 24, 2017 at 9:41
  • Thanks. This explains why my filesystem was wrecked when I did a resize2fs to 500G and a parted resizepart to 500GB. You would think there would be some kind of consensus between these low level utils.
    – asdofindia
    Sep 20, 2020 at 18:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.