Estou limpando um disco rígido semelhante ao descrito aqui com o mesma capacidade.
Eu recebi uma mensagem Input/output error de dd ao limpar uma partição, após o que ela parecia nem tentar gravar em outras partições.
Isso está indicando um problema com a unidade? O inversor deve continuar sendo usado ou é hora de substituir o inversor?
Para a unidade mencionada no link, passei por cada uma das 14 partições sem qualquer incidente; Lembro-me de que a saída foi semelhante à seguinte para todas as partições, exceto a última:
dd: error writing ‘/dev/sdX13’: No space left on device
287772+363 records in
287771+363 records out
301989888000 bytes (302 GB) copied, 32614.4 s, 9.3 MB/s
A última partição variou na quantidade de bytes, já que era menor que os outros.
Agora, para a unidade atual, eu corri anteriormente fdisk , esquecendo o limite de 2 TB, e passei pelo que eu acreditava ser o disco inteiro, quando, na verdade, eu limpei a primeira metade.
Depois de passar pela outra unidade, liguei esta de volta para terminar o trabalho. A unidade é um disco rígido de 3.5 "HGST conectado a um dock USB que foi conectado ao meu laptop com Debian Jessie.
Corri gdisk para particionar conforme descrito na outra postagem e surgiu com as mesmas 14 partições agora que na outra unidade.
Como eu sabia que o primeiro tempo já estava limpo, eu não queria duplicar o trabalho, então corri hexdump -C em cada partição por alguns segundos para ter certeza de que as parções 1, 2, 3, ... foram eliminados.
Eu determinei que as partições de 1 a 7 eram boas e poderiam ser deixadas em paz, e eu só precisei limpar as partições de 8 a 14.
Eu executei um comando semelhante ao seguinte no meu laptop para apagá-los um a um:
# for f in 14 13 12 11 10 9 8; do echo ------ wiping /dev/sdX${f}; nohup dd if=/dev/urandom of=/dev/sdX${f} bs=1M; echo ------ done wiping /dev/sdX${f}; done
No momento em que isso foi feito, eu tinha a seguinte saída no meu arquivo nohup.out , que apareci um pouco para mostrar apenas as partes relevantes:
...
dd: error writing ‘/dev/sdX14’: No space left on device
71381+104 records in
71380+104 records out
74917420544 bytes (75 GB) copied, 8011.74 s, 9.4 MB/s
...
dd: error writing ‘/dev/sdX13’: No space left on device
287772+363 records in
287771+363 records out
301989888000 bytes (302 GB) copied, 32614.4 s, 9.3 MB/s
...
dd: error writing ‘/dev/sdX12’: No space left on device
287996+6 records in
287995+6 records out
301989888000 bytes (302 GB) copied, 31719.2 s, 9.5 MB/s
...
dd: error writing ‘/dev/sdX11’: Input/output error
162464+5 records in
162463+5 records out
170360164352 bytes (170 GB) copied, 17934.6 s, 9.5 MB/s
...
dd: error writing ‘/dev/sdX10’: No space left on device
11+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 1.1662 s, 9.0 MB/s
...
dd: error writing ‘/dev/sdX9’: No space left on device
1+0 records in
0+0 records out
0 bytes (0 B) copied, 0.104243 s, 0.0 kB/s
...
dd: error writing ‘/dev/sdX8’: No space left on device
1+0 records in
0+0 records out
0 bytes (0 B) copied, 0.104305 s, 0.0 kB/s
A partir disso, vejo que passou pelas partições 14, 13 e 12 sem nenhum problema, e então algo aconteceu enquanto escrevia para a partição 11. Eu perdi isso à primeira vista, mas quando dei uma segunda olhada, observei partição 11 falhou com Input/output error em vez do esperado No space left on device .
Depois de ter problemas na partição 11, parece que ela começou em 10 e terminou, e não fez nada em 9 e 8. Depois disso, liguei o dock USB e desisti por alguns dias.
Esta é apenas a segunda unidade que eu tentei limpar usando este método "wipe-in-parts", e a primeira que mostrei esse problema.
Eu usei anteriormente o mesmo laptop e o mesmo dock USB para limpar mais duas unidades com capacidade semelhante, mas elas foram totalmente executadas usando of=/dev/sdX .
Eu finalmente consegui meu novo Raspberry Pi Zero W funcionando, então hoje eu pluguei o dock USB no Raspberry Pi rodando o Raspbian GNU / Linux 9 (por /etc/issue ).
Eu repeti, desta vez escrevendo para apenas partições 11 a 8 sobre isso:
# for f in 8 9 10 11; do echo ------ wiping /dev/sdX${f}; nohup dd if=/dev/urandom of=/dev/sdX${f} status=progress bs=1M; echo ------ done wiping /dev/sdX${f}; done
(FYI status=progress não foi uma boa combinação com nohup , pois poluiu o arquivo nohup.out . Por outro lado, fiquei agradavelmente surpreso que o Raspberry Pi estivesse gravando no disco 50% mais rápido que o meu Core i3 laptop.)
Finalmente, eu pulei 8 e limpei a partição 9 diretamente:
# nohup dd if=/dev/urandom of=/dev/sdX9 bs=1M
Isso funcionou melhor porque acabei limpando toda a partição:
dd: error writing '/dev/sdX9': No space left on device
287894+173 records in
287893+173 records out
301989888000 bytes (302 GB, 281 GiB) copied, 20256.4 s, 14.9 MB/s
Agora eu voltei e estou limpando a partição 8 e até agora tudo bem:
# while [ 1 ]; do ps -ef | grep sda | grep -v grep | awk '{ print $2; }' | xargs --no-run-if-empty kill -USR1; sleep 300; done
...
47653+2 records in
47653+2 records out
49969233344 bytes (50 GB, 47 GiB) copied, 3319.69 s, 15.1 MB/s
51943+3 records in
51943+3 records out
54467986944 bytes (54 GB, 51 GiB) copied, 3620.21 s, 15.0 MB/s
...
EDIT 30 de dezembro de 2017:
Olhando através de dmesg no meu laptop, não vejo mais nada relevante desde que já faz vários dias.
Olhando pelo Raspberry Pi, não vejo nada além da saída padrão quando a unidade está conectada:
[ 116.531659] usb 1-1: new high-speed USB device number 3 using dwc_otg
[ 116.531874] Indeed it is in host mode hprt0 = 00001101
[ 116.763221] usb 1-1: New USB device found, idVendor=152d, idProduct=0567
[ 116.763263] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 116.763274] usb 1-1: Product: USB3.0 Device
[ 116.763284] usb 1-1: Manufacturer: USB3.0 Device
[ 116.763293] usb 1-1: SerialNumber: ...
[ 116.783789] usb-storage 1-1:1.0: USB Mass Storage device detected
[ 116.784653] scsi host0: usb-storage 1-1:1.0
[ 117.842937] scsi 0:0:0:0: Direct-Access HGST HDN 726040ALE614 0701 PQ: 0 ANSI: 6
[ 117.849626] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 124.681886] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
[ 124.682459] sd 0:0:0:0: [sda] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB)
[ 124.682485] sd 0:0:0:0: [sda] 4096-byte physical blocks
[ 124.683187] sd 0:0:0:0: [sda] Write Protect is off
[ 124.683213] sd 0:0:0:0: [sda] Mode Sense: 33 00 00 08
[ 124.683879] sd 0:0:0:0: [sda] No Caching mode page found
[ 124.683899] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 124.688603] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
[ 124.925084] sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 sda14
[ 124.954512] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
[ 124.956387] sd 0:0:0:0: [sda] Attached SCSI disk
Aqui estão os atributos atuais do SMART:
# smartctl --attributes /dev/sda
smartctl 6.6 2016-05-31 r4324 [armv6l-linux-4.9.59+] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0
2 Throughput_Performance 0x0005 136 136 054 Pre-fail Offline - 108
3 Spin_Up_Time 0x0007 156 156 024 Pre-fail Always - 309 (Average 373)
4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 11
5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0
7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0
8 Seek_Time_Performance 0x0005 128 128 020 Pre-fail Offline - 18
9 Power_On_Hours 0x0012 100 100 000 Old_age Always - 152
10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 10
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 19
193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 19
194 Temperature_Celsius 0x0002 127 127 000 Old_age Always - 47 (Min/Max 20/50)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0
Nada grita para ser anormal.
Este é um novo disco, por isso, se houver algum problema, eu prefiro procurar o fabricante para substituí-lo na garantia.
EDIT 31 de dezembro de 2017: Bem, o apagamento foi concluído sem mais problemas durante o uso do Raspberry Pi. Não tenho certeza do que aconteceu; se alguém tiver uma visão, eu gostaria de saber sobre isso.
Tags hard-drive dd linux