Acerca de...
El equipo
Encuestas
Política de privacidad
WinTablets

Encuesta

¿Cual crees que triunfará?

Ver Resultados

Cargando ... Cargando ...

últimas entradas importantes

Categorías

Archivos

24
Ene 2018
Importante

TRIM que TRIM TRIMTRIMTRIM (y la fragmentación)

Vamos a hablar de los discos duros SSD y el comando TRIM.

“Alevamos que nos vamos”.

¿Que es el TRIM? Para ello debemos comenzar por el principio. O más bien dejar claros una serie de conceptos e ideas.

Todos conocemos las tarjeta de memoria SD y los discos flash USB. Se conocen genéricamente como memorias no volátiles porque son chips de memoria con la característica de que, una vez que se les corta la energía que los mantiene activos, continúan conservando lo que tuvieran almacenado.

Os puedo asegurar que hubo una época en la que tener algo así era el sueño húmedo de muchos electrónicos e informáticos (de los de antes, de los de destornillador y soldador en mano, no como ahora, que cualquier mindundi sentado en un cómodo sillón se hace llamar a sí mismo informático).

Pues bien, la idea subyacente de todo esto es muy sencilla: cada bit es un conjunto de registros (o de transistores) que almacenan una pequeña carga estática y que “traban” un transistor para guardar un uno o dejarlo destrabado si han de guardar un cero.

Los primeros chips de este tipo solían tener muy pocas escrituras. Es decir, que el fabricante te garantizaba, por poner un caso, diez mil (en la época en la que yo empecé a usarlas como electrónico/informático), y en cuanto escribieras diez mil veces en una posición, iniciabas una cuenta atrás para ver cuándo la celda se rompía y ya no era capaz de guardar nada. Podemos verlo como una puerta con una bisagra que se puede cerrar o abrir diez mil veces. A la diez mil una corres el riesgo de que la bisagra se rompa y entonces no es que la puedas dejar siempre cerrada o siempre abierta, es que te quedabas sin puerta y por lo tanto sin acceso a la misma.

No os podéis imaginar los trucos que había que ingeniarse para hacer que esos chips duraran igual que la vida media de los equipos en los que los ponías. Por ejemplo, para guardar un número te creabas un array de 22 elementos emparejados dos a dos, más un elemento extra. En la pareja escribías por un lado el valor que querías guardar, y por el otro incrementabas en uno el otro valor del par cada vez que escribías, y cuando ese valor llegaba al número citado de escrituras aconsejadas por el fabricante, saltabas al siguiente par y anotabas en el elemento extra que estabas en el segundo grupo. De esta manera, convertías el límite de 10.000 escrituras en 10.000 x 10, o sea 100.000. Si necesitabas más, pues añadías más celdas, pero no muchas porque el tamaño de esos chips no era muy grande.

Técnicamente, para leer no había que hacer nada. Simplemente leías el valor extra para saber dónde estaba guardado el número, y luego ibas a la posición indicada y ya tenías lo que querías. Leer no estropeaba esas celdas. Era escribir en ellas, y el proceso de escritura era (y es) un poco extraño.

No puedes simplemente decirle a la puerta que se cierre o que se abra, sino que primero la tienes que quitar antes de poder ponerla abierta o cerrada. Igualico que cuando las llevas a pintar. La idea es que antes de escribir tienes que dejar el grupo de registros en un estado de “borrado”. Si os acordáis, pasaba algo similar con los CD (y luego DVD) regrabables: había que “peinar” la resina para poder volver a grabar.

Por lo tanto, escribir en una celda de este tipo consiste en dos pasos: inicializar y luego escribir. Bueno, el proceso es un poco diferente, o al menos yo lo hacía algo diferente: primero leía el byte a modificar, me anotaba los bits que habían cambiado y solo “borraba” y grababa esos, aumentando la duración de las celdas si, encima, mantenías una función estadística de cuántas veces habías cambiado cada “bit” del “byte”, aumentando la duración de las celdas. De hecho, yo tenía máquinas que aguantaban hasta un millón de “escrituras” de este tipo por byte cuando el límite real de escrituras era de diez mil.

Pero como todo en esta vida, evoluciona, y en general evoluciona a mejor. Y aparecieron las tarjetas SD y las memorias flash. Lo que no mejoró fue el proceso de escritura. A fecha de hoy, cualquier dispositivo con el nombre de flash (menos Flash Gordon) hay que inicializarlo y luego escribir. Hasta donde yo sé no existe ningún dispositivo de este tipo que permita escribir sobre una celda ya escrita, y si en la documentación te dicen que sí es que el chip contiene un comando combinado de borrado y escritura encadenado, que suma el tiempo de borrar y el de grabar.

Y sí, el proceso de borrado es lento. Lento de cojones respecto al de escritura y todavía más lento que el de lectura.

Pues bien, como decía nacieron los pinchos USB y las tarjetas. Al principio no duraban mucho, porque los sistemas de ficheros de la época (léase FAT y sus variantes) no estaban diseñados para trabajar con este tipo de dispositivos.

En general, los USB se rompían al cabo de poco no porque hubieras escrito mucho sobre ellos, sino porque el sistema operativo escribía mucho sobre ellos. Y aquí viene una nueva disgresión.

Un sistema de ficheros consta de un índice y de los propios datos. Básicamente, hasta el más moderno consiste en eso. Cuando tu grabas un fichero en disco, ocurren dos cosas. La primera es que se guarda el contenido del fichero en sí en alguna parte del disco. La segunda es que el sistema operativo guarda, en un índice, cómo se llama ese fichero, dónde está, y la lista de sectores ocupados.

Para poder hacer pequeño lo grande, los sistemas operativos dividen el disco en una cosa llamada sectores, que a nivel del disco en sí suelen ser de 512 bytes (más otros valores de corrección de errores), pero que el sistema operativo suele agruparlos en bloques de 4Kbytes (es decir, 8 sectores de 512).

Y eso es lo que maneja el sistema operativo. Da igual que tu fichero realmente ocupe 1 byte o tres mil bytes: en disco va a ocupar, como poco 4192 bytes. O más. En general, para sistemas de ficheros antiguos, como FAT16 o FAT32, más mucho más, dependiendo del tamaño del disco.

Pero esto es una cosa que ahora no nos interesa. De momento debemos saber que cuando guardamos un fichero, el sistema operativo lo escribe en disco y luego actualiza el índice que le dice dónde está.

Bien, ahora supongamos que trabajamos con ese fichero. Le vamos añadiendo datos. O le quitamos. Cada vez que tocamos el fichero, el sistema operativo actualiza su entrada en el índice. Si el sistema cuenta con fecha de último acceso, lo tocará incluso cuando lo leamos.

¿Veis el problema? Quizás no estemos escribiendo muchas veces en el propio archivo, pero sí estamos escribiendo, y no pocas en el índice.

Y ya sabéis por dónde se suelen romper los discos USB. Los fabricantes dicen que “mueven” la FAT (el índice) a lo largo de las posiciones de memoria, pero yo no me lo creo.

Lo que sí me creo que que sistemas de ficheros más modernos, entre ellos todos los modernos incluyendo, creo, exFat, utilizan “inodes”, que viene a ser una forma de esturriar el índice a lo largo de todo el disco. Se disminuye la fragmentación del disco y se aumenta el tiempo de vida de los elementos flash.

¿Cómo se borra un fichero en un disco duro (y en un sistema de ficheros)? Pues muy sencillo: se anota que el fichero ha sido borrado en el índice, dejando sin tocar tanto el índice como el fichero en sí. Y es por eso por lo que existen utilidades que son capaces de recuperar ficheros borrados en disco. Lo que hacen es buscar las entradas del índice marcadas como borradas y luego ir al lugar donde estaba el fichero y leerlo. Con un poco de suerte no habrá sido sobreescrito. De igual modo, las entradas del índice eventualmente son sobreescritas para ficheros nuevos, pero solo cuando el índice empieza a estar lleno.

Por eso, si sois ancianos como yo, recordaréis que las utilidades que recuperan ficheros borrados de los sistemas FAT recuperaban el nombre del fichero menos la primera letra, que si tenía cierto valor especial era que había sido borrado.

Otro detalle técnico es la fragmentación de ficheros. ¿Qué es? Cuando un fichero ocupa más de un sector (del tamaño que sea, 512 o 4K), si queremos guardarlo entero, tendremos que hacerlo en dos sectores. O en tres. O en los que haga falta. Es algo evidente.

