Tamaño de la unidad de asignación

Internamente los SSDs (y los HDD modernos también) utilizan un tamaño de sector de 4KiB, y dado que los tiempos de acceso en un SSD son prácticamente 0 (frente a los tiempos de transferencia al menos) no suele tener mucho sentido usar una unidad de asignación más grande ni más pequeña.

Más pequeña no sirve por motivos evidentes (la controladora va a tener que leer 4KiB igualmente y descartar lo que sobra, no aporta nada al rendimiento y es más overhead para todas las operaciones). Mas grande en un HDD mecánico que sabes a ciencia cierta que va a almacenar pocos archivos pequeños como dices podría tener algo de sentido, pero en general hay poco que ganar. En un SSD más grande no aporta nada porque el rendimiento en secuencial se queda igual, y el rendimiento con bloques pequeños empeora.

Yo hace años hice algunas pruebas con HDD externos y con pendrives usando tamaños de unidad de asignación más grandes, y bueno, en secuencial se podía ganar un pelín, pero eran ganancias "single digit" en ambos casos y el rendimiento con bloques pequeños caía en picado.

Así que... aunque supongo que no es la mejor respuesta que se puede dar, diría que hay motivos de sobra para dejarla por defecto (que suelen ser 4KiB en casi todos los casos). Yo la suelo dejar por defecto.

Y al hilo del siguiente ejemplo:

Ludvik escribió:Pongamos archivos de 100Mb, en una partición de 500Gb. Y que cada archivo, por desgracia, coincida que siempre desaprovechan un cluster prácticamente vacío (porque un solo archivo no puede desaprovechar varios, ¿o sí...?). Son 5.000 archivos, en teoría. Pero con un tamaño de unidad de asignación de 4kb, se perderían 20Mb. Con 32kb, serían 160Mb. En ese caso, ¿los 140Mb de diferencia son más significativos que lo que ganarías de rendimiento y evitarías de fragmentación?

...de rendimiento no se gana prácticamente nada, y la fragmentación no debería cambiar significativamente dado que los archivos grandes van a estar contiguos igualmente salvo que el disco esté tan lleno que no haya más remedio que trocearlos, incluso si la unidad de asignación es pequeña. Ese problema de fragmentación si el disco está muy lleno lo vas a tener igualmente con una unidad de asignación mayor, de hecho con el disco menos lleno, porque será más difícil que haya trozos libres contiguos mayores que la unidad de asignación.

En protocolos con más overhead y más latencia, pienso en TCP/IP por ejemplo, sí que tiene sentido subir el tamaño de algo parecido a esto como es la MTU (de 1500 bytes a 4000 o 9000, "jumbo packets" que se llaman) y aun así a veces es contraproducente en rendimiento. Yo uso jumbo frames en el NAS de mi trabajo, porque es habitual trabajar con archivos relativamente grandes, pero en el de casa que tengo "un poco de todo" no, por esto mismo.

Saludos

@Pollonidas pues mil gracias de nuevo. Estás a todas, compañero.

He buscado mucho y realmente nadie explicaba nada. Básicamente lo que encuentras, de gente preguntando, es "si no sabes, déjalo en predeterminado y ya está". Y claro, me surgía la duda...

Pero luego leías la teoría y decías, joder, es tan básica y bastante evidente, que por qué no tocar el tamaño según necesidades, y todo el mundo se emperra con el predeterminado.

Y entonces pensé en lo que básicamente me has confirmado, ¿no será que directamente no vale la pena pararse a pensar en el tamaño de la unidad de asignación, porque básicamente todas las consecuencias en el fondo serán anecdóticas, cuando menos?

Vamos, que en un ssd, las diferencias entre 4kb y 512kb, independientemente de que los archivos sean más o menos grandes, al final dan igual, ¿no?

En realidad me queda mucho más claro. No sé si es la mejor respuesta que se puede dar, pero al menos da una imagen más real de lo que supone y cuentas algo más que un simple "si no sabes no lo toques" (que leyendo la teoría a veces parece que para archivos grandes, pasar de 4kb a 8kb va casi a implicar ir el doble de rápido porque lee la mitad de fragmentos...).

Gracias de nuevo.

Ludvik escribió:Vamos, que en un ssd, las diferencias entre 4kb y 512kb, independientemente de que los archivos sean más o menos grandes, al final dan igual, ¿no?

En realidad me queda mucho más claro. No sé si es la mejor respuesta que se puede dar, pero al menos da una imagen más real de lo que supone y cuentas algo más que un simple "si no sabes no lo toques" (que leyendo la teoría a veces parece que para archivos grandes, pasar de 4kb a 8kb va casi a implicar ir el doble de rápido porque lee la mitad de fragmentos...).

Correcto. En un SSD, ir a tamaños más grandes de unidad de asignación no tiene ningún efecto con bloques más grandes que la unidad de asignación porque el cuello de botella para las transferencias no está en "saltar" de un bloque a otro que es casi instantáneo, sino en la velocidad de la propia memoria FLASH, de la controladora, y de la interfaz a la que esté conectado. Y lógicamente tiene un efecto negativo con bloques más pequeños que la unidad de asignación, porque tiene que leer el bloque entero aunque solo necesite unos pocos bytes. Y ese "leer el bloque entero" está sumando más datos que deben moverse entre la FLASH y la controladora, que como digo es el limitante a la velocidad en este supuesto en particular.

Incluso con un HDD mecánico si todos los bloques están contiguos (baja fragmentación) tampoco tiene ninguna especial ventaja que sean más grandes, ya que los va a leer todos secuencialmente y no hay tiempos de acceso en medio. Podría ser una ligera ventaja en casos como el que comentas: Un disco que almacena en su mayoría archivos grandes y está muy fragmentado. Pero sería "disparar al mensajero", porque el problema es la fragmentación más que el tamaño de la unidad de asignación, y mejorar la segunda parte solo disimula un poco un problema que va a volver a aparecer en el momento que el disco se llene un poco más.

Y lo contrario, ir a tamaños más pequeños, tampoco tiene sentido por lo que comento en el post anterior, si internamente la FLASH tiene bloques de, como mínimo, 4KB, aunque tú los quieras hacer de 512b para no desperdiciar tanto espacio para cualquier operación va a tener que leer el sector entero igualmente. Con la pega de que aquí sí podría haber una pequeña reducción en el rendimiento secuencial (con ficheros grandes), porque incluso si el tiempo de acceso es bajo, empieza a tener que tratar muchos más "trozos" de manera innecesaria.

Saludos