[pso] Really raw read de pe un block device

[Octavian Voicu]

Multumesc foarte mult, ddrescue e mult mai tare si merge mult mai repede!
Are (cred) si ce imi doream eu, use "direct disk access for input file" si
default citeste un cluster de 128 blocuri de 512 bytes (care din cate tin
minte e dimensiunea default a unui bloc hardware).

Am lasat optiunile default, dar i-am dezactivat optiunea "split", care
intuitiv cred ca vrea sa imparta clusterele in subclustere si sa reincerce,
ce probabil ar creste timpul semnificativ (dar tot mult mai mic decat dd
chior banuiesc).

Sa nu mai spun ca afiseaza progresul mai frumos decat dd (care nu afiseaza
nimic; poti sa-i dai kill -USR1 intr-un loop la vreo cateva zeci de secunde
ca sa vezi ce mai face).

Tot cu ocazia asta am aflat ca isi face aparitia un nou tool de compresie
fisiere, LZIP. Singura problema e ca distributiile nu prea l-au inclus inca
si nici tar-ul nu stie de el...



2009/3/6 Mircea Bardac <cs at mircea.bardac.net>

> Octavian Voicu wrote:
> > Ideea mea e sa fac un dump al intregului hdd stricat pe un hdd extern
> > folosind dd.
> >
> > Am folosit:
> >
> > dd if=/dev/hda2 of=hda2.bin bs=4096 conv=noerror
> >
> > Parametrul conv=noerror continua chiar daca apar erori pentru unele
> blocuri.
> >
> > Functioneaza, dar sunt foarte multe blocuri consecutive care dau erori,
> > urmate de alte sectiuni mari care merg fara probleme. Per total, intr-o
> > noapte a copiat vreo 8 GB (din 120).
> >
> > Intrebarea mea e daca se poate efectua un read foarte low level, fara
> > retry-uri si fara error checking, astfel incat sa citeasca sectiunile
> bune
> > si sa returneze garbage sau whatever pentru cele stricat. Astfel ar merge
> > mult mai repede si ar returna cam acelasi lucru, cred eu (in momentul de
> > fata fiecare bloc stricat inseamna sa astepte dupa un timeout si cred ca
> > face si cateva retry-uri, din ce am vazut un dmesg).
>
> Hmm.. been through this... some time ago. La fel am facut cu dd,
> conv=noerror, "poate merge mai repede cu un bs mai mare...".
>
> > Ca optimizare o solutie la care m-am gandit ar fi sa maresc block size-ul
> > pentru dd (bs=40960 de exemplu), dar ma gandesc ca nu ar avea mare efect
> > pentru ca oricum linux face un buffering al lui si nu s-ar schimba mare
> > lucru.
>
> Intr-adevar merge lent cu un bs mic. Nu mai stiu cum am rezolvat
> problema - parca totusi am crescut bs-ul.
>
> Mi se pare ca, daca se face bs mai mare si apare o eroare, tot blocul o
> sa fie scris ca 0000...000 la destinatie, cu toate ca eroarea ar fi doar
> intr-o parte a lui (nu sunt sigur de acest comportament though).
>
> Intre timp am aflat de ddrescue [1] care ar trebui sa fie mai destept
> decat dd la copierea datelor de pe un HDD-uri pe moarte - sincer, nu
> l-am folosit, dar s-ar putea sa fie un punct mai bun de start.
>
> Good luck.
>
> P.S. Dupa experienta neplacuta pe care am avut-o, toate datele
> importante se gasesc in cel putin 2 locuri [soon (si) intr-un sistem cu
>  ZFS/RAIDZ [2]].
>
> [1] http://www.gnu.org/software/ddrescue/ddrescue.html
> [2]' http://en.wikipedia.org/wiki/Non-standard_RAID_levels#RAID-Z
> [2]" http://blogs.sun.com/bonwick/entry/raid_z
>
> --
> Mircea
> http://mircea.bardac.net
> _______________________________________________
> pso mailing list
> pso at cursuri.cs.pub.ro
> http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/pso
>



-- 
Octavian Voicu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cursuri.cs.pub.ro/pipermail/pso/attachments/20090306/75571102/attachment.html