Voortgang dd onder linux

[guanpedro]

Weet iemand misschien of ik kan achterhalen hoever het dd commando is in het kopieren van een disk naar een andere disk? (dd if=/dev/sda1 of=/dev/sdb1).

De reden hiervoor is dat de disk waarvan ik aan het kopieren erg traag is doordat er iets mee mis is en hij nu al een week bezig is...

Beetje achtergrond info:

Een tijdje geleden heb ik mijn linux software RAID systeem geupgrade van 5x 120GB naar 10x 120GB. Echter omdat ik nog een bracket voor mijn kast miste heb ik mijn raid in degraded mode gedraaid tot ik de bracket kon verkrijgen.

Nu had ik de laatste schijf er vorige week in gezet en begon de RAID te rebuilden alleen met wel 50kb/min. Dit zou betekenen dat hij er 30 dagen over zou gaan doen. De reden hiervoor is dat een van de schijven in de array in slechte staat was (maar nog wel werkte).

Ik heb al mijn belangrijke informatie weten te redden maar wil graag mijn raid kunnen rebuilden dus heb ik dd gedaan van de slechte disk naar een goede disk.

[intoxicated]

guanpedro schreef op 09 juni 2004 @ 19:17:
Weet iemand misschien of ik kan achterhalen hoever het dd commando is in het kopieren van een disk naar een andere disk? (dd if=/dev/sda1 of=/dev/sdb1).

De reden hiervoor is dat de disk waarvan ik aan het kopieren erg traag is doordat er iets mee mis is en hij nu al een week bezig is...

Dit zou moeten werken, aldus 'dd --help'

