3 votos

Por qué fsck_hfs es lento en *journaled* HFS+

A veces mis discos externos se desprenden de forma poco limpia, y en la siguiente conexión es necesaria una comprobación del disco.

Lo que me sorprende ahora es ver un proceso de comprobación de disco lento en un sistema de archivos con diario . Según el manual, eso requiere el -f pero eso parece incorrecto. ¿El objetivo de llevar un diario no es que nunca ¿necesita una revisión completa del disco?

En detalle, MacOS inició fsck automáticamente con -y :

$ ps auxw|grep fsck
root              3792   1.1  2.3  6429668 389400   ??  U     2:09pm   0:05.10 /System/Library/Filesystems/hfs.fs/Contents/Resources/./fsck_hfs -y /dev/disk3s2

Entonces interrumpí el proceso y lo volví a ejecutar a mano sin -y para un mayor control, como suelo hacer:

 sudo fsck_hfs /dev/disk3s2
** /dev/rdisk3s2
   Executing fsck_hfs (version hfs-407.50.6).
** Checking Journaled HFS Plus volume.
   The volume name is MyPass4T-TM2
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.

FWIW, esto es en un sparsebundle HFS+ con diario, que uso para Time Machine, alojado dentro de un sistema de archivos externo (ExFAT).

3voto

Oskar Puntos 1242

Gran pregunta.

Apple sólo registra los cambios en el sistema de archivos y no los datos, por lo que cuando se inicia una comprobación completa del sistema de archivos, el archivo de catálogo, el archivo de extensiones, los superbloques y los recuentos de asignación se comprueban manualmente / se cruzan / y, opcionalmente, se reconstruyen o refrescan. El diario no ahorra tiempo en la comprobación de un volumen - sólo ahorra tiempo si se pierde la energía o la conexión cuando se está realizando una modificación de los metadatos del sistema de archivos. Por lo tanto, puede ejecutar fsck menos a menudo, pero no acorta el tiempo de ejecución de fsck

Cada uno de los enlaces duros es referenciado/evaluado en el lado emisor y receptor.

Este proceso es altamente intensivo en IO, por lo que si tiene discos giratorios, podría tener semanas para comprobar un volumen de 20 TB en un RAID si hay varios discos involucrados.

Un buen punto de referencia es comprobar cuántos archivos hay en el volumen en la pestaña de información y observar el Monitor de Actividad para ver cuáles son las IOPS de lectura y escritura y la tasa de datos. Luego puedes comparar eso con el protocolo (USB C y 3.0 y Thunderbolt son más rápidos que cualquier almacenamiento realista que puedas tener) para saber que el progreso está limitado por la unidad y no por la CPU o la conexión.

En tu caso, el sparsebundle añade una sobrecarga insignificante, pero el Time Machine es el verdadero paralizador. Utiliza enlaces duros por lo que cada archivo puede ser referenciado docenas o incluso cientos de veces. Tengo algunos volúmenes de Time Machine que nunca terminarán un fsck en que no dejaré que funcione durante las semanas necesarias.

En lugar de eso, los dejo como de sólo lectura - los pongo en un estante y sólo saco archivos de ellos o los borro cuando sé que no necesito ningún archivo de ellos.

Algunas personas realizan una cirugía heroica en los datos de Time Machine para revivirlos. Yo prefiero comprar otra unidad de 100 dólares y empezar de nuevo cada 6 o 18 meses, añadiendo nuevos destinos frescos y envejeciendo mis destinos más antiguos cuando se acercan a llenarse.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X