¿Cuáles son las diferencias entre registrar HFS+ y no registrar HFS+?

Estoy a punto de formatear una unidad de disco duro externa (HDD).

¿Cuáles son las diferencias clave entre HFS+ con registro en diario y HFS+ sin registro en diario? Aparte del hecho de que uno tiene registro diario y el otro no, ¿cómo afecta el rendimiento de la unidad (con números)?

Mi intuición es que, en un uso "normal", el diario sería el camino a seguir, pero ¿hay alguna situación en la que se deba considerar HFS + sin diario? La compatibilidad con Linux es una, ya que parece que el módulo hfsplus del kernel admite lectura y escritura en HFS+ sin registro, pero solo lectura en HFS+ con registro.

¿Algo más que valga la pena mencionar?

Respuestas (3)

No tengo números para respaldar el extracto, pero usar HFS+ no registrado es una buena idea en ciertos volúmenes que requieren velocidad absoluta, sin preocuparse (demasiado) por una posible "pérdida de datos" o "corrupción de datos" en caso de corte de energía o similar.

¿Cuándo usar HFS+ Non-journaled es una MALA idea ?

  • Unidades externas (USB, FW, ESata) que se conectan y se vuelven a conectar con frecuencia: generalmente es una mala idea, ya que estas unidades tienden a desconectarse accidentalmente con mucha frecuencia o sus fuentes de alimentación se desconectan.

  • Particiones donde la integridad de los datos es importante y la protección contra una pérdida de energía inesperada es imprescindible. (Documentos, Música, Videos, Backups, etc).

¿Cuándo es una BUENA idea usar HFS+ Non-journaled ?

  • Scratch, Temp, almacenamiento trivial y unidades y particiones similares, donde la velocidad es> integridad de datos en caso de falla de energía. Desea que su volumen de borrador de Final Cut no se registre (de todos modos, tiene un UPS, ¿no es así?). Desea que su temperatura de Photoshop no se registre. Unidades para copiar cosas (un Pen drive, por ejemplo, si se encarga de expulsarlo correctamente).

  • Cualquier otra unidad que requiera portabilidad y compatibilidad como usted señaló correctamente.

Recuerde, mantener el diario agrega una pequeña sobrecarga, pero el beneficio en caso de un desmontaje inadecuado del volumen es importante, no solo para evitar un "escaneado" completo del disco al iniciar o volver a montar, sino también en términos de asegurarse de que los datos no se corrompido en primer lugar.

El montaje de una unidad sin registro que se ha desmontado incorrectamente provocará un escaneo fsck , mientras que la unidad registrada podrá estar en funcionamiento en un período de tiempo más corto (escaneando el registro y aplicando transacciones no confirmadas).

Con respecto a la velocidad y las pruebas, no tengo mucha información para respaldar la afirmación anterior, sin embargo, que yo sepa, la diferencia de velocidad no solo es muy pequeña e incluso difícil de notar, sino que, en algunos casos, el sistema de archivos registrado es más rápido que no . -escrito en diario.

Resulta que, a pesar de la sobrecarga del diario, algunas operaciones se pueden realizar de forma asincrónica en la unidad con registro, mientras que la versión sin registro tiene que realizar las cosas de forma sincrónica.

Como referencia, busqué en Google un poco tratando de encontrar una comparación anterior (los números probablemente sean válidos ya que HFS + realmente no ha cambiado mucho desde sus primeras iteraciones en OSX, aparte de agregar registros de datos de atributos en línea y seguridad de archivos de lista de control de acceso y tal vez algo más.

Aquí está el sitio web con los gráficos:

Comparación entre HFS+ registrado y HFS+ no registrado

TL;RD:

La secuencia de copiado/duplicado/copiado de archivos fue casi igual de rápida tanto para el HFS registrado como para el no registrado. La misma secuencia con la carpeta fue nuevamente algo más rápida con el HFS registrado

(énfasis mío)

Conclusión

Estoy algo sorprendido de ver los resultados anteriores, ya que estaba un poco convencido de que usar Non-Journaled era realmente más rápido para algunas operaciones, pero aparentemente los pequeños casos en los que puede marcar la diferencia, están sobrevalorados por la "seguridad" de Journaling.

@Griffo en realidad es +1 en la pregunta por hacerme investigar y llegar a la conclusión anterior ;-) Gracias.
@MartínMarconcini, la sección de respuesta "pequeña sobrecarga" carece de la sobrecarga en términos de consumo de espacio en disco. Por ejemplo, ¿cuánto más espacio en disco estará disponible para almacenar archivos cuando el diario no esté habilitado?
@ProBackup Aunque no tengo "números", realmente creo que el tamaño del Journal será insignificante en las unidades de disco de hoy.
@MartínMarconcini Me pregunto cuál es la sobrecarga en términos de espacio en disco consumido porque: (1) La mayoría de esas funciones adicionales se agregan proporcionalmente. (2) Todos estos adicionales suman: 209,7 MB para una partición EFI, otros 1,4 MB para la capacidad de crear 128 particiones donde solo se necesita 1. (3) El hecho diskutil moveJournal externalcreará una partición Apple_Journal de 512 MB. (4) En un 2,7 TB (estilo antiguo de 3 TB), se utilizan 736 MB ( df -h) cuando se almacena solo 1 archivo (según sudo du /Volumes/Name).

El registro en diario agrega demora y complejidad a cada operación que se registrará en diario. Las escrituras en diario obligan a que los datos se escriban inmediatamente en la unidad, lo que puede hacer que otras transacciones pendientes de la unidad sean más lentas.

Un buen tratamiento de lo que hace el diario se encuentra en la Nota técnica retirada TN1150: Formato de volumen HFS Plus .

El área de diario en el sistema de archivos está muy escrita y obliga al sistema operativo a sincronizar los datos de forma regular. Esto puede interferir con grandes operaciones de lectura y escritura que se realizan al mismo tiempo que una modificación del sistema de archivos que requiere entradas de diario.

La ventaja de un sistema de registro en diario es que, en el momento del montaje, el sistema puede completar fácilmente cualquier entrada de creación de archivo o modificación de directorio que se estaba intentando. El sistema de archivos en sí se repara y se convierte en un estado consistente con extrema rapidez en comparación con una verificación completa del catálogo del sistema de archivos.

Para los usuarios principiantes, que una computadora les pida que reparen un disco no es divertido y les provoca incertidumbre y les obliga a aprender un poco sobre cómo funcionan las cosas. Sí, oculta el hecho de que podrían perder esa imagen que estaban descargando o moviendo. En la práctica, el sentido común asegura que incluso los nuevos usuarios verifiquen dos veces el archivo antes de borrarlo de la cámara cuando la "maldita computadora" se reinicia en medio de la copia de sus fotos a iPhoto. (Lo más probable es que llamen a su sistema de soporte para obtener ayuda en este punto si notan que el próximo arranque fue más lento o sucede más de dos veces por semana)

Para los usuarios avanzados que desean el rendimiento más rápido, los beneficios del registro en diario empiezan a parecerse más a penalizaciones al precio de un rendimiento más lento. Estas penalizaciones pueden ser sustanciales si el sistema ya está cerca de su capacidad o necesita el máximo rendimiento para grandes transferencias de datos sostenidas típicas de videos profesionales o algunos flujos de trabajo de bases de datos.

Cosas como estas son buenas razones para deshabilitar el registro en diario:

  • archivos de almacenamiento de base de datos
  • máquinas redundantes con rutinas de recuperación de datos después de una falla
  • Almacenamiento RAID que se encarga del diario y más
  • solo necesito velocidad adicional sin importar el costo
TN1150 pareció desaparecer del dominio apple.com, luego la edición de 2004 reapareció como un documento retirado en developer.apple.com/legacy/mac/library/#technotes/tn/… luego se trasladó a developer.apple.com/legacy/ biblioteca/technotes/tn/tn1150.html . Hay una copia con un estilo nostálgico de la edición de 2004 en dubeiko.com/development/FileSystems/HFSPLUS/tn1150.html
RAID no se ocupa del tipo de errores que previene el diario. El registro en diario es para asegurarse de que cuando el sistema operativo / sistema de archivos esté en medio de la actualización de su directorio, que es una estructura de árbol complicada en HFS, un bloqueo del sistema o la eliminación del disco no destruirá todo su árbol de directorios al perder nodos importantes ( sucursales) que incluso fsck no puede recuperar. RAID no evita eso, solo evita la pérdida de datos debido a una falla del disco, que es un tipo de pérdida de datos muy diferente.

Puede echar un vistazo a las herramientas de desarrollo para comparar el rendimiento del disco de diferentes sistemas de archivos si así lo desea, hay una guía aquí:  http://developer.apple.com/library/mac/DOCUMENTATION/Performance/Conceptual/FileSystem/Articles /MacOSXAndFiles.html

No puedo encontrar ninguna comparación con números duros, pero probablemente no hace falta decir que un sistema de archivos con registro en diario ofrece tolerancia a fallas, pero un sistema de archivos sin registro en diario ofrece un mejor rendimiento.

También agregué la etiqueta del sistema de archivos

+1 para el enlace de desarrollo, tiendo a olvidar lo útil que es ese recurso. Y un +1 invisible para el retag ;-)