Ahora supongamos un sistema de ficheros que solo tenga 10 sectores como espacio de almacenamiento. Digamos que tenemos una caja que tiene 10 huecos, libres para llenarlos de bytes. Guardamos dos ficheros que ocupan tres sectores cada uno. El primero se guarda en los sectores 1, 2 y 3. El segundo en los 4, 5, 6. Ahora guardamos otro fichero nuevo de otros tres sectores: 7, 8 y 9. Nos queda un sector libre, el 10. Borramos el primer fichero y el último, liberando los sectores 1, 2, 3, 7, 8 y 9, que junto al 10 es el espacio libre que tenemos en este micro disco, dejando ocupados el 4, 5 y 6.

Ahora vamos a guardar un fichero que necesita cinco sectores. Espacio tenemos, porque tenemos 7 sectores libres. Pero no están uno al lado del otro. Al guardarlo, si el sistema operativo es listo, guardará una parte en los cuatro últimos (7, 8, 9 y 10), y uno en, por decir algo, el sector 3. Este archivo está guardado en dos bloques de datos no consecutivos. Está fragmentado y su valor de fragmentación es, tachán, 2 (porque está guardado en dos trozos diferentes).

Esto, en los discos duros mecánicos, hasta la llegada de sistemas de ficheros “inteligentes” como NTFS y HPFS y otros (ReiserFS, etc), era un serio problema. Pero muy serio. Porque podía llegar un momento en el que no pudieras guardar un fichero sin fragmentarlo en considerables proporciones, sobre todo si el disco empezaba a estar lleno. Y de paso era una de las causas más comunes de problemas con los sistemas de ficheros FAT, que no aceptaban bien una tasa de fragmentación alta y terminaban reventando.

Aparte de eso, ralentizaban un montón el acceso a disco, algo que se notaba, y no poco, después de pasar un desfragmentador de disco, que parecía un sistema nuevo del aumento de rendimiento, pero a partir de Windows XP (y versiones equivalentes de otros sistemas operativos), la fragmentación más o menos dejó de ser un problema ya que Microsoft y anexas aprendieron, tras muchos estudios, a minimizarla (Y aquí, el que me diga que ext3 no se fragmenta miente bellacamente).

No obstante, la caída de rendimiento en un disco mecánico con fragmentación viene del hecho de que, para leerlo o escribirlo, se requieren varias “vueltas” de los platos del disco duro. No vamos a entrar en detalles de interleave, E/S vertical, etc., simplemente diremos que la fragmentación en un disco duro hace que, en lugar de procesar los datos de forma consecutiva, los cabezales de lectura/escritura tienen que esperar más tiempo a que la rotación del disco ponga los datos que faltan a la altura de los mismos. A mayor fragmentación, más esperas.

Vale, ya lo tenemos todo para entrar en el mundo de los discos SSD. Se abre el telón y entra un disco SSD. ¿Qué es? Pues es un trasto con forma de disco duro y con protocolo de comunicaciones de disco duro completamente lleno de chips de tipo flash. Estos discos comenzaron a ser “baratos” y fiables cuando la tasa de fallos de los chips flash pasó de las decenas de miles a los millones y subiendo.

A nivel de sistema operativo, un disco SSD es igual a uno mecánico o a un trozo de RAM actuando como disco, ¿o es que ya no recordáis los discos RAM, jodíos? La diferencia está en el interfaz, y en el driver de bajo nivel, y a efectos de disco, cualquier disco duro es una secuencia consecutiva de sectores, del 1 al que sea dependiendo del tamaño del disco.

Por lo tanto, el sistema operativo escribe en un disco SSD igual (tened paciencia, ya sé que no) que en uno mecánico. Es decir, mantiene las mismas estructuras, el mismo concepto de iNode, etcétera. La ventaja es que son más rápidos que los mecánicos.

Respecto a la fragmentación, esta tampoco importa mucho ya que, en principio, los tiempos de acceso a los sectores no importan. Es decir, se tarda igual a acceder al sector 1, 2, 3, 4 y 5 que al 1, 10000, 23854, 4 y 303. Bueno, más o menos igual, porque en las memorias flash existe el “modo ráfaga” que es similar al antiguo “modo DMA”: le puedes decir a la controladora que te envíe del sector 1 al 100 en un  chorro de datos. Y la diferencia de tiempos es significativa, aunque no respecto al “alto nivel”, pero para lo que nos ocupa vamos a obviarla. Me refiero a que lo mismo existe una diferencia del orden de nano o micrsegundos y lo mismo al cabo de una hora leyendo y escribiendo en disco hemos ganado cinco segundos, por lo tanto lo obviaremos.

