The find command allows you to search by size, which you can specify using units spelled out in the man page:

File uses n units of space.  The following suffixes can be used:
  `b'    for 512-byte blocks (this is the default if no suffix is used)
  `c'    for bytes
  `w'    for two-byte words
  `k'    for Kilobytes (units of 1024 bytes)
  `M'    for Megabytes (units of 1048576 bytes)
  `G'    for Gigabytes (units of 1073741824 bytes)

Is there a historical reason b is chosen for "block" rather than "byte", which I suspect would be the more common assumption? And why would block be the default rather than byte? When and why would someone ever want to use this unit? Converting to bytes/kilobytes involves a bit of math, it doesn't seem very convenient to be the default unit.

2 Answers 2


The first versions of Unix happened to use 512-byte blocks in their filesystem and disk drivers. Unix started out as a pretty minimalist and low-level system, with an interface that closely followed the implementation, and leaked details that should have remained abstracted away such as the block size. This is why today, “block” still means 512 bytes in many contexts, even though there can be different block sizes, possibly even different block sizes applying to a given file (one for the filesystem, one for the volume manager, one for the disk…).

The implementation tracked disk usage by counting how many data blocks were allocated for a file, so it was easy to report the size of a file as a number of blocks. The disk usage and the size of a file can differ, not only because the disk usage is typically the size rounded up to a whole number of blocks, but also because sparse files have fewer blocks than the size would normally require. As far as I know, early Unix systems that implemented sparse files had find -size use the number of blocks used by the file, not the file size; modern implementations use the file size rounded up (there's a note to this effect in the POSIX specification).

The earliest find implementations only accepted a number of blocks after -size. At some point, find -size started accepting a c suffix to indicate a number of characters instead of blocks; I don't know who started it, but it was the case in 4.3BSD. Other suffixes appeared later, for example in FreeBSD it was release 6.2 that introduced k, M and other suffixes but not b which I think only exists in GNU and BusyBox find.

Historically, many programs used “character” and “byte” interchangeably, and tended to prefer the term “character”. For example, wc -c counts bytes. Support for multibyte characters, and hence a character count that differs from the byte count, is a relatively recent phenomenon.

In summary, there is no purpose. The 512-byte block size, the fact that it's the default unit, and the use of the letter b did not arise deliberately, but through historical happenstance.


Blocks were more important than bytes because from the beginning, files used a given number of blocks rather than bytes on the file system. A file with one byte still took up one block on the disk.

For instance the find(1) manual page from Unix 6th edition says

-size n         True if the file is n blocks long (512 bytes
                 per block).

The manual page did not provide convenient ways to represent other units of measure for size.

POSIX explicitly states in the description of find that it uses 512-byte blocks:

-size n[c]
The primary shall evaluate as true if the file size in bytes, divided by 512 and rounded up to the next integer, is n. If n is followed by the character 'c', the size shall be in bytes.

On some older systems, e.g., the HPUX 10.20 manual page, it was not explicit.

  • So its down to the FS compliance then?
    – heemayl
    Commented Feb 2, 2016 at 1:48
  • The sum of all the byte sizes of a bunch of files doesn't add up to the actual filesystem space allocated. The sum of the sizes of blocks a bunch of files use does add up to the actual filesystem space allocated. This is why blocks can be important. Less so, now that disks are gigantic. Or should that be terantic? :-) Commented Feb 2, 2016 at 3:01
  • Is this unit dependent on the block size of your file system? Or is it always 512 bytes regardless?
    – baochan
    Commented Feb 2, 2016 at 3:25
  • It's always 512 bytes. And looking at V7, 4.3BSD, GNU, and FreeBSD , they all use the st_size field of stat() rather than st_blocks, so they're looking just at the length of the file rather than the amount of space it occupies on the filesystem (which depends on sparseness, indirect blocks, etc.) Commented Feb 2, 2016 at 6:39

You must log in to answer this question.

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