Re: [Bug-ddrescue] GDDRescue - suggestion immediate and appended image files for fast first data retrieval.

[Felix Ehlermann]

Dear Al,

I don't know which tools you are using to process the generated image. 
From my experience it is not necessary to have a "complete" image in 
order to process it.

If you need the image file to have a certain size due to a limitation of 
the repair-tool you are using you could just append bytes to the end of 
the image file. This should not cause a problem for ddrescue. If the 
data at the "appended" locations can be recovered at a later run it will 
simply overwrite your "appended bytes" at that time. If you do not want 
this to happen you can also adjust the logfile accordingly.

Depending on what your repair tool / file checking utility needs you 
might be able to quickly adjust the image file size like this:
http://en.wikipedia.org/wiki/Sparse_file#Creation

Maybe I have misunderstood your suggestion - but right now I don't see 
why pre-allocating the image file should need be integrated into 
ddrescue when padding with a few (million) 0-bytes can easily be done in 
a single line on command line.

Kind Regards
Felix

On 26.10.2012 08:33, wilsonstreet wrote:
> Hi Antonio,
>
> Yet another thought.
> Please forgive me for a bit of a barrage of suggestions,
> but I have saved a few projects up for using Gddrescue with,
> and while I am doing them I am having some thoughts.
> Please understand that I am not thinking that these will be
> done soon,
> I am just writing them while I think of them,
> so the development team can pick what ever (if any) they
> want to do.
>
> Suggestion
> ==========
>
> It is possible for the user to do several passes to
> progressively increase the amount of data that is retrieved.
> In deed, that is what the algorithm of the program does,
> even within a single run of the program.
> The objective of the program is to get maximize the amount
> of good data as soon as possible - later returning to the
> more difficult areas.
>
> It is observed that some runs can take many many hours or
> even days.
>
> In some circumstances, it may be important to get usable
> data ASAP, or get examples of data ASAP.
> The file checking utilities can not be run till an image is
> completed.
> However a completed image, is currently not generated till
> the run/pass is complete.
>
> It might be possible for Gddrescue to create intermediary
> image files, after predetermined time intervals or
> increments of data extracted.
> These could all be appended/merged (e.g. possibly using a
> similar method to retrieval from several sources) after the
> complete retrieval of data to make a single complete image.
>
> The advantage that results from the intermediary (split)
> images, is that the user is able to attempt to extract files
> from the intermediary images, which might be important to
> help get their systems returning to normal faster. It also
> would help them get an idea of how badly damaged the data
> is.
>
> This approach may possibly be achieved by using the method
> that can get data from prioritized areas of the disk first,
> just using a scenario where the disk is divided up into
> consecutive areas, to make "sub" images.
>
> Currently a user who thinks of doing this, might be able to
> manually set up the commands to do it.
> But it might be more user friendly to have the program do
> it.
>
>
> Yours
> Al
>
> _______________________________________________
> Bug-ddrescue mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-ddrescue