Re: [Bug-ddrescue] Bug-ddrescue Digest, Vol 87, Issue 15

[Garegin Asatryan]

badblocks has a problem with speed. this has been widely reported, but its developer- Theodore Tso, has constantly ignored pleas to fix it. as a result it literally takes two days to scan a 1tb hdd vs. ddrescue's couple of hours. 

On Mon, Apr 29, 2013 at 1:50 PM, <address@hidden> wrote:

Send Bug-ddrescue mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.gnu.org/mailman/listinfo/bug-ddrescue
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bug-ddrescue digest..."


Today's Topics:

   1. Re: Fill mode halting on write errors (Felix Ehlermann)
   2. Re: Fill mode halting on write errors (Niklas Holm)


----------------------------------------------------------------------

Message: 1
Date: Mon, 29 Apr 2013 18:19:53 +0200
From: Felix Ehlermann <address@hidden>
To: address@hidden, address@hidden
Subject: Re: [Bug-ddrescue] Fill mode halting on write errors
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"

Dear Niklas,

it seems you are tying to delete data on a damaged drive. From my understanding this is not the scope of ddrescue.
Is there a reason why you cant use tools like badblocks (using destructive read-write mode with a pattern of your preference)?

The way I use ddrescue I would be very unhappy if it silently ignored errors on my destination drive/image file, possibly having me end up with my rescued data on another faulty disk.

Kind Regards
Felix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/bug-ddrescue/attachments/20130429/c31f87de/attachment.html>

------------------------------

Message: 2
Date: Mon, 29 Apr 2013 19:50:21 +0200
From: Niklas Holm <address@hidden>
To: Felix Ehlermann <address@hidden>
Cc: bug-ddrescue <address@hidden>
Subject: Re: [Bug-ddrescue] Fill mode halting on write errors
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

Hi Felix!

Thank you for your answer.


2013/4/29 Felix Ehlermann <address@hidden>

> Dear Niklas,
>
> it seems you are tying to delete data on a damaged drive. From my
> understanding this is not the scope of ddrescue.
> Is there a reason why you cant use tools like badblocks (using destructive
> read-write mode with a pattern of your preference)?
>

Yes that is correct. The reason I don't use badblocks is because I didn't
know it can be used for that. Thank you for the tip! I'm pretty new at
this, I just recently found about ddrescue when trying to find a way to
rescue my bad drive. I do realize it's not the scope of ddrescue to wipe
drives, but my particular use case IS mentioned in the manual as one of the
possible usage areas for fill mode, so I think it should be properly
supported. It's seems to me like a quite easy fix too, just add a command
line argument to ignore write errors. Badblocks probably wasn't designed
for wiping drives originally either.


> The way I use ddrescue I would be very unhappy if it silently ignored
> errors on my destination drive/image file, possibly having me end up with
> my rescued data on another faulty disk.
>

I'm not asking you change the default behaviour.


>
> Kind Regards
> Felix
>


Best regards
Niklas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/bug-ddrescue/attachments/20130429/0da1afc0/attachment.html>

------------------------------

_______________________________________________
Bug-ddrescue mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-ddrescue


End of Bug-ddrescue Digest, Vol 87, Issue 15
********************************************