[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ext4
Subject:    Re: need help with getting into a corrupted sub directory
From:       Andreas Dilger <adilger () sun ! com>
Date:       2010-01-31 18:11:25
Message-ID: 573A48EF-7CE3-481D-935E-364506424D1F () sun ! com
[Download RAW message or body]

On 2010-01-30, at 10:44, tytso@mit.edu 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 unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]