¿Mejoraría el rendimiento de escritura para llenar una unidad reformateada con ceros?

Tengo una unidad de 2 TB que se llenó hasta> 99%. Eliminé las particiones fidsky las formateé mkfs.ext4.

Hasta donde yo sé, los datos reales que estaban en el disco todavía existen. Aún así la mesa de partición fue reasignada.

La pregunta es: ¿mejoraría el rendimiento de escritura para otras acciones de escritura si se limpiara el disco ? Con limpiado me refiero a llenar el disco con ceros?

Algo como

dd if=/dev/zero of=/dev/sdx bs=1 count=4503599627370496

No, no mejoraría el rendimiento.

TL; DR: las unidades de disco duro magnético rotacional no funcionan así

Primero, cuando escribe cualquier dato dado en una unidad de almacenamiento magnético rotacional, esos datos se transforman en dominios magnéticos que en realidad pueden verse muy diferentes del patrón de bits que está escribiendo. Esto se hace, en parte, porque es mucho más fácil para mantener la sincronización cuando el patrón de leer de nuevo desde el plato tiene una cierta cantidad de variabilidad, y por ejemplo una larga cadena de "cero" o valores de "uno" se haría muy difícil mantener la sincronización . (¿Ha leído 26.393 bits o 26.394 bits? ¿Cómo reconoce el límite entre bits?) Las técnicas para realizar esta transformación entre los bits de datos de la computadora y los fragmentos almacenables han evolucionado con el tiempo; por ejemplo, busque Modulación de frecuencia modificada , MMFM,Grabación de código de grupo y la tecnología más general de codificaciones limitadas de longitud de ejecución .

El proceso de grabación real, como HAMR , PMR , shingled , etc., es ortogonal a esto, ya que describe la mecánica de cómo se almacenan los dominios magnéticos en los medios físicos.

En segundo lugar, cuando escribe datos nuevos en un sector, los dominios magnéticos de las partes relevantes del plato simplemente se establecen en el valor deseado. Esto se hace independientemente de cuál era el dominio magnético anterior en esa ubicación física particular. El plato ya está girando debajo del cabezal de escritura; primero leer el valor actual, luego escribir el nuevo valor si y solo si es diferente, haría que cada escritura requiera dos revoluciones (o un cabezal adicional para cada plato), haciendo que la latencia de escritura se duplique o aumente considerablemente la complejidad de la unidad, a su vez aumento de costos. Dado que el factor limitante en el rendimiento secuencial de E / S del disco duro es la rapidez con que cada bit pasa por debajo del cabezal de lectura / escritura, esto ni siquiera ofrecería ningún beneficio al usuario. (Como un aparte, El factor limitante en el rendimiento de E / S aleatorias es la rapidez con que el cabezal de lectura / escritura se puede colocar en el cilindro deseado y luego el sector deseado llega debajo del cabezal. La razón principal por la que los SSD pueden ser tan rápidos en cargas de trabajo de E / S aleatorias es que eliminan por completo ambos factores).

Como señaló JakeGould , una de las razones por las que es posible que desee sobrescribir la unidad con algún patrón fijo (como todos los ceros) sería asegurarse de que no se puedan recuperar restos de datos almacenados previamente , ya sea de forma deliberada o accidental. Pero hacerlo no tendrá ningún efecto en el rendimiento de la unidad en el futuro, por las razones indicadas anteriormente. Otra razón, que posiblemente podría decirse que "mejora el rendimiento", como lo señaló liori , es para ayudar a comprimir las partes no utilizadas de las imágenes de disco almacenadas, pero incluso eso no mejora el rendimiento del sistema en uso.

Tú dices esto:

La pregunta es: ¿mejoraría el rendimiento de escritura para otras acciones de escritura si se limpiara el disco? Con limpiado me refiero a llenar el disco con ceros?

100% no Escribir ceros en un disco no mejora el rendimiento. Solo haría eso para destruir datos. Entonces, sabiendo eso, dices esto:

Hasta donde yo sé, los datos reales que estaban en el disco todavía existen.

Técnicamente sí ... Los datos que existían anteriormente en la unidad todavía existen en la unidad en algún nivel fundamental. Dicho esto, no existe en una forma que sea fácil de acceder o recuperar en este momento, pero podría ser una preocupación si realmente le preocupa que los datos se vean comprometidos por alguien dispuesto a hacer el esfuerzo de recuperar esos fragmentos de datos que permanecer.

Por lo tanto, si la seguridad y la privacidad son una preocupación, es posible que desee escribir ceros en la unidad para asegurarse de que todo el espacio libre se haya eliminado realmente. Pero la seguridad y la privacidad son la única razón absoluta por la que eliminaría el espacio libre con ceros, ya que hacer algo así nunca mejora el rendimiento.

Mi regalo de dos centavos para todos ustedes es mi propia experiencia, SÍ ayuda pero con precaución.

Tenía muchos SSD y, en base a mis propias pruebas, recomiendo que se llenen completamente con ceros antes de volver a escribir la tabla maestra y, en lugar de eliminar particiones, volver a crear la tabla maestra.

Más adelante explicaré por qué, pero los pasos serían ˋddˋ para llenar todo el SSD, use bs = 1M, mucho más rápido que bs = 1, y olvide el parámetro de conteo para hacerlo funcionar hasta el final (dará el error de no más espacio cuando llegue al final, eso se especula, así que no se preocupe por ver ese error, debe mostrarse) después del llenado completo, use gparted o lo que desee para escribir una tabla maestra (MBR / GPT / etc.) según sea necesario, esto 'recortará' todo el disco, luego creará particiones con el formato deseado, etc.

