Quiero formatear mi unidad USB y confirmar que esté llena de ceros. Para formatear este es el comando que estoy usando:
sudo mkfs.vfat -I /dev/sdb
¿Cómo confirmo que el dispositivo está lleno de ceros a través de la línea de comando?
Respuesta1
Aquí también lanzaré mi sombrero al ring. Una alternativa que me encanta usar es scrub. Está en los repositorios, así que para instalarlo desde una ventana de terminal escriba:
sudo apt-get install scrub
scrubadmite muchos tipos diferentes de patrones de fregado
Available patterns are:
nnsa 3-pass NNSA NAP-14.1-C
dod 3-pass DoD 5220.22-M
bsi 9-pass BSI
usarmy 3-pass US Army AR380-19
random 1-pass One Random Pass
random2 2-pass Two Random Passes
schneier 7-pass Bruce Schneier Algorithm
pfitzner7 7-pass Roy Pfitzner 7-random-pass method
pfitzner33 33-pass Roy Pfitzner 33-random-pass method
gutmann 35-pass Gutmann
fastold 4-pass pre v1.7 scrub (skip random)
old 5-pass pre v1.7 scrub
dirent 6-pass dirent
fillzero 1-pass Quick Fill with 0x00
fillff 1-pass Quick Fill with 0xff
custom 1-pass custom="string" 16b max, use escapes \xnn, \nnn, \\
Para usar scrubpara llenar la unidad con todo, zerosprimero asegúrese de que la unidad no esté montada. Luego ejecute la siguiente línea ( -psignifica patrón a usar):
sudo scrub -p fillzero /dev/sdX
entonces deberías ver algo como esto:
scrub: using Quick Fill with 0x00 patterns
scrub: please verify that device size below is correct!
scrub: scrubbing /dev/sdh 31260704768 bytes (~29GB)
scrub: 0x00 |..... |
Algunos de los patrones utilizados para fregar deben tener un verifypase para asegurarse de que el fregado haya pasado.
Si lo desea, puede agregar hexdump(como en la respuesta de Byte Commander) o cualquiera de las otras respuestas al final para su verificación.
¡Espero que esto ayude!
Respuesta2
Aplicar ddy trpara inspección virtual:
dd if=/dev/sdb | tr '\0' 0
Solicitar ddy greppara verificación automática:
dd if=/dev/sdb | grep -zq . && echo non zero
Lo anterior es significativamente más lento que el siguiente comando optimizado:
grep -zq . /dev/sdb && echo non zero
grep -zlee en líneas delimitadas por nulos. Si todos los bytes son nulos, entonces cada línea está vacía, por lo que .nunca debería coincidir.
Por supuesto, esto no será cierto para una partición formateada: el sistema de formato utilizará algunos bytes y no serán nulos.
Respuesta3
Mi sugerencia sería hexdump. Muestra el contenido de cualquier archivo o dispositivo en formato hexadecimal como filas de 16 bytes, pero si dos líneas consecutivas son iguales, las omite.
Aquí hay un ejemplo de salida del archivo de 512 MB virtualdeviceque está lleno de ceros solo en el directorio actual de mi HDD. La columna más a la izquierda es el desplazamiento de la línea en notación hexadecimal, las 8 columnas siguientes son los datos reales, agrupados en dos bytes (4 caracteres hexadecimales):
$ hexdump ./virtualdevice
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
20000000
Actuación:
Hice el esfuerzo y comparé mi solución con las demás según el tiempo de ejecución real y el tiempo de CPU para el archivo de ejemplo descrito (512 MB, que contiene solo ceros binarios, ubicado en el disco duro).
Medí cada solución con el timecomando dos veces con el caché del disco recién borrado y dos veces con el archivo ya almacenado en caché. Los nombres de los tiempos son iguales a los del timecomando, y la fila adicional CPUes solo la suma de los tiempos USER+ SYS. Puede exceder el REALtiempo porque estoy ejecutando una máquina de doble núcleo.
Para la mayoría de las personas, las cifras interesantes son REAL(tiempo de principio a fin, como si se midiera con un cronómetro. Esto también contiene la espera de IO y el tiempo de CPU de otros procesos) y CPU(tiempo de CPU que realmente ocupa el comando).
Resumen:
El mejor rendimiento tienemuruLa segunda versión optimizada ( grep -zq . DEVICE) que utiliza increíblemente poco tiempo de procesamiento de CPU.
Cuota de rango 2 cmp /dev/zero DEVICE(Cos'solución optimizada) y mi propia solución hexdump DEVICE. Casi no hay diferencia entre ellos.
Para canalizar los datos desde dda cmp( dd if=/dev/zero | cmp - DEVICE-Cos' solución no optimizada) es muy ineficiente, la tubería parece consumir mucho tiempo de procesamiento.
Usando ddy grepmuestra el peor rendimiento con diferencia de los comandos probados.
Conclusión:
Aunque la parte más crítica de operaciones como estas es el tiempo de acceso a IO, existen diferencias significativas en la velocidad de procesamiento y la eficiencia de los enfoques probados.
Si está muy impaciente, utilice la segunda versión demuruLa respuesta ( grep -zq . DEVICE)!
Pero también puedes usar la segunda versión deCos' respuesta ( cmp /dev/zero DEVICE) o la mía ( hexdump device), ya que tienen un rendimiento casi igual de bueno.
Sin embargo, mi enfoque tiene la ventaja de que usted ve inmediatamente el contenido del archivo y puede calcular cuántos bytes difieren de cero y dónde se encuentran. Sin embargo, si tiene muchos datos alternos, la salida aumentará y probablemente se ralentizará.
Lo que debes evitar en cualquier caso es el uso ddde tuberías. El rendimiento ddprobablemente podría mejorarse estableciendo un tamaño de búfer adecuado, pero ¿por qué hacerlo de forma complicada?
Tenga en cuenta también nuevamente que la prueba se realizó en un archivo en mi disco en lugar de en un dispositivo real. Además, el archivo sólo contenía ceros. Ambos afectan las actuaciones.
Aquí están los resultados detallados:
hexdump ./virtualdevice(mi propia solución):| Uncached: | Cached: Time: | Run 1: Run 2: | Run 1: Run 2: --------+-------------------+------------------ REAL | 7.689s 8.668s | 1.868s 1.930s USER | 1.816s 1.720s | 1.572s 1.696s SYS | 0.408s 0.504s | 0.276s 0.220s CPU | 2.224s 2.224s | 1.848s 1.916sdd if=./virtualdevice | grep -zq . && echo non zero(murusolución no optimizada):| Uncached: | Cached: Time: | Run 1: Run 2: | Run 1: Run 2: --------+-------------------+------------------ REAL | 9.434s 11.004s | 8.802s 9.266s USER | 2.264s 2.364s | 2.480s 2.528s SYS | 12.876s 12.972s | 12.676s 13.300s CPU | 15.140s 15.336s | 15.156s 15.828sgrep -zq . ./virtualdevice && echo non zero(murusolución optimizada):| Uncached: | Cached: Time: | Run 1: Run 2: | Run 1: Run 2: --------+-------------------+------------------ REAL | 8.763s 6.485s | 0.770s 0.833s USER | 0.644s 0.612s | 0.528s 0.544s SYS | 0.440s 0.476s | 0.236s 0.264s CPU | 1.084s 1.088s | 0.764s 0.808sdd if=/dev/zero | cmp - ./virtualdevice(Cos'solución no optimizada):| Uncached: | Cached: Time: | Run 1: Run 2: | Run 1: Run 2: --------+-------------------+------------------ REAL | 7.678s 6.539s | 3.151s 3.147s USER | 2.348s 2.228s | 2.164s 2.324s SYS | 3.672s 3.852s | 3.792s 3.516s CPU | 6.020s 6.080s | 5.956s 5.840scmp /dev/zero ./virtualdevice(Cos'solución optimizada):| Uncached: | Cached: Time: | Run 1: Run 2: | Run 1: Run 2: --------+-------------------+------------------ REAL | 6.340s 9.183s | 1.660s 1.660s USER | 1.356s 1.384s | 1.216s 1.288s SYS | 0.640s 0.596s | 0.428s 0.360s CPU | 1.996s 1.980s | 1.644s 1.648s
Comandos utilizados:
Para las cuatro pruebas ejecuté el siguiente procedimientodos vecespara reducir imprecisiones, reemplazándolo <COMMAND>con el comando exacto del título de cada tabla.
Deje que el kernel elimine todos los cachés del disco:
sync && echo 3 | sudo tee /proc/sys/vm/drop_cachesPrimera ejecución programada (sin caché), el archivo se carga en la caché durante esto:
time <COMMAND>Segunda ejecución cronometrada (en caché). Esta vez la mayoría de los datos se toman del caché del disco en la RAM, por lo que es mucho más rápido que cuando se accede directamente al disco:
time <COMMAND>
Respuesta4
Usando cmp(gracias a muru por habernos señalado la tontería de usar una pipa):
sudo cmp /dev/zero /dev/sdX
Si obtienes un resultado como este:
cmp: EOF on /dev/sdX
La unidad está llena de ceros.
% dd if=/dev/zero of=foo iflag=fullblock bs=1M count=1 && sync
1+0 records in
1+0 records out
1048576 bytes (1,0 MB) copied, 0,00226603 s, 463 MB/s
% cmp /dev/zero foo
cmp: EOF on foo