Por lo tanto la fragmentación en un disco SSD no importa. O eso decimos los tíos, porque sí importa, pero de manera diferente respecto a los mecánicos.

Imaginemos un fichero en un disco SSD muy fragmentado. Pongamos por caso 100 fragmentos. El índice que describe a ese fichero tiene que tener 100 entradas apuntando a cada uno de los fragmentos, mientras que uno con 10 fragmentos solo tendrá 10 entradas. En el primer caso, por poner un ejemplo, cada entrada será del tipo “sector x, 1 sector”, mientras que en el segundo será “sector y, 20 sectores” [contiguos].

Por lo tanto más memoria usada y más llamadas al driver de disco para obtener y componer el fichero completo.

¿Importa? En la realidad no mucho, pero sí para sistemas con muy poca memoria, o con discos SSD muy antiguos (y por lo tanto lentos), y para, según dice Microsoft, algunas cosas como las “copias shadow” para el System Restore y las copias de seguridad, que parece ser tienen algún tipo de límite de fragmentación.

¿Debemos desfragmentar un disco SSD por ello? No en Windows y no en MAC. De eso ya se ocupa el sistema operativo.

¿Debemos andar tocándole las meninges a Windows o a macOS y cambiar las configuraciones por defecto? No para un usuario normal (léase el 99.999999% de la población humana).

¿Por qué? Pues porque al menos Microsoft (y supongo que Apple) ya saben qué se hacen y cómo se lo hacen. Dicho esto, debemos dejar que el Defrag de Microsoft haga lo que quiera y como quiera, porque si bien antes he dicho que al sistema operativo se la trae floja el tipo de disco, eso no es cierto, y él sabe qué hacer en cada caso.

Supongo que con Apple pasará lo mismo, pero mis conocimientos no llegan a saberlo con certeza (y sin ella tampoco. Vamos, que no tengo ni pajolera idea sobre cómo y qué hace macOS).

¿Y el TRIM? ¿Qué pasa con el TRIM de los cojones?

Tenemos que volver al tema de las flash y de la escritura sobre celdas ya escritas. Con toda la evolución del mundo, y como quien dice ya a mediados del siglo XXI, las celdas de los discos SSD no se pueden sobreescribir si antes no se borran.

¿Qué pasa cuando borramos un archivo en un disco SSD? Pues igual que con uno mecánico: el fichero se marca como borrado, generalmente cambiando un byte de la entrada del índice (pro supuesto, primero se borra y luego se escribe tal byte), y no se hace nada más.

Bueno, el sistema operativo en sí hace una cosa más: envía una serie de comandos a la controladora del disco (a los chips que están dentro del disco) dándole la lista de los sectores que ocupaba el fichero borrado.

Efectivamente, ese es el comando TRIM.

La controladora los pone en su lista de “hacer después” y cuando tiene tiempo libre, los va ejecutando y va borrando las celdas liberadas, así, cuando esos sectores vuelvan a hacer falta, estarán borrados y listos para escribir.

Pero pueden ocurrir algunas “desgracias”, como por ejemplo que estemos escasos de espacio de disco, y que la controladora no haya tenido tiempo de “limpiar” sectores que están siendo reclamados. Pues lo que hace el disco es suspirar, borrar los sectores reclamados y volverlos a escribir, eliminando esos sectores de la lista de los que tiene que “TRIMear” y ralentizando las escrituras que te cagas, porque si tuviera sectores “limpios”, haría una “traslación” y escribiría sobre los nuevos, diciéndole al sistema operativo que ha habido un cambio.

Otra es que borremos muchos ficheros y luego apaguemos el ordenador, por lo que la controladora seguro que no ha tenido tiempo de borrarlos todos. Pues mala suerte, cuando encendamos el ordenador esos sectores estarán sin borrar y cuando se tengan que sobreescribir, habrá que borrarlos antes, volviendo a ralentizar los accesos a disco.

¿Se puede minimizar eso? Pues sí. Ahí es donde entra, de nuevo, el desfragmentador de Windows, que cuando toque, actuará de “recolector de basura” y, en connivencia con el disco, irá emitiendo los comando de borrado de los sectores libres y que todavía no hayan sido borrados.

