Le mercredi 10 janvier 2007 =E0 12:23 -0500, Dragan Krnic a =E9crit :
> I am trying to salvage data from an unlucky volume.=20
> The dump utility starts with following messages:=20
>=20
> DUMP: Date of this level 0 dump: Wed Jan 10 18:07:37 2007=20
> DUMP: Dumping /dev/sdl (/disc) to standard output=20
> DUMP: Excluding inode 7 (resize inode) from dump=20
> DUMP: Label: none=20
> DUMP: Writing 64 Kilobyte records=20
> DUMP: mapping (Pass I) [regular files]=20
>=20
> and then after about two and a half minutes it says=20
>=20
> /dev/sdl: Can't read next inode while scanning inode #2342912=20
>=20
> The volume was quite big, 3.5 TB, but it was only about 1.2 TB=20
> full. The dump utility apparently finds more than 2 million=20
> inodes but unfortunately it breaks with the above message=20
> before actually dumping any data.=20
>=20
> Is there some version of dump which would ignore such errors=20
> and just try to make sense out of the remaining sound data,=20
> even if there are corrupted chunks in between?=20
The problem here is that the filesystem structure itself is corrupted.=20
You can modify dump to make it stop iterating the inodes just before the
corrupted one, but there is a good chance that you'll encounter even
more data corruption when trying to find the data blocks associated to
the inodes.
> Do you have some other suggestion, how to salvage as much=20
> data as possible (e2fsck has even less patience with it)?=20
e2fsck is based on the same ext2 low-level libraries as dump, but it has
much more intelligence to deal with errors. If e2fsck is not able to
salvage at least a part of the data, I don't think dump will.
--=20
Stelian Pop <st...@po...>
|