¿Por qué llenarlo con ceros? En pocas palabras, mi experiencia es cuando lo lleno con ceros, algunos SSD que cuando se repararon 2-24 bloques ilegibles, ya no hay más bloques ilegibles.

Ahora, lo primero que hago cuando recibo un nuevo SSD, antes de usarlo, es llenarlo completamente con ceros, para garantizar que no vuelva a sufrir los errores aleatorios comunes de los bloques ilegibles de 1 KB.

Mi experiencia: al usar software para leer / probar todo el SSD (le dice cuánto tiempo lleva leer cada 'sector') estaba obteniendo muchos pares de '512byte secttors' (bloques de 1KiB) que son ilegibles, y su posición cambia al azar y el número de fallas varía de 2 a 24, etc .; después del relleno completo con ceros y volver a crear la tabla maestra (que elimina los recortes) no más sectores ilegibles.

Mi prueba de choque: en lugar de llenar con ceros para recuperarme de tales errores, dejé que se usara un SSD, después de unas pocas horas y con solo menos de un terabyte escrito (SSD de 120GiB) murió de manera indeseable, no permite ninguno ya no puede acceder a él, la BIOS de la placa base no puede verlo, los gabinetes usb se congelan al acceder a él, por lo que ni Windows lo ve, ni Linix fdisk lo ve.

Fue una prueba de 'morir' con múltiples SSD que había comprado al mismo tiempo, idénticas ... todo lo que no puse a cero se murió, el resto tiene muchos bloques reasignados, pero sin ningún error ilegible.

Por supuesto, mi conclusión es que todos los SSD no son confiables, sin importar la marca y la capacidad.

Entonces, lo primero con ellos, en mi experiencia, es forzarlos a que se llenen por completo al menos una vez, mejor con ceros que con aleatorio (es más rápido).

Además, la mayoría de los SSD hacen recortes internos cuando se escriben con ceros (algoritmos de recolección de garbe, etc.).

Además, si primero los llena una vez, cualquier bloque que dé un error de escritura se reasignará. Es mucho mejor que tal cosa suceda sin datos vitales, cuando se escriben ceros si los datos se perdieron (todos eran ceros) no es relevante, pero si los datos son 'vitales' para el sistema operativo, es muy malo.

La mayoría de las reasignaciones de SSD hacen eso, pero al perder los datos en el bloque que dio el error de escritura, solo la 'empresa' (cuestan> 10 € por GiB) vuelve a intentar la escritura después de la reasignación correcta. Algunos SSD también perderán todos los otros 'sectores' en dicho bloque fallido (como hacer un 'descarte').

Así que mejor, pruébelo primero, después de completarlo completamente, verifique los datos SMART para ver cuántas reasignaciones aún se pueden hacer.

No es tan importante la cantidad de reasignaciones que se han realizado, la mayoría de los SSD provienen del fabricante con algunos bloques ya reasignados, encontrar uno con cero es inferior al 1%, por lo que lo importante es la relación, reasignar versus futuras reasignaciones posibles.

Es mi experiencia después de que cientos de SSD murieron a lo largo de cinco y cinco años, algunos murieron en la primera hora de uso, otros en una semana, otros en un mes; pero todo lo que había hecho con un relleno completo cero vivió de 2 a 3 años, con un 13GiB escrito cada día, 3 * 365 * 13 GiB = 13.9TiB escrito, mucho menos de lo que dicen las fabricaciones (> 100TiB).

Pero la velocidad es importante, la mayoría si en Windows (en Linux, un buen trazado de líneas 2xHDD LVM2 ofrece los mismos tiempos de arranque, pero no fallan en> 25 años), por lo que usar SSD con un precio de 0.21 € por Gigabyte (120GiB = 25 €) es vale la pena (para Windows), entre ellos deben cambiarse después de 2 o 3 años; Espero que la tecnología mejore la fiabilidad.

Para Linux no quiero más SSD hasta que sea más confiable, pero para Windows (Vista, 7 y 10) la partición del sistema es imprescindible (tiempos de arranque diez veces menores en algunos casos, con Windows Vista, en lugar de> 30 minutos de arranque) arranca> 4 minutos en mi vieja computadora portátil).

Sí, el llenado completo con ceros es imprescindible, dada mi experiencia.

Pero, solo cuando recibe el SSD y antes de usarlo para algo.

Consejo: Si el SSD no funciona bien en la recolección de basura y el sistema operativo no le dice que recorte todo, es mejor hacer un relleno completo con ceros, al final eso es lo que internamente en el SSD cuando descarta bloques. También escribir ceros borrará electrónicamente, por eso ayuda a recuperar bloques de lectura defectuosos.

Y también, cada vez que cambie datos en él, intente hacer un clon, el SSD informará que la escritura estuvo bien, también en sectores no leíbles (pueden escribirse bien pero no leídos), ningún sistema operativo está diseñado para soportar tal condición , todos suponen que si wtite está bien, se pueden leer los datos; no confunda legible con leer datos diferentes a lo que se escribió.

Esa es mi experiencia con SSD y HDD. Para el arranque y las aplicaciones de Windows, uso SSD, pero siempre con un clon hecho en HDD normales, ya que SSD muere en menos de 3 años, pero en Linux utilizo 2x o 3x HDD de 2.5 "buenas, obtengo tiempos similares en uso normal como lo que SSD daría , pero dura mucho más (> 25 años).

No estoy dispuesto a pagar> 1000 € por una unidad de estado sólido empresarial de 100GiB que funciona bien durante 10 años, prefiero pagar 25 € por 130GiB cada 2 o 3 años. El precio importa 100 € por año (empresa) versus 10 € por año (Yucon, Samsung, etc.), solo haz los cálculos.