Note that sending a SIGUSR1 signal to a running `dd' process makes it
print to standard error the number of records read and written so far,
then to resume copying.
$ kill -USR1 $pid
10899206+0 records in
10899206+0 records out

_{$pid natuurlijk zelf invullen}

[ Voor 6% gewijzigd door intoxicated op 09-06-2004 19:24 ]

[guanpedro]

pardon ik lees ff niet goed, ik ga het proberen.

[ Voor 58% gewijzigd door guanpedro op 09-06-2004 19:23 ]

[DiedX]

erm, je zou het kunnen proberen op een andere PC. Al weet ik niet hoe RAID zijn gegevens opslaat op de harde schijf.

Dus HDD's in andere PC hangen. dd meuk, en terughangen. Als de schijven inderdaad FYSIEK volledig identiek zijn, gaat het werken, anders ben je alles kwijt!

[Verwijderd]

Andere alternatieven:
- dd_rescue gebruiken (word voor zover ik weet niet meer ondersteund, maar laat wel uitgebreide stats zien)
- pipebench (geloof ik) gebruiken. Hiermee "benchmark" je een pipe, en krijg je stats in bijvoorbeeld MB/s. Gebruik is ongeveer zoals onderstaande constructie:

code:

dd if=/dev/sda1 | pipebench | dd of=/dev/sdb1

[guanpedro]

intoxicated schreef op 09 juni 2004 @ 19:22:
[...]
Dit zou moeten werken, aldus 'dd --help'
[...]


_{$pid natuurlijk zelf invullen}

Raar, mijn dd geeft deze info niet en het commando geeft geen resultaat (ook geen error overigens).

Het is een Red Hat 9 installatie met dd versie 4.5.3

[guanpedro]

Verwijderd schreef op 09 juni 2004 @ 19:28:
Andere alternatieven:
- dd_rescue gebruiken (word voor zover ik weet niet meer ondersteund, maar laat wel uitgebreide stats zien)
- pipebench (geloof ik) gebruiken. Hiermee "benchmark" je een pipe, en krijg je stats in bijvoorbeeld MB/s. Gebruik is ongeveer zoals onderstaande constructie:

code:

dd if=/dev/sda1 | pipebench | dd of=/dev/sdb1

Het liefst zou ik het komen te weten van de al draaiende dd, straks is hij bijna klaar en moet ik weer overnieuw beginnen met een misschien nog slechtere disk.

dd_rescue lijkt me wel eeen goed alternatief mocht het echt niet lukken.

[Wilke]

Je kunt ook met 'vmstat 1' kijken hoeveel blocks in/blocks out er worden geschreven per seconde (natuurlijk niet als het systeem ook nog allerlei andere dingen doet).

Je hebt trouwens wel een grotere blocksize meegegeven aan dd? Standaard staat die dacht ik op 1KB ofzo, dan duurt het eindeloos (met 100% CPU-gebruik), terwijl als je blokken neemt van een MB ofzo dan gaat het veel sneller.

[Total-Control]

Ehm, normaal zou ik zegen: had dat dan ook effe in delen gedaan en niet meteen de hele zooi. Had je een scrippie kunnen maken die netjes stats weergeeft. (tip: dd met count=...)

Maar goed de oplossing voor je probleem ligt waarschijnlijk in de tool: strace

strace -f -p PID <= PID = process id dus effe 'ps -ax'

Succes!

[DDX]

guanpedro schreef op 09 juni 2004 @ 19:29:
Het is een Red Hat 9 installatie met dd versie 4.5.3

nieuwste versie van dd kan je vinden in coreutils (opvolger fileutils)

http://www.gnu.org/software/coreutils/coreutils.html

en voor redhat :

ftp://ftp.quicknet.nl/pub...coreutils-5.2.1-7.src.rpm

[ Voor 18% gewijzigd door DDX op 09-06-2004 20:00 ]

[guanpedro]

Wilke schreef op 09 juni 2004 @ 19:37:
Je kunt ook met 'vmstat 1' kijken hoeveel blocks in/blocks out er worden geschreven per seconde (natuurlijk niet als het systeem ook nog allerlei andere dingen doet).

Je hebt trouwens wel een grotere blocksize meegegeven aan dd? Standaard staat die dacht ik op 1KB ofzo, dan duurt het eindeloos (met 100% CPU-gebruik), terwijl als je blokken neemt van een MB ofzo dan gaat het veel sneller.

Ik heb niets meegegeven in de blocksize helaas, ik kon hierover niets vinden in de help of info dus dacht ik maar veiliger te zijn dit niet aan te passen. Geen hoge CPU use btw, minder dan 1 procent.

Vmstat geeft aan dat er om de 5 seconden 256 blocks in en out gaan dus ongeveer 50kb/s en een 120Gb(114GB) is 114440917? dat delen door 50 en 3600 = 635 uur, oftewel 26 dagen. Net even gekeken en hij is nu 10 dagen bezig, niet 7 dus nog twee weken te gaan lijkt me, als de disk het houdt.

Dat strace programma, kan ik daar mee uitvinden welke block hij nu schrijft?

[ Voor 7% gewijzigd door guanpedro op 09-06-2004 20:04 ]

[Wilke]

guanpedro schreef op 09 juni 2004 @ 20:01:
Ik heb niets meegegeven in de blocksize helaas, ik kon hierover niets vinden in de help of info dus dacht ik maar veiliger te zijn dit niet aan te passen.

Que

Bij mij is de eerste of tweede regel van de manual page: "It reads the input one block at a time, using the specified input block size (the default is 512 bytes)". En daarna staat hoe je de input block size opgeeft.

Maar als hij vrijwel geen CPU gebruikt dan zal het inderdaad wel door de brakke schijf komen, ik was het zelf een keer vergeten en dan zag je dat het lezen van de input achterlijk lang duurde (en 100% CPU-tijd gebruikte).

[guanpedro]

Wilke schreef op 09 juni 2004 @ 21:25:
[...]


Que

Bij mij is de eerste of tweede regel van de manual page.

Tja, dat staat niet in de man van mijn versie, ook die tip van Intoxicated stond er niet in. Ik zal wel een andere/oudere versie hebben.

[guanpedro]

Hij is nogsteeds bezig, inmiddels 13 dagen.

Dit commando ($ kill -USR1 $pid) gaf uiteindelijk wel resultaat:

125880720+0 records in
125880720+0 records out

Maar wat betekent dit? Het is niet het aantal kb denk ik aangezien de schijf maar 120gb is (eigelijk maar 114gb). Als het bytes is dan geef ik het maar op. Als het blocks is, hoe kom ik dan achter de blocksize van de schijf?

[_Squatt_]

guanpedro schreef op 12 juni 2004 @ 13:09:
Als het blocks is, hoe kom ik dan achter de blocksize van de schijf?

Het is (zo ver ik weet) het aantal blocks.

Om achter de default blocksize te komen kun je het volgende doen:

code:

$ dd if=/dev/zero of=/tmp/ddtest count=1
1+0 records in     -- dit is output van dd
1+0 records out    -- dit is output van dd
$ ls -l /tmp/ddtest
-rw-rw-r--    1 mh       mh            512 Jun 12 13:20 /tmp/ddtest

De size van /tmp/ddtest is precies 1 block. Op mijn systeem dus 512 bytes.

[ Voor 11% gewijzigd door _Squatt_ op 12-06-2004 13:21 ]

[guanpedro]

_Squatt_ schreef op 12 juni 2004 @ 13:20:
[...]

Het is (zo ver ik weet) het aantal blocks.

Om achter de default blocksize te komen kun je het volgende doen:

code:

$ dd if=/dev/zero of=/tmp/ddtest count=1
1+0 records in     -- dit is output van dd
1+0 records out    -- dit is output van dd
$ ls -l /tmp/ddtest
-rw-rw-r--    1 mh       mh            512 Jun 12 13:20 /tmp/ddtest

De size van /tmp/ddtest is precies 1 block. Op mijn systeem dus 512 bytes.

Toen ik de vraag had gesteld bedacht ik me later ongeveer hetzelfde. Bij mij is de blocksize ook 512 bytes. Hij is dus net over de helft, 60 (echte) gb.

Dank voor alle hulp iedereen, nu heb ik in ieder geval een idee waar ik aan toe ben.