Hi,
I have a ext3 filesystem created inside a problematic seagate ST3500320AS
drive. The drive will just shut itself down automatically whenever it hits
any read error. Only way to wake it up it to cold power off / on the
computer.
Now, my ext3 fs is /dev/sde2
I can mount it without any error:
mount /dev/sde2 /tmp
then, I can 'cd' into /tmp to get a sub directory listing.
let's says there's
Hello
World
users
public
now when I do 'ls public', I get:
EXT3-fs error (device sde2): ext3_get_inode_loc: unable to read inode
block - inode: 26181633, block=26181634
ls: cannot access /tmp/public: Input/output error
'sde' will disappeared from the system, need power off / on can get it back.
After cold boot, I know there's a subdirectory called "EL" inside "public",
if I do a 'ls public/EL',
I get:
EXT3-fs error (device sde2): ext3_get_inode_loc: unable to read inode
block - inode: 26181633, block=26181634
ls: cannot access /tmp/public/EL: Input/output error
Is there any way I can get into subdirectory of "public" without the need of
read inode block 26181633/26181634 ?
Is it still possible to get a full subdirectory listing of "public" ?
Thanks a lot,
kyle
On 2010-01-29, at 23:07, kyle wrote:
> I have a ext3 filesystem created inside a problematic seagate
> ST3500320AS
> drive. The drive will just shut itself down automatically whenever
> it hits
> any read error. Only way to wake it up it to cold power off / on the
> computer.
Strange, I had to do the same for a friend, and I think it was the
same drive.
You should put it into a USB enclosure - it speeds things up a lot.
> 'sde' will disappeared from the system, need power off / on can get
> it back.
To get most of the data off the dying drive, use rsync -v, and create
a list
of files to exclude, when you detect they cause the drive to die.
> After cold boot, I know there's a subdirectory called "EL" inside
> "public",
> if I do a 'ls public/EL',
> I get:
> EXT3-fs error (device sde2): ext3_get_inode_loc: unable to read inode
> block - inode: 26181633, block=26181634
> ls: cannot access /tmp/public/EL: Input/output error
>
> Is there any way I can get into subdirectory of "public" without the
> need of
> read inode block 26181633/26181634 ?
> Is it still possible to get a full subdirectory listing of "public" ?
debugfs is your friend. It can open and list a directory by inode
number, and dump the files to another filesystem.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
On Sat, Jan 30, 2010 at 12:24:09AM -0700, Andreas Dilger wrote:
> On 2010-01-29, at 23:07, kyle wrote:
> >I have a ext3 filesystem created inside a problematic seagate
> >ST3500320AS
> >drive. The drive will just shut itself down automatically whenever
> >it hits
> >any read error. Only way to wake it up it to cold power off / on the
> >computer.
>
> Strange, I had to do the same for a friend, and I think it was the
> same drive.
> You should put it into a USB enclosure - it speeds things up a lot.
>
> >'sde' will disappeared from the system, need power off / on can
> >get it back.
>
> To get most of the data off the dying drive, use rsync -v, and
> create a list
> of files to exclude, when you detect they cause the drive to die.
An image copy of the disk will tend to recover more than accessing the
disk via the file system. I haven't run across the failure mode where
accessing a certain magic block causes the disk to die and require a
power cycle, but in that case what I'd probably do is enhance the
dd_rescue program to take a list of block numbers which it should skip
over....
This will require some programming, but it's probably the best way to
recover the most amount of data. (Oh, and afterwards someone should
send the changes back to Kurt Garloff, since it would be a very useful
enhancement to dd_rescue.)
- Ted
On 2010-01-30, at 10:44, [email protected] wrote:
> On Sat, Jan 30, 2010 at 12:24:09AM -0700, Andreas Dilger wrote:
>> On 2010-01-29, at 23:07, kyle wrote:
>>> I have a ext3 filesystem created inside a problematic seagate
>>> ST3500320AS drive. The drive will just shut itself down
>>> automatically
>>> whenever it hits any read error.
>>
>> Strange, I had to do the same for a friend, and I think it was the
>> same drive.
>> You should put it into a USB enclosure - it speeds things up a lot.
I just checked the drive type that I had this problem on, it is
ST3320620AS, as I kept it in case there needed to be more rescue work
done. Not exactly the same, but I don't know enough about Seagate
model numbers to determine how related they are.
> An image copy of the disk will tend to recover more than accessing the
> disk via the file system. I haven't run across the failure mode where
> accessing a certain magic block causes the disk to die and require a
> power cycle, but in that case what I'd probably do is enhance the
> dd_rescue program to take a list of block numbers which it should skip
> over....
Well, I thought the same thing initially, but like the poster I have a
drive which dies (locks up internally? I don't know) as soon as
certain files are accessed. Since I could get 95%+ of the files
using the "rsync -av --exclude-from {bad_file_list}" method, and the
files I couldn't recover were of marginal value, I did that, as it was
expedient.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
>
> To get most of the data off the dying drive, use rsync -v, and create
> a list
> of files to exclude, when you detect they cause the drive to die.
I need to get files from 'public/EL/', however, 'public' cause the drive die
........
>
>
> debugfs is your friend. It can open and list a directory by inode
> number, and dump the files to another filesystem.
Is it possible to get the inode number of 'public/EL' without hitting the
'public' which cause the drive die?
Kyle
>
> Well, I thought the same thing initially, but like the poster I have a
> drive which dies (locks up internally? I don't know) as soon as
> certain files are accessed. Since I could get 95%+ of the files
> using the "rsync -av --exclude-from {bad_file_list}" method, and the
> files I couldn't recover were of marginal value, I did that, as it was
> expedient.
>
90% of files I need is inside a subdirectly 'public' which cannot be read
........ :(
Kyle
> >
> > To get most of the data off the dying drive, use rsync -v, and create
> > a list
> > of files to exclude, when you detect they cause the drive to die.
>
> I need to get files from 'public/EL/', however, 'public' cause the drive die
> ........
>
> >
> >
> > debugfs is your friend. It can open and list a directory by inode
> > number, and dump the files to another filesystem.
>
> Is it possible to get the inode number of 'public/EL' without hitting the
> 'public' which cause the drive die?
Not easily. But as Ted pointed out, you might try to dd blocks from /dev/sde
upto the problematic block and then next time starting after the problematic block.
If this works out, you can then just run fsck at the resulting image and it should
recover the filesystem reasonably...
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs