Quantcast
Channel: tendencias industriales – WinTablet.info
Viewing all articles
Browse latest Browse all 16

Hilbert y los discos duros SSD

0
0

¿Tienes discos duros SSD? ¿Se te ha roto alguno? Pues eso, más después del corte.Unknown

Decíamos ayer que las memorias de tipo flash tienen un número limitado de borrados, que es lo mismo que decir de escrituras, aunque si nos ponemos filosóficos deja de ser cierto ya que si suponemos una memoria flash infinita, podremos escribir una sola vez en cada una de las celdas y nos duraría infinito tiempo sin romperse jamás, obteniendo un supuesto disco flash con un número infinito de escrituras pero finito de borrados.

Vamos, como el Grand Hotel de Hilbert, pero a lo cutre y con memorias flash.

Tonterías aparte, esto de que las memorias flash tienen un número limitado de borrados termina siendo otra más de esas cosas que si bien son ciertas en la teoría, a la hora de la práctica da casi igual.

Y de nuevo nos aparece la metáfora de Hilbert, pero en este caso se trata de la similitud entre la inexistencia del Hotel pero sí de los números infinitos, y el hecho de que aunque no se te haya roto hasta ahora, seguro que lo hará en un futuro.

Vale, dejémonos de pajas mentales y entremos al meollo de la cuestión, que no es otro que trastear con el tema de los discos SSD.

 

No vamos a entrar en detalles respecto a las tarjetas SD o pinchos USB ya que en general no les damos a esos elementos el mismo uso que a un disco duro. En general los solemos llevar en el bolsillo y tener a buen recaudo y apenas se les da uso intensivo.

Y si no es así, búscate algo SSD porque si no sí que podrías estar en la cuerda floja.

Hace unos años, bastantes, que el firmware de los discos duros ofrecen al sistema operativo una interfaz uniforme llamada LBA (Logical Block Address).

chs_vs_lba

Básicamente el sistema operativo ve un disco duro, cualquier disco duro como una sucesión continua de bloques de un tamaño prefijado.

No he podido encontrar documentación oficial sobre el tema, pero el bloque típico según un disco duro es de 512 bytes, aunque el sistema operativo los quiere de 4KB, por lo tanto debe existir algún tipo de mecanismo que le diga al disco que devuelva bloques de ese tipo. De todos modos, la image de más abajo intuye una forma de convertir entre un tipo de sectores y el otro.

Por lo tanto, la mínima unidad de escritura en disco son 4 KB. Y el LBA 0 es el bloque 0, el LBA 1 el 1, y así hasta el límite que ofrezca el disco duro.

Por ejemplo, un disco duro de 1 TB, suponiendo que 1 TB sean 1024 MB (ya sabemos que intereses comerciales cambiaron el estándar no hace mucho), tendrá 268,435,456 bloques lógicos. Casi doscientos setenta millones.

IC498633

Por lo tanto, para el sistema operativo, ese disco duro contendrá dicho número de bloques.

Aquí ahora entra el tema de las particiones y los sistemas de ficheros. De eso se encarga el sistema operativo, en base a unos estándares para al menos cómo definir las particiones.

Por ejemplo, el sector LBA 0 es donde está el MBR, que consta de 512 bytes. ¿Y los 1536 bytes restantes? Pues se han perdido.

El siguiente sector libre es el LBA 1, que en general pertenecerá a la definición de las particiones, que también sigue un estándar, aunque aquí ya hay más variación y por ejemplo Windows y Apple tienen sus formatos extendidos y propietarios, que a veces son conocidos por la competencia.

Si dividimos el disco en dos unidades diferentes, a ojo de buen cubero, cada partición tendrá la mitad de bloques, empezando cada uno en el valor definido.

Por ejemplo, quizás la primera partición comience en el sector LBA 1025 y acabe en el 130.000.000, y la segunda comience en el 130.000.001 y acabe en el 268.435.456. Y es solo un ejemplo, en general, por temas de rendimiento todos estos valores quedan alineados de alguna forma para facilitar los cálculos a la hora de que el sistema operativo sepa dónde escribir.

Aquí ya hemos visto un concepto de índice. Las particiones quedan definidas en un área del disco, y el resto son los discos lógicos en sí. Digamos que indexamos las particiones.

Esta parte del disco apenas se va a escribir. Solo cuando definamos más particiones, o cambiemos su tamaño.

images-1

Ahora entra en juego el concepto de tabla de ficheros. El sistema operativo sabe dónde empieza y dónde termina el disco lógico, pero queda poder saber cómo guardar y leer ficheros.

Volvemos entonces al tema de los índices. Absolutamente todo sistema de ficheros tiene unas áreas especiales del disco en los que se guarda la información sobre dónde está realmente cada ficheros.

En los sistemas modernos en general dichos índices van repartidos a lo largo del disco lógico, casi nunca en un lugar fijo, sino que habrá diferentes índices para un número determinado de ficheros, pongamos mil, o diez mil, o cincuenta.

Para hacerlo sencillo, supongamos que nuestra partición o disco lógico tiene cien mil sectores. Pues tendremos índices en los sectores 20.000, 40.0000, 60.000 y 80.000.

¿Cómo sabe el sistema operativo dónde están guardados esos índices? En otro índice que dice dónde está cada uno de ellos.

E igual que en el caso del de las particiones, ese índice apenas se tocará cuando redimensionemos una, o necesitemos un nuevo índice porque ya hemos llenado los que tenemos con los nombres y posiciones de nuestros ficheros.

cnw-exploded-view-enterprise-SSD-large

Ahora, si nosotros escribimos un fichero nuevo, lo que hace el sistema operativo es

  1. Miro dónde comienza y termina la partición.
  2. Miro dónde está el índice de índices.
  3. Voy recorriendo los diferentes índices hasta encontrar un hueco que me convenga, y ahí anoto en qué bloques finales estará el fichero.

El paso 3 tiene truco, porque no es lo mismo guardar un fichero de 20 bytes que uno de 20 megas. El gestor de ficheros debe encontrar hueco en los sectores no usados para escribir el contenido del mismo, y luego anotar cuántos y en qué bloques ha escrito.

Además, está el tema de las transacciones que explicamos con anterioridad.

Efectivamente, no es una tarea trivial hacer un sistema de ficheros funcional, rápido y seguro.

La operación de lectura es más o menos la misma hasta el paso 3, que en lugar de buscar hueco lo que hago es buscar el fichero, ver dónde está realmente guardado y cargarlo a memoria.

2014-09-30-image-6

Pero no sé si os habéis dado cuenta de una cosa: para guardar un fichero no hay tantas escrituras en disco como pudiera parecer.

Y encima a veces, al menos en NTFS, si el fichero es pequeño, el paso 3 no se hace y se escribe directamente en el índice. Ignoro qué ocurre con los formatos de Linux y de OS X, pero si no tienen un mecanismo similar es que están obsoletos.

Hay cosas que nos hemos dejado en el tintero, como la fragmentación, ese caballo mitológico del que todo el mundo habla pero nadie sabe bien qué es y por qué ocurre. (Es un decir, claro, ningún sistema de ficheros moderno se fragmenta mucho gracias a los algoritmos de elección de bloques y a que a veces los sistemas de ficheros mueven bloques a la vez que escriben para evitarla.)

Tampoco del espacio perdido. Con bloque de 4K, 1000 archivos de 15 bytes no consumen 15K de disco, sino 60K… En teoría. En NTFS al menos, al poder guardar ficheros dentro de los índices, el desperdicio de espacio es menor.

En ese casi incluso ahorramos al menos una escritura, porque el hecho de guardar el índice guarda el fichero y nos evitamos el escribir el bloque final.

Destroyed_Hard_Drive

La pregunta que nos surge a continuación es cuántas veces escribimos un mismo archivo. Menos de las que nos creemos, porque si tu editas un fichero en Word, ¿cuántas veces lo grabas? ¿Diez? ¿Veinte? ¿Cien? ¿Mil? ¿Diez mil si estás escribiendo una novela muy larga?

Supongamos el último caso. Diez mil escrituras. Cada vez que guardas el archivo, ¿lo guardas porque has modificado todo el archivo o solo una parte? Uno puede ser un escritor prolífico, pero desde luego que no puede cambiar quinientas páginas en una tarde.

Entonces, con cada guardado de ese fichero estaremos modificando a lo sumo unos cuantos sectores, quizás solo uno o como mucho dos.

¿Cómo es eso? Pues es muy sencillo: el sistema de ficheros es muy cuco, y solo va a escribir lo que realmente ha variado, y a veces, de nuevo bajo NTFS, si los cambios son nimios, se hará en el índice en lugar de en un sector, ahorrando todavía más escrituras.

Esto nos lleva al registro, el archivo de paginación y a los ficheros mapeados en memoria de Windows. Supongo que de esto último también tendrán tanto Linux como OS X.

Esos tres tipos de ficheros son una especie de truco del almendruco. Tu escribes en RAM pero realmente estás escribiendo en disco.

Esta es la parte más crítica de todo el sistema de ficheros y la que podría romper un disco SSD más fácilmente… o no.

Al menos no con Windows modernos, y supongo que tampoco con OS X porque si no los maqueros de pro como yo pondríamos el grito en el cielo cuando se rompieran nuestros SSD, que no se rompen.

¿Por qué? Pues por la misma razón por la cual escribir un fichero a disco no escribe el fichero, sino solo los bloques modificados. Y también porque al menos Windows es consciente de ello y sólo escribe cuando no tiene más narices que hacerlo.

Y como el tiempo nos demuestra, no escribe lo suficiente como para romper nuestros SSD. No con un usuario doméstico o con uno de oficina o incluso un programador.

Yo llevo por lo menos seis años con discos SSD, compilando a tutiplén y todavía no se me ha roto ninguno, y tengo SSD de cuando eran de 64GB y costaban lo que ahora uno de 1 Tera.

Otra cosa son los servidores, pero ahí no entramos.

Por lo tanto, y como conclusión, no le tengas miedo al disco SSD. Un equipo con cinco o seis años de antigüedad revive drásticamente al ponerle uno, y los precios actuales comienzan a ser realmente competitivos sobre los mecánicos.

images

Para los curiosones, de los equipos que no traían de forma nativa un SSD, mi iMAC de mediados del 2011 tiene uno de 250GB (que estoy pensando seriamente en sustituir por uno de 1 TB) más en antiguo de 1 TB mecánico, y mi Thinkpad W550s (que últimamente me está dando grandes quebraderos de cabeza), dos, uno de 512 GB y otro M.2 de 256 GB.

Eso sin contar el WKS del curro, que tiene 4 de 64GB (los que comenté en su momento) instalados casi antes de que se inventara el comando TRIM, y uno más de 256 para contener a Windows.

Y ningún problema, así que anímate.


Viewing all articles
Browse latest Browse all 16

Latest Images

Trending Articles





Latest Images