[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-ddrescue] Suggestion for ddrescue in _seriously hosed filesyste
Iphone Recovery Online Info
Re: [Bug-ddrescue] Suggestion for ddrescue in _seriously hosed filesystem_ environment
Wed, 29 Apr 2015 22:00:04 +0200
Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
are you sure it's the best idea to try to recover your files from inside
the NAS (which apparently has some problems, if it's segfaults)?
Wouldn't it be safer to take the HDDs out, clone them individually using
ddrescue, and try to reconstruct the RAID with a software afterwards?
On 04/29/2015 10:40 AM, Antonio Diaz Diaz wrote:
Nathan Neulinger wrote:
If you are using ddrescue against a filesystem (to recover raw file
contents) - there is a scenario where the current
behavior doesn't handle things well - when the filesystem is hosed
to the point of causing ddrescue to be killed with
Do you mean recovering a file from a damaged filesystem (mounted
read-only I hope), as in the following command?
ddrescue /somedir/somefile outfile logfile
Neither ddrescue nor the kernel should segfault in such scenario.
What versions of ddrescue and OS are you running? What
type of filesystem?
It was on a synology nas embedded linux, ext4, with some _really_
messed up filesystem content with interrupted fscks, etc. Fresh build
of latest 1.19.
I managed to finally get it to read without crashing by adding the -d
direct option, so my suggestion may not strictly be necessary.
However, until I hit on that, I managed to get all but a portion of
the file recovered - it just reran the same blocks each time since it
was crashing during the reads when trying to access certain parts of
the corrupted file.
It just seemed to me that the 'I'm trying block X' information is lost
if the process is uncleanly terminated _while_ trying that block, and
seems like there should be something that is recording reads in
progress with a fsync of that temporary log while it's running.
I'd like to see two (what I see as probably relatively simple)
improvements to alleviate this:
They are not so simple. So I would like to be sure that they are
useful before trying to implemente them.
1. Implement a "--log-every-time" option - you could use "-e" it
The '-e' option is already taken since version 0.1 (2004). You are
using GNU ddrescue. Aren't you?
Ah, missed that while reading list of options... being blind.
Nathan Neulinger address@hidden
Neulinger Consulting (573) 612-1412
Bug-ddrescue mailing list