Y esta es otra razón de más para dejar que Windows haga lo que quiera, y no andar metiendo mano donde no debemos.

Y de nuevo el que esto escribe no tiene ni puta idea de cómo lo hace Apple con su macOS, aunque supone que algo similar hará.

Vamos terminando. ¿Qué pasa cuando borro un fichero por accidente en un disco SSD y vacío la papelera de Windows (o de MAC)? Pues que como no corras, y hablamos de un tiempo de reacción de segundos, te has quedado sin ellos, porque en un sistema sin mucha carga, y sobre todo para ficheros de tamaño normal, el TRIM tarda milisegundos. Quizás la entrada del fichero borrado esté en algún iNode (que tampoco suele estarlo), pero el contenido del fichero se ha ido para siempre.

La vida es dura, y no, no es un motivo para desactivar el TRIM, que poderse se puede. O más bien, vale, desactivalo. Espero que tengas un disco SSD grande, y que escribas poco en él, porque en cuanto hayas escrito en todas las celdas (y ocurrirá en un par de meses), va a notar una caída en el rendimiento de tu Windows que te vas a reir de la de Spectre y Meltdown.

Y sí, hay discos duros con auto TRIM, por lo que podrías desactivar el de Windows/MAC, pero el TRIM sigue estando ahí, y posiblemente menos eficiente, porque… os cuento una historia, la última.

Más arriba he comentado que los discos duros se ven a sí mismos como una lista de sectores de 512 bytes (que con las correcciones de errores y reemplazo de bits son, si no me equivoco, setecientos y pico, pero los extra no cuentan), y el sistema operativo suele ver a los discos como una lista de sectores de 4KB (No necesariamente, al menos en Windows podemos especificar el tamaño que queramos, incluso 512 bytes, pero entonces ten una buena cantidad de RAM, y de paciencia para que el sistema mueva todo eso).

¿Como se come eso? Me refiero a cómo el sistema operativo puede entender tan diferente el tamaño del sector respecto al propio disco. Pues es el driver de bajo nivel, el que habla directamente con el disco, el que hace la conversión. Windows le dice al driver: escribe 1 sector en el sector 400, y le pasa un puntero a los 4KB que están en memoria.

El driver coge y dice al disco: escribe 8 sectores contiguos a partir del sector 400*8, pasando la dirección base original. Y santas pascuas.

¿Y el TRIM? Ah, amigo, originalmente Windows decía: haz un TRIM al sector 400, y la controladora decía al disco: haz un TRIM en el sector 400*8. Y la controladora hacía un TRIM al sector 32000. Pero no al 32001, ni al 32002, y así hasta el 32008. Porque no se lo habían ordenado, y el disco solo sabe de sectores de 512 bytes, no de sistemas de ficheros ni otras zarandajas.

Eso pasaba en Windows XP y Windows Vista. Creo que Windows 7 ya lo arregló, pero no estoy seguro. Windows 8 ya lo hacía bien.

De lo que sí estoy seguro es que había que montar un chocho de cojones tocando el registro. Y era diferente para cada fabricante de discos SSD… y con algunos fabricantes no se podía hacer…

Por lo tanto, algunos fabricantes espabilados (y que te vendían el disco más caro que otros), lo que hacían era preguntar al sistema operativo su tamaño de sector y actuar en consecuencia, borrando el número adecuado de sectores. Era lo que se conocía como “discos SDD con recolección automática de basura”, que por cierto eran los únicos discos SSD que podías instalar en un MAC (y que dieran un rendimiento aceptable después de unas semanas o meses de uso) antes de que Apple pusiera a disposición de todo quisque el habilitar el comando TRIM. Básicamente, lo que hacía el disco SSD era “hackear” MAC OS X para saber qué ficheros se habían borrado y actuar en consecuencia.

Y colorín colorado, esta historia se ha acabado.

Posdata: ¿Os suena el texto? Eso es porque habéis escuchado el episodio 20 de mi podcast, Leña al mono que es de goma, ya que esta entrada y el citado episodio ambas cosas son ambas dos la misma. Y no será la última vez que esto ocurra.

Por RFOG | Dejar un comentario | Enlaza esta entrada
contacto@wintablet.info tema WinTablet.info por Ángel García (Hal9000)