Perry Hutchison | 11 Aug 00:09 2008

Can't read next inode ...

I am attempting to dump a filesystem which has developed a bad
block, and the bad block happens to contain some of the inodes.
Even though I specified a large -I number, dump is terminating
upon reaching the unreadable inode block.

How do I get it to just skip over unreadable blocks, including
unreadable inode blocks, and dump whatever can be read?

(Aologies if the answer is in the archives; when I attempted to
search them I got "Unable to connect to Search Server".)

# /sbin/dump -0 -f - -I 32767 /dev/hda7 | rsh ...
  DUMP: Date of this level 0 dump: Sun Aug 10 14:39:51 2008
  DUMP: Dumping /dev/hda7 (an unlisted file system) to standard output
  DUMP: Added inode 8 to exclude list (journal inode)
  DUMP: Added inode 7 to exclude list (resize inode)
  DUMP: Label: /cricket1
  DUMP: mapping (Pass I) [regular files]
/dev/hda7: Can't read next inode while scanning inode #212576

# tune2fs -l /dev/hda7
tune2fs 1.32 (09-Nov-2002)
Filesystem volume name:   /cricket1
Last mounted on:          <not available>
Filesystem UUID:          55ba4ec9-762f-4df8-beb5-d608a59cc7bb
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal filetype sparse_super
Default mount options:    (none)
Filesystem state:         clean with errors
(Continue reading)

Stelian Pop | 20 Aug 17:01 2008
Picon

Re: Can't read next inode ...

Hi Perry,

Le dimanche 10 août 2008 à 15:09 -0700, Perry Hutchison a écrit :
> I am attempting to dump a filesystem which has developed a bad
> block, and the bad block happens to contain some of the inodes.
> Even though I specified a large -I number, dump is terminating
> upon reaching the unreadable inode block.
> 
> How do I get it to just skip over unreadable blocks, including
> unreadable inode blocks, and dump whatever can be read?

I'm afraid you can't.

At this point you should make a low level copy of the filesystem (using
dd for example), and try to repair the filesystem using e2fsck. Once the
filesystem is clean, you should be able to use dump again...

Stelian.
--

-- 
Stelian Pop <stelian <at> popies.net>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Dump-users mailing list
Dump-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dump-users
(Continue reading)

Perry Hutchison | 20 Aug 21:12 2008

Re: Can't read next inode ...

> > I am attempting to dump a filesystem which has developed a bad
> > block, and the bad block happens to contain some of the inodes.
> > Even though I specified a large -I number, dump is terminating
> > upon reaching the unreadable inode block.
> > 
> > How do I get it to just skip over unreadable blocks, including
> > unreadable inode blocks, and dump whatever can be read?
>
> I'm afraid you can't.
>
> At this point you should make a low level copy of the filesystem
> (using dd for example), and try to repair the filesystem using
> e2fsck ...

I had already made a copy using dd with conv=noerror, and have
encountered two problems (one definite, the other suspected):

- If I try to have dump read from the image file, it misinterprets
  this as a request to dump the image file itself:

  $ ls -l hda7-ddImage
  -r--r-----  1 phutchis wrs 12707980800 Aug  8 21:51 hda7-ddImage

  $ file hda7-ddImage
  hda7-ddImage: Linux rev 1.0 ext3 filesystem data (errors)

  $ /sbin/dump -0 -f hda7-dump-from-ddImage hda7-ddImage 
    DUMP: Date of this level 0 dump: Wed Aug 20 11:58:43 2008
    DUMP: Dumping /dev/mapper/VolGroup00-LogVol00 (/ (dir
pdx-punster1/cricket_backups/hda7-ddImage)) to hda7-dump-from-ddImage
(Continue reading)

Stelian Pop | 20 Aug 23:21 2008
Picon

Re: Can't read next inode ...

Le mercredi 20 août 2008 à 12:12 -0700, Perry Hutchison a écrit :

> I had already made a copy using dd with conv=noerror, and have
> encountered two problems (one definite, the other suspected):
> 
> - 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.

e2fsck works with a block device or a regular file (it just issues a
warning on startup iirc).

[...]

> - the dd manpage does not say what dd does about the unreadable
>   blocks.  Ideally it would have filled the corresponding parts
>   of the image file with zeros, but I suspect it skipped them
>   entirely (so everything beyond the first unreadable block is
>   probably at the wrong offset for either e2fsck or dump).

>From what I read, you should have been using:
	dd conv=noerror,sync

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

--

-- 
Stelian Pop <stelian <at> popies.net>
(Continue reading)

Perry Hutchison | 21 Aug 22:07 2008

Re: Can't read next inode ...

> > 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_.
(Continue reading)

Stelian Pop | 21 Aug 22:42 2008
Picon

Re: Can't read next inode ...

Le jeudi 21 août 2008 à 13:07 -0700, Perry Hutchison a écrit :

> > 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
[...]
>   -i
[...]
>   -X
[...]

I'm confused. To what program do you intend to pass those options ?
(Linux) dump manpage or (my local copy of) losetup manpage do not
mention those.

Stelian.
--

-- 
Stelian Pop <stelian <at> popies.net>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Dump-users mailing list
Dump-users <at> lists.sourceforge.net
(Continue reading)

Perry Hutchison | 21 Aug 22:57 2008

Re: Can't read next inode ...

> > What would you think of adding some options:
> > 
> >   -D filesystem
> [...]
> >   -i
> [...]
> >   -X
> [...]
>
> I'm confused. To what program do you intend to pass those options ?
> (Linux) dump manpage or (my local copy of) losetup manpage do not
> mention those.

I'm suggesting adding those capabilities to dump.

I would expect -D to be fairly easy, and -i also provided it's
not necessary to have read the Nth inode block in order to find
the (N+1)th inode block.  -X might be more troublesome, depending
on how much block accounting dump is already doing.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Stelian Pop | 21 Aug 23:13 2008
Picon

Re: Can't read next inode ...

Le jeudi 21 août 2008 à 13:57 -0700, Perry Hutchison a écrit :
> > > What would you think of adding some options:
> > > 
> > >   -D filesystem
> > [...]
> > >   -i
> > [...]
> > >   -X
> > [...]
> >
> > I'm confused. To what program do you intend to pass those options ?
> > (Linux) dump manpage or (my local copy of) losetup manpage do not
> > mention those.
> 
> I'm suggesting adding those capabilities to dump.

Ok, got it now.

> I would expect -D to be fairly easy,

indeed

>  and -i also provided it's
> not necessary to have read the Nth inode block in order to find
> the (N+1)th inode block.

dump used e2fsprogs' ext2fs_block_iterate2() to iterate over the blocks
of one inode. I'm not sure (at least it is not documented) that
ext2fs_block_iterate2() allows the behaviour you're searching for.

(Continue reading)


Gmane