¿Por qué una comprobación de disco Ext4 es mucho más rápida que NTFS?

Hoy tuve una situación en la que reinicié mi computadora y decía que necesitaba verificar la consistencia del disco. Aproximadamente 10 minutos después (al "1%" completado), me di por vencido y decidí dejarlo funcionar cuando me vaya a casa.

A modo de comparación, la computadora de mi casa usa Ext4 para todas las particiones, y las comprobaciones de disco (que se ejecutan una vez por semana) solo toman un par de segundos. Recuerdo haber leído que tener una verificación rápida del disco era una prioridad, pero no sé cómo podrían hacerlo.

Entonces, ¿cómo hace Ext4 las comprobaciones de disco tan rápido? ¿Hay algún gran avance en hacer esto después de que NTFS salió (hace ~ 10 años)?

Nota: El disco NTFS es ~ 300 GB y el disco Ext4 es ~ 500 GB. Ambos están medio llenos.

Hay dos razones principales para la diferencia de rendimiento y dos posibles . Primero, las razones principales:

Mayor rendimiento de ext4 frente a NTFS

Varios puntos de referencia han concluido que el sistema de archivos ext4 real puede realizar una variedad de operaciones de lectura y escritura más rápido que una partición NTFS. Tenga en cuenta que si bien estas pruebas no son indicativas del rendimiento en el mundo real, podemos extrapolar estos resultados y usar esto como una razón.

En cuanto a por qué ext4 realmente funciona mejor, entonces NTFS puede atribuirse a una amplia variedad de razones. Por ejemplo, ext4 admite la asignación retrasada directamente. Sin embargo, una vez más, las ganancias de rendimiento dependen estrictamente del hardware que esté utilizando (y puede negarse totalmente en ciertos casos).

Requisitos de comprobación de sistema de archivos reducidos

El sistema de archivos ext4 también es capaz de realizar comprobaciones más rápidas del sistema de archivos que otros sistemas de archivos de registro en diario equivalentes (por ejemplo, NTFS). De acuerdo con la página de Wikipedia:

En ext4, los grupos de bloques no asignados y las secciones de la tabla de inodo se marcan como tales. Esto permite que e2fsck los omita por completo en una verificación y reduce en gran medida el tiempo que lleva verificar un sistema de archivos del tamaño que ext4 está diseñado para soportar. Esta característica se implementa en la versión 2.6.24 del kernel de Linux.

Y ahora, las dos posibles razones:

Sistema de archivos que verifican las utilidades mismas

Ciertas aplicaciones pueden ejecutar diferentes rutinas en los sistemas de archivos para realizar realmente la "verificación" de estado. Esto se puede ver fácilmente si usa la utilidad fsck establecida en Linux versus la utilidad chkdsk en Windows. Estas aplicaciones están escritas en diferentes sistemas operativos para diferentes sistemas de archivos. La razón por la que menciono esto como una posible razón es que las llamadas de sistema de bajo nivel en cada sistema operativo son diferentes, por lo que es posible que no pueda comparar directamente las utilidades utilizando dos sistemas operativos diferentes.

Fragmentación de disco

Este es fácil de entender y también nos ayuda a comprender las diferencias entre los sistemas de archivos. Si bien todos los datos digitales contenidos en un archivo son iguales, la forma en que se almacena en el disco duro es muy diferente de un sistema de archivos a otro. La fragmentación de archivos obviamente puede aumentar las velocidades de acceso, atribuyéndose a una mayor diferencia de velocidad.

Según tengo entendido, ext4 intenta escribir datos en la mayor brecha continua de inodos abiertos donde actualmente no hay datos. Esto reduce severamente la latencia cuando esos archivos tienen que leerse, ya que, en su mayor parte, todo el contenido de un archivo individual se ubicaría principalmente en una sola pista continua, por lo que el cabezal de las unidades tendría menos búsqueda al encontrar cada bloque que contiene los datos eso constituye ese archivo.

(Ext4) todavía puede fragmentarse, pero mucho menos y no necesariamente de una manera que afecte gravemente el rendimiento de lectura / escritura como con NTFS. En NTFS, los datos se escriben en los primeros bloques abiertos en la ruta de la cabeza.

Entonces, donde sea que se encuentre la cabeza y haya bloques abiertos, escribe la mayor cantidad de datos que pueda caber y luego escribe donde sea que aterrice en otra parte del disco cuando la cabeza tiene que moverse, por ejemplo, a otra parte del disco para acceder a un archivo diferente que tiene que abrirse en un programa que acaba de cargar mientras ese otro archivo aún se estaba escribiendo.
Esto significa que si el archivo es grande, es probable que se extienda en bloques separados entre sí en pistas separadas y es por eso que a menudo se necesita desfragmentar para NTFS.

Además, por qué los servidores generalmente no lo usan, ya que hay una E / S más pesada con un servidor donde los datos se escriben y leen constantemente desde el disco 24/7.

Además, no estoy seguro, pero si chkdskverifica la integridad de cada archivo (lo cual creo tanto como lo fsckhago), entonces también sería más lento en comparación debido a lo que acabo de describir sobre la fragmentación en NTFS.

Windows nunca debería necesitar verificar un volumen NTFS al inicio. Si es así, algo ha salido muy mal, algo mucho peor que un simple BSOD o un corte de energía. Existe una gran posibilidad de que algunos de sus datos también hayan sido dañados por lo que haya dañado los metadatos del sistema de archivos. La comprobación del disco no puede detectar eso; Su único propósito es evitar una mayor corrupción.

KB2854570 enumera algunas razones por las que esto puede suceder. Uno está hibernando un sistema operativo con un volumen montado, modificando el contenido del volumen y luego reanudando la hibernación con el volumen (re) adjunto. Si hace eso, hay una alta probabilidad de corrupción de datos silenciosa.

No sé por qué su sistema de archivos ext4 se estaba revisando una vez por semana, pero probablemente (con suerte) no se debió a una crisis comparable que se repitió semanalmente. Probablemente solo estaba haciendo una verificación de cordura de rutina, y no una verificación de consistencia completa.