¿Por qué el número de bloques por el tamaño del bloque no coincide con el tamaño del archivo?

Esto es lo que obtengo cuando emito un statcomando para un archivo en mi linux:

yasar@yasar-laptop ~/myscripts/sysprog $ LC_ALL=C stat error.c
  File: 'error.c'
  Size: 184         Blocks: 8          IO Block: 4096   regular file
Device: 804h/2052d  Inode: 103650221   Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   yasar)   Gid: (  100/   users)
Access: 2012-04-23 17:10:28.117455882 +0300
Modify: 2012-04-21 22:18:59.967686183 +0300
Change: 2012-04-21 22:19:00.001019336 +0300
 Birth: -

Como puede ver, el tamaño de bloque para el sistema de archivos es de 4 kb y el archivo tiene 8 bloques asignados, pero su tamaño es de solo 184 bytes. ¿Por qué un archivo cuesta 8 bloques, cuando solo un bloque es suficiente?

$ echo a > a

El archivo "a" ahora contiene dos bytes, una "a" y un carácter de nueva línea.

$ stat -c "%b %B %s" a
16 512 2

Hay 16 bloques asignados, cada bloque tiene un tamaño de 512 bytes. Esta es la cantidad mínima de espacio que el sistema de archivos realiza un seguimiento.

El sistema de archivos ext4 asigna al menos 4k por archivo. Eso son 8 bloques en el disco (512 bytes). Aquí hay una muy buena explicación https://stackoverflow.com/questions/1346807/how-does-stat-command-calculate-the-blocks-of-a-file

como ves, el bloque IO también conocido como bloque de sistema de archivos es 4kB

Esto significa que el archivo asigna ocho bloques de 512 bytes

(y me deja preguntándome qué sucede si tenemos un disco moderno con un tamaño de bloque físico de 4kB)

y usted ve la razón por la cual fdisk y las herramientas de partición de Windows recientemente compensan las particiones en megabytes redondos desde el inicio del disco ... en caso de que detecte incorrectamente el tamaño de bloque de medios (tamaño de escritura NAND, etc.) es al menos algo óptimo, es decir, no escribe 4kB bloquear a través de 2x chips NAND de 128kB más o menos.