That sentence is severely misleading. If you don't want to get into gory details, forget you read it and just assume that -size
looks at the size of the file.
The size of a file is the number of bytes that you can read from it. A file of size N is an array of N bytes.
When you pass a unit other than bytes (c
) to -size
, the find
command rounds the file size up to a multiple of the unit. For example, -size 11k
matches files of 10,240 to 11,263 bytes; -size 12345M
maches files of 12,943,622,145 to 12,944,670,720 bytes. The default unit, for historical reasons, is called blocks and its value is 512 bytes.
That was the easy part. Now on typical filesystems, the data of a file is stored in blocks. For a filesystem whose block size is 512 bytes¹, a 5123-byte file would occupy 11 data blocks (the last one being only partially used). So find -size 11
normally matches files that consist of 11 blocks.
In fact there are possible complications. The OS needs to have a place where to store the location of all the blocks that make up the file. If there are too many blocks, it needs to allocate some more blocks just to contain the addresses of other blocks. Such blocks are called indirect blocks. The find
manual tells you that these blocks are not taken into account — which is unsurprising since find
isn't counting blocks, it's looking at the file size.
Conversely, it's possible to have a file that uses fewer blocks than you'd expect from its size, because of compression. Classical unix filesystems only implement a crude form of compression: blocks that consist exclusively of null bytes may be omitted. This is known as sparse files.
A program can know how many blocks have been allocated to a file; this is the st_blocks
field of the stat
structure, as opposed to st_size
. GNU find only uses this in its display code for -ls
and -printf
, never for any predicate. The st_blocks
value gives a crude indication of how much space the file occupies on the disk, which can be less than the file size if the file is sparse, but it does not take indirect blocks into account.
¹ Ext2, ext3 and ext4 have blocks of 1kB, 2kB or 4kB.
find
would make any claims whatsoever about what kind of "indirect" or "not actually allocated" blocks are or are not counted. I think those claims might well be anachronistic or applicable only to some particular but unspecified type of filesystem. I can only imagine thatfind
simply uses whatever the filesystem reports in thest_blocks
field of thestat
structure; what that value is and how it is calculated is totally up to each type of filesystem. – Celada Jun 3 '13 at 22:06find
is (usually) not even capable of accessing that information (i.e. read the inodes directly). – Hauke Laging Jun 3 '13 at 22:14