El tamaño de la partición en df -h es totalmente diferente al tamaño en /proc/partitions [closed]

5 minutos de lectura

Estoy usando buildroot para construir un sistema Linux personalizado para mi raspi A+.

Usando genimage, he creado dos particiones en un Tarjeta SD de 1 GB. La primera partición es la partición de arranque. es vfat y es 32 MB. La segunda partición es ext4, es rootfs y es 512 megabytes.

Una vez que arranque mi raspi con la tarjeta SD recién grabada y escribo df -h Obtengo esto en la salida:

Filesystem                Size      Used Available Use% Mounted on
/dev/root                17.1M     14.0M      1.8M  89% /
devtmpfs                200.6M         0    200.6M   0% /dev
tmpfs                   200.7M         0    200.7M   0% /dev/shm
tmpfs                   200.7M         0    200.7M   0% /tmp
tmpfs                   200.7M      4.0K    200.7M   0% /run

como puedes ver, /dev/root es de 17,1 MB en lugar de 512 MB.

Entonces, emito cat /proc/partitions:

major minor  #blocks  name

  1        0       4096 ram0
  1        1       4096 ram1
  1        2       4096 ram2
  1        3       4096 ram3
  1        4       4096 ram4
  1        5       4096 ram5
  1        6       4096 ram6
  1        7       4096 ram7
  1        8       4096 ram8
  1        9       4096 ram9
  1       10       4096 ram10
  1       11       4096 ram11
  1       12       4096 ram12
  1       13       4096 ram13
  1       14       4096 ram14
  1       15       4096 ram15
179        0     969728 mmcblk0
179        1      32768 mmcblk0p1
179        2     524288 mmcblk0p2

Vemos claramente que la tarjeta SD (mmcblk0) es de 1 GB, la partición de arranque (mmcblk0p1) es de 32 MB y la partición rootfs (mmcblk0p2) es de 512 MB.

Entonces, para convencerme de que la partición mmcblk0p2 puede haber sido montada incorrectamente, la monto de nuevo con mount -t ext4 -o rw /dev/mmcblk0p2 /mnt y luego emito df -h otra vez:

Filesystem                Size      Used Available Use% Mounted on
/dev/root                17.1M     14.0M      1.8M  89% /
devtmpfs                200.6M         0    200.6M   0% /dev
tmpfs                   200.7M         0    200.7M   0% /dev/shm
tmpfs                   200.7M         0    200.7M   0% /tmp
tmpfs                   200.7M      4.0K    200.7M   0% /run
/dev/mmcblk0p2           17.1M     14.0M      1.8M  89% /mnt

De nuevo, veo que el tamaño de mmcblk0p2 es de 17,1 MB.

entonces mi pregunta es Por que es cat /proc/partitions devolviendo el tamaño esperado para mi partición rootfs mientras df -h devuelve un tamaño totalmente diferente y falso?

  • ¿Su arranque utiliza alguna forma de pivote de raíz? Es decir, ¿comienza montando una imagen RAM y luego cambia al sistema de archivos raíz? Es solo una suposición descabellada, pero 17M parece un buen tamaño para una imagen initramfs, y me pregunto si /dev/root, de hecho, ya no está montado en /?

    –Kevin Boone

    3 de octubre de 2017 a las 7:06

  • No, no uso ninguna forma de pivote de raíz. Mi único sistema de archivos raíz es el de mmcblk0p2.

    – slaadvak

    3 oct 2017 a las 11:01

  • No hay initramfs ni nada por el estilo? ¿Ha compilado la compatibilidad con mmcblk directamente en el kernel? Lo pregunto porque /dev/root generalmente se refiere a un initramfs, y el rootfs “real” generalmente se gira en su lugar o simplemente se monta sobre la parte superior de /. En cualquier caso, te queda un initramfs en /dev/root, pero no hace nada útil. La única forma de evitar que initramfs aceche como un apéndice inútil (según recuerdo) es no usar un initramfs en absoluto y compilar todos los controladores que necesita en el momento del arranque directamente en el kernel. Creo que /dev/root se puede ocultar, pero no recuerdo cómo.

    –Kevin Boone

    3 de octubre de 2017 a las 12:22

TL;DR: establecer BR2_TARGET_ROOTFS_EXT2_BLOCKS al 524288.

Debe distinguir la partición del sistema de archivos en la partición.

Los tamaños y compensaciones de las particiones se especifican en la tabla de particiones y puede verlos con cat /proc/partitions. Las particiones se crean con una herramienta como fdisk (o cuando usa Buildroot, a menudo lo crea genimage).

El tamaño del sistema de archivos se especifica en el superbloque del sistema de archivos, una pieza de metadatos que especifica el tamaño del sistema de archivos, cualquier opción (p. ej., si se usa el diario), tamaños de clúster, etc. Esto se crea con una herramienta como mke2fs. cuando usas mke2fs directamente en una partición, usará todo el espacio de la partición para el sistema de archivos, que normalmente es lo que desea. Sin embargo, cuando crea el sistema de archivos antes de particionando la tarjeta SD (como suele ser el caso cuando genera una imagen con, por ejemplo, Buildroot), debe especificar el tamaño para mke2fs (cfr. el página man: el segundo argumento es blocks-count).

En Buildroot, normalmente crea una imagen como un archivo y no escribe directamente en la tarjeta SD. Eso es porque el tamaño de la tarjeta SD no se conoce a priori, y porque tienes que ser root para poder escribir la tarjeta SD. Por lo tanto, no hay forma de que Buildroot sepa qué tan grande debe ser el sistema de archivos ext4 cuando crea el sistema de archivos. Antes del lanzamiento 2017.05 de Buildroot, intentaría estimar qué tan grande debería ser el sistema de archivos para que quepa todo y crear un sistema de archivos de exactamente ese tamaño. Probablemente estés en esa situación.

Para solucionar esto, debe establecer la variable de configuración BR2_TARGET_ROOTFS_EXT2_BLOCKS al 524288 (= 512 MB en bloques de 1024 bytes). O si usa Buildroot más reciente que la versión 2017.05, establecer BR2_TARGET_ROOTFS_EXT2_SIZE a 512M (la nueva opción es en bytes pero permite sufijos K, M, G).

¿Ha sido útil esta solución?