[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-ddrescue] Perl script to modify ddrescue log files

From: Burkart Lingner
Subject: Re: [Bug-ddrescue] Perl script to modify ddrescue log files
Date: Wed, 19 Oct 2011 13:31:54 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110922 Thunderbird/3.1.15

Hi Antonio!

I really like your idea of changing only those blocks in a given interval that were of type <old_types> before. Off of the top of my head I can't think of a case where I would use that, but it's nice to have such a feature as long as it's easy to also set <new_types> only, e.g. by leaving <old_types> blank. Do you have a scenario in mind where one would change only specific block types into a new type?

If I understand <new_types> correctly, "--change-types=/-+,\?/-" for instance would change non-split blocks (/) into non-tried ones (?), bad sectors (-) into non-split blocks (/) and finished blocks (+) into bad sectors (-). That would be weird. I mean, of course this would be a very general-purpose solution, but can you think of any scenario where you'd want to perform such a modification on a log file? Don't get me wrong, I like the idea of changing several block types at the same time, but then I would expect them all to change into the same new type. For instance

  ddrescuelog --change-types=\*/-,\? logfile > new_logfile

would change all non-trimmed (*), non-split (/), and bad blocks (-) into non-tried blocks (?) in one go. Essentially it would be <new_type> (singular) instead of <new_types> (plural). Then again this behavior could be achieved using your solution by duplicating <new_type> three times, i.e.

  ddrescuelog --change-types=\*/-,\?\?\? logfile > new_logfile

On top of that, in the obscure case where you do want to "rotate" block types as in the "--change-types=/-+,\?/-" example, doing it all in one command becomes a necessity if there is some overlap between <old_types> and <new_types>.

Altogether while I can't come up with any scenario where one would do that, your solution is suited for both simple and obscure cases. So the worst that could happen is that this advanced feature might never get used.

Now for something different. Since my data recovery script suite operates on blocks I had another look at the man and info pages for ddrescue and ddrescuelog. The good news is that it would be easy to adapt my scripts from ddrlogmod.pl to an improved ddrescuelog. However, I also encountered two peculiarities:

First, block size for ddrescue is 512 byte by default whereas it's 4096 byte for ddrescuelog. Apparently the assumption is that one would first use ddrescue to rescue a partition (not a whole drive) sector by 512-byte sector and then use ddrescuelog to extract a list of bad 4096-byte filesystem blocks/clusters to feed to e.g. e2fschk. While this is a sensible approach I find it somewhat confusing to have different _default_ values for the same "--block-size" parameter. Setting them both to 512 byte and expecting the user of a higher-level tool like e2fschk to manually change block size to whatever is appropriate in that case seems more consistent to me personally.

Second, both man pages mention that "numbers may be followed by a multiplier". I think it would be nice to add something like "Numbers without multiplier are interpreted as bytes." On top of that you may wanna add "See below for multiplier specification" to the parameters "-i", "-o", etc. Oh, finally one more thing: some options have a <bytes> parameter and some have a <pos> parameter according to the man pages. But aren't they really all of the same type that can be multiplied by "k", "Ki", etc.? If so, shouldn't they all be called the same?

Thanks for your continued effort to improve ddrescue and ddrescuelog. They're both great tools.

Bye, Burkart

reply via email to

[Prev in Thread] Current Thread [Next in Thread]