Re: [Dump-users] Can't read next inode ...

[<phu...@wi...>]

> > I had already made a copy using dd with conv=noerror ...
> > - the dd manpage does not say what dd does about the
> >   unreadable blocks ... I suspect it skipped them entirely ...
>
> From what I read, you should have been using:
> 	dd conv=noerror,sync

I considered that, but was not entirely sure from the manpage
whether it would have the desired effect.

> Even better, ddrescue seems to be more appropriate:
> 	http://www.gnu.org/software/ddrescue/ddrescue.html

Definitely.

> > - If I try to have dump read from the image file, it
> >   misinterprets this as a request to dump the image
> >   file itself:
>
> Yes, dump really expects a block device. So you should
> 'losetup' a loop device on top of the disk file.

What would you think of adding some options:

  -D filesystem
        Interpret _filesystem_ as the filesystem to be dumped, even if
        it is neither a mounted filesystem nor a device (e.g. it is a
        regular file containing an image of an ext2 filesystem, such as
        might be produced by ddrescue(8)).  If any _files-to-dump_ are
        specified they are interpreted as names within _filesystem_.

  -i
        Ignore read errors in blocks containing inodes as well
        as in data blocks, treating the inodes in such blocks as
        unallocated, instead of terminating.  This enables recovery
        of data represented by readable inodes, even when some inodes
        are not readable.

  -X
        Any data blocks which the freelist shows as allocated, but which
        are not accounted for by any inode, are dumped with made-up names
        that include the block number.  This is mostly useful along with
        -i, or with a -D image produced by ddrescue(8) from a filesystem
        which contained unreadable inode blocks, to recover the data
        associated with the missing inodes.