In article CACXMG+s-KcfMV_eFRqm12asaQ8rDABL123bD+ur8jwNVLyQXjw@mail.gmail.com, Erick Perez - Quadrian Enterprises eperez@quadrianweb.com wrote:
@tonymountifield Does this still hold true? https://superuser.com/a/1075837
It wouldn't surprise me. What I take away from those tests is that it is indeed important to use a bs= setting that corresponds to the disk physical block size, which is why I said to use bs=4096.
When I used "conv=noerror,sync bs=4096" I got an image of the correct size. That seems to correspond with what is said in the comment you linked to.
Cheers Tony
On Sun, Sep 27, 2020 at 7:21 AM Tony Mountifield tony@softins.co.uk wrote:
In article E02FA554-9D6D-4E7D-8A78-5FBDE1DE939D@kicp.uchicago.edu, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On Sep 26, 2020, at 8:05 AM, Jerry Geis jerry.geis@gmail.com wrote:
I have a disk that is flagging errors, attempting to rescue the data.
I tried dd first - if gets about 117G of 320G disk and stops
incrementing
the save image any more.
did you try
dd conv=noerror …
this flag makes dd not stop on input error. Whatever is irrecoverable is
irrecoverable, but this way you will get stuff
beyond failure point.
You need conv=noerror,sync so that unreadable sectors get replaced by zeros instead of not being written out at all. Without sync, the filesystem geometry on the destination image will be wrong after the first error.
You also need bs=4096 so that ONLY the bad sector(s) get zeroed, and not the surrounding ones. If you have, say, bs=1M, then you will get a megabyte of zeros if any block within that megabyte is bad.
I'm speaking from recent experience!
Cheers Tony
-- Tony Mountifield Work: tony@softins.co.uk - http://www.softins.co.uk Play: tony@mountifield.org - http://tony.mountifield.org _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
--
Erick Perez Quadrian Enterprises S.A. - Panama, Republica de Panama Skype chat: eaperezh WhatsApp IM: +507-6675-5083
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos