¿Cómo ignorar errores de escritura al poner a cero un disco?

Digamos que quiere poner a cero un disco duro defectuoso. Desea sobrescribir tanto como sea posible con ceros. Lo que no quiere es: el process aborta en el primer error de escritura. ¿Como hacer eso?

AFAICS, plain dd solo proporciona una opción para ignorar los errores de lectura. Por lo tanto, algo así como

 dd if=/dev/zero of=/dev/disk/by-id/lousy-vendor-123 bs=128k 

no es suficiente.

ddrescue parece ser mejor para ignorar los errores, pero ¿cuál sería la línea de command óptima con él?

Mi bash con GNU ddrescue:

 ddrescue --verbose --force --no-split /dev/zero /dev/disk/by-id/lousy-vendor-123 

Prefiero los badblocks en modo de escritura destructiva para esto. Escribe, continúa haciéndolo cuando detecta errores, y finalmente le dice dónde estaban esos errores, y esta información puede ayudarlo a decidir qué hacer a continuación (¿se mezclará?).

 # badblocks -v -b 4096 -t random -o badblocks.txt -w /dev/destroyme Checking for bad blocks in read-write mode From block 0 to 2097151 Testing with random pattern: done Reading and comparing: done Pass completed, 52105 bad blocks found. (0/52105/0 errors) 

Y la list de locking:

 # head badblocks.txt 2097000 2097001 2097002 2097003 2097004 

Y lo que queda en el disco después:

 # hexdump -C /dev/destroyme 00000000 be e9 2e a5 87 1d 9e 61 e5 3c 98 7e b6 96 c6 ed |.......a.<.~....| 00000010 2c fe db 06 bf 10 d0 c3 52 52 b8 a1 55 62 6c 13 |,.......RR..Ubl.| 00000020 4b 9a b8 d3 b7 57 34 9c 93 cc 1a 49 62 e0 36 8e |K....W4....Ib.6.| 

Tenga en count que no se trata de datos aleatorios, el patrón es repetitivo, por lo que si omitiera 1MiB , vería el mismo resultado nuevamente.

También intentará verificar al volver a leer los datos, de modo que si tiene un disco que dice estar escribiendo correctamente pero devuelve datos incorrectos durante la lectura, también encontrará esos errores. (Asegúrese de que ningún otro process escriba en el disco mientras se ejecuta badblocks para evitar falsos positivos).

Por supuesto, con un disco quebrado, esto puede llevar demasiado time: no hay un código que lo saltee por completo a las áreas defectuosas. La única forma en que podrías lograr eso con badblocks sería usando un tamaño de bloques mucho más grande.

No estoy seguro si ddrescue hace esto mejor; se supone que debe hacer eso en la otra dirección (recuperar la mayor cantidad de datos posible). Puede hacerlo manualmente para dd / ddrescue / badblocks especificando el primer / último bloque …

Si el disco no está conectado por USB, entonces considere usar hdparm (versión> 9.31) para llevar a cabo una eliminación segura de ATA del disco. Este command hace que el firmware de la unidad limpie el contenido del disco, incluidos los bloques defectuosos.

Advertencia: utilice la letra de la unidad correcta. He mostrado /dev/sdX como ejemplo. No solo copie / pegue.

Primero, compruebe que comprende los commands ATA (la mayoría de las unidades fabricadas en esta última década o más deberían):

 $ sudo hdparm -I /dev/sdX . # lots of other info here... . Security: Master password revision code = 65534 supported not enabled not locked not frozen not expinetworking: security count supported: enhanced erase 202min for SECURITY ERASE UNIT. 202min for ENHANCED SECURITY ERASE UNIT. 

Las últimas dos líneas del extracto muestran que es compatible.

Por lo tanto, agregue una contraseña a la unidad (un requisito al parecer):

 $sudo hdparm --user-master u --security-set-pass p /dev/sdX security_password="p" 

y borrar

 $sudo hdparm --user-master u --security-erase p /dev/sdX security_password="p" /dev/sdX: Issuing SECURITY_ERASE command, password="p", user=user 

Más información sobre este procedimiento está disponible aquí .

 dd conv=notrunc 

Probablemente hizo el truco para mí.

El mencionado

 dd conv=noerror 

debe ser para errores de lectura (de acuerdo con la página de manual). No hay nada malo en combinar los dos.

Mi command completo para poner a cero un disco se veía así:

 dd iflag=fullblock oflag=direct conv=noerror,notrunc if=/dev/zero of=/dev/sda 

También se puede bs= agregar un bs= personalizado para algunos casos.

Un método rápido y maduro es usar sdd .

Si solo desea destruir todo el contenido, llame a:

sdd -inull bs=1m of=/dev/rdsk/cXdXtXp0 -noerror

Utilice siempre la interfaz del controller de disco "en bruto".

Si desea reparar un disco y mantener la mayor cantidad de contenido antiguo posible, llame a:

sdd if=/dev/rdsk/cXdXtXp0 of=/dev/rdsk/cXdXtXp0 bs=1m -noerror

Esto replaceá todos los bloques ilegibles con ceros a un nivel de 512 bytes. Puede modificar el recuento de rebashs a través de try=# , el valor pnetworkingeterminado es 2.

Tenga en count que sdd es más rápido que dd en caso de errores, ya que primero intenta leer con el tamaño de bloque proporcionado y, en caso de errores, lee con 512 bytes. Si hay errores de lectura, sdd realiza búsquedas aleatorias y lecturas ficticias para calmar el firmware de la unidad.

Las características mejoradas de recuperación de errores se han desarrollado en la década de 1980, mientras trabajaba para el segundo OEM más grande de Sun-Microsystems.

El código fuente Sdd está incluido en las herramientas de schily:

http://sourceforge.net/projects/schilytools/files/

Veo cuatro respuestas viables aquí:

  1. El método hdparam publicado por garethTheRed es probablemente el mejor si está conectado directamente a su computadora. Aparentemente, si lo intentas conectar a través de USB, puedes bloquear tu unidad. Si está haciendo esto para un disco que está a punto de tirar, eso puede ser algo bueno. Sin embargo, es probable que desee asegurar el borrado antes de descartarlo.

  2. La técnica reportada por "imz – Ivan Zakharyaschev" funcionará, pero puede ser muy lenta. Sugeriría que si no quiere que los datos sean recuperables, utilice /dev/urandom lugar de /dev/zero ; p.ej,

     dd iflag=fullblock oflag=direct conv=noerror,notrunc if=/dev/urandom of=/dev/sdX 
  3. Recomendaría en contra de lo siguiente. Para algo más rápido que hace lo mismo, use la técnica reportada por maxschlepzig (en la pregunta):

     ddrescue --verbose --force --nosplit /dev/urandom /dev/sdX 

    Esto será más rápido que el command dd , pero no tan rápido como el command hdparm . Vea a continuación por qué no recomiendo esto …

  4. El command badblocks también funcionará, pero no puede aleatorizar los datos de esa manera, y de nuevo será muy lento.

Finalmente, sería negligente si no señalara que la razón principal por la que las personas quieren borrar por completo un disco es porque están a punto de deshacerse de él. En ese caso, si aún no lo hizo, es posible que desee intentar recuperar el disco primero. Si lee un bloque y devuelve el error de E / S, la próxima vez que escriba en el mismo bloque, el disco intentará reasignar un bloque diferente de una list de reserva. Una vez que la list de reserva esté llena, obtendrá errores de E / S en las escrituras. Entonces es cuando realmente debería descartar el disco.

Entonces puedes hacer algo simple como:

 dd if=/dev/sdX of=/dev/null conv=noerror 

Y, luego, para reescribir los bloques defectuosos, algo así como:

 dd if=/dev/zero of=/dev/sdX bs=128k 

Si este command funciona, si eres valiente, puedes reformatear tu disco y usarlo nuevamente.

Alternativamente, puede ejecutar el command badblocks en el disco dos veces. La segunda vez debería informar que no hay bloques malos …

 badblocks -v -s -w -t random /dev/sdX badblocks -v -s -w -t random /dev/sdX 

Esto llevará más time, pero es más confiable.

También vale la pena señalar que ninguna de las técnicas realmente hace un borrado seguro, excepto el command hdparm . ¿Restrings todos esos bloques malos? Esos aún tienen algunos de sus datos originales en su mayoría intactos. Un experto en recuperación de datos podría acceder a estos para ver una pequeña cantidad de lo que estaba previamente en su disco duro.

Con respecto a ddrescue y por qué aconsejo no hacerlo, tengo el siguiente antídoto:

El problema es que ddrescure será DEMASIADO bueno para ignorar los errores. Tenía un disco duro que, de forma consistente, con dd, disminuía la velocidad de escritura en aproximadamente la marca de 102 GB y comencé a producir errores de escritura en la marca de 238 GB. Me impresionó bastante que ddrescue continuara agitando el disco a una velocidad constante, incluso sin informar errores. 17 horas más tarde, cuando estaba en los 1300 GB cuando me di count de que la luz del convertidor había dejado de parpadear. Una revisión rápida reveló que todo el receptáculo USB se había desconectado. Saqué el disco de la cuna. Noté que ddrescue simplemente me informó que todavía estaba copyndo sin errores, incluso con el disco en mis manos. Conecté el disco en otra máquina y descubrí que ahora era un bloque.

No culpo a ddrescue por hacer que la unidad sea un ladrillo. El disco estaba fallando y se convertiría en un ladrillo. Solo encuentro inquietante ddrescue ni siquiera da un recuento de errores de cuántos errores de escritura está ignorando. En este uso, ddrescue te hace pensar que ha sido completamente exitoso, independientemente de todos los errores de escritura. El hecho es que no debería haber sido capaz de continuar a toda velocidad en la sección con la desaceleración. La razón por la cual la sección fue lenta, muchos bloques han sido reubicados por la unidad, lo que causa muchas búsquedas al acceder a esa sección. Entonces ese es probablemente el momento en que la producción de ddrescue se volvió ficticia.