¿Qué sucede si dd ceros a la unidad donde reside dd?
Respuestas:
Hay tres cosas que pueden suceder:
- El comando se inicia, se ejecuta hasta su finalización y regresa a un mensaje. Dado que el disco se limpia de manera efectiva, no puede hacer mucho después de eso, aunque puede tener suerte con algunos comandos incorporados de shell.
- El comando comienza. En algún momento se localiza debido a la presión de la memoria. Normalmente, esto no es un problema porque algunas partes se pueden volver a cargar desde el disco (datos sin cambios) o desde el intercambio. Sin embargo, si acaba de borrarlos, el comando dd fallará parcialmente al llenar el disco.
- La tercera opción es algo de BSD. El MBR en un disco montado está protegido contra sobrescritura. Incluso si ejecuta el comando como root. Hay docenas de distribuciones de Linux, todas son ligeramente diferentes. Es muy posible que algunos de ellos emulen esto.
Hasta ahora para la teoría. Ahora para una prueba práctica.
Instalé un Ubuntu 12.10 nuevo en una VM. (Estación de trabajo VMware en win7-x64, con opciones predeterminadas y un disco virtual de 10 GB).
El comando dd se completó con éxito y me dejé caer en lo que parecía un mensaje de trabajo. Podría ingresar nuevos comandos, aunque fallarían por razones obvias.
Segmentation faulty afirmas que se completó con éxito ...?
Un experimento rápido en una máquina virtual usando Damn Small Linux indica que el comando dd se completa, como se esperaba; El programa se carga inicialmente en la memoria para ejecutarse y tiene muy poco sentido cargar el ejecutable una y otra vez durante el proceso. Finalmente, dd saldrá e informará 'no queda espacio en el dispositivo'.
Después, el sistema operativo parece funcionar normalmente a primera vista, pero se bloquea después del primer comando que ya no puede ejecutar por razones obvias y deja de responder. Una breve inspección del contenido del disco duro muestra que la partición ha sido puesta a cero.
Desde la mmappágina en Linux:
MAP_SHARED Share this mapping. Updates to the mapping are visible to other processes that map this file,
and are carried through to the underlying file. The file may not actually be updated until
msync(2) or munmap() is called.
MAP_PRIVATE
Create a private copy-on-write mapping. Updates to the mapping are not visible to other pro‐
cesses mapping the same file, and are not carried through to the underlying file. It is
unspecified whether changes made to the file after the mmap() call are visible in mapped
region.
Los ejecutables son asignados a la memoria por el núcleo a través de una llamada interna a la mmapfunción. Se MAP_PRIVATEsolicita una asignación de tipo (busque en fs/binfmt_elf.cel árbol de origen del núcleo).
Por lo tanto, se reduce al comportamiento de mmap: si los cambios en el archivo, o el dispositivo de bloque subyacente al que se hace referencia a ese archivo, se propagan a las páginas de la asignación que ya se han paginado y están presentes.
Esa página se basa en los estándares API, en lugar del comportamiento del kernel, de ahí el "no especificado". El comportamiento real es que los cambios en el archivo no se propagan a las páginas ya presentes. Por supuesto, si el programa salta repentinamente a una página de código que no ha sido paginada, y la eliminación ya ha tenido lugar, entonces obtendrá una página de todos los ceros.
Pero, muy probablemente, en el momento en que se ddborra, ya ha paginado en todas las páginas de código que necesita para continuar el ciclo de borrado. Existe la posibilidad de que una vez que finaliza el ciclo, puede llegar a algún código que se encuentra en una página no presente: por ejemplo, una función se extiende a través de un límite de página, por lo que para alcanzar la instrucción de retorno, debe buscarse una página.
Pero esa página también puede almacenarse en caché de una ddinvocación anterior .
Si. Por supuesto, también le costará la mayor parte de su sistema de archivos, pero presumiblemente ya lo sabe ...
Cometí un error recientemente. Tenía la intención de dd un img de 2 GB en la tarjeta SD, pero lo hice a sda por error dd if=rasberrypi.img of=/dev/sda. Me di cuenta de mi error y cancelé el dd, pero para entonces se habían escrito ~ 600 MB (en un disco con ~ 500 GB). La mesa de partición estaba arruinada.
El escritorio (con memoria de 10 GB y hasta por semanas) continuó funcionando durante algunas horas, ya que no pasó nada. Se las arregló para obtener archivos importantes recientemente cambiados en Dropbox, navegando en Chrome normalmente. De hecho, pude ejecutar el dd a la tarjeta SD como originalmente quería, funcionó bien.
Después de un par de horas, mi sistema de archivos entró en modo de solo lectura, y los programas aleatorios comenzaron a morir. Me introdujeron en muchos otros sistemas, podría seguir usando esas sesiones, pero al hacer una nueva sesión me dio un error que no puede encontrar el programa ssh. En este momento podría cambiar las pestañas abiertas en Chrome, pero el contenido de las pestañas parece haberse "colgado". Si actualizo, obtengo una pantalla blanca para siempre. rsyslogd estaba tomando 100% de CPU (1 núcleo) por alguna razón, probablemente estaba confundido por qué no podía vaciar registros al disco ... tal vez.
Tenía un video de 350 MB abierto (y en pausa) en VLC, todavía podía reproducirlo y saltar a cualquier parte del video. Probablemente ya que es una descarga reciente.
Podría apagar el sistema normalmente usando GUI, sin errores.
Así que esto no responde a su pregunta exactamente, pero dice qué sucede si elimina el inicio del disco ...
La mayoría de las cosas en el disco aún pueden ser recuperables, pero no me molestaré ya que (con suerte) todo lo que me importa está respaldado.
Lo más probable es que no se complete, ya que algún otro componente en ejecución solicitará un archivo que falta y entrará en pánico al núcleo. si realmente quiere poner a cero el disco, use un CD en vivo; de lo contrario, nunca podrá garantizar el resultado.