Buffer I/O error when booting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Depending on the disk, you can possibly get a vendor tool to disable bad 
block relocation.  This way, if a block can't be read the disk will not 
do it's internal magic to remap the block to another part of the disk. 
Some vendors also offer a disk copy tool which can skip the unreadable 
parts, similar to what ddrescue ends up doing but can be significantly 
faster.

John.

Dag Wieers wrote:

> On Wed, 22 Jun 2005, Nikos Zaharioudakis wrote:
> 
> 
>>try something like this.
>>fdisk -l /dev/hda    (no 1,2 etc just the drive)
>>if it gives you back some partition table then you have hope.
> 
> 
> Even when it fails to return a partition table there is still hope.
> 
> I actually had problems, fdisk -l didn't work, partitions couldn't be 
> mounted read-only. But after ddrescueing the complete disk I still had 
> 99.983% of my disk (about 30MB of the 160GB was lost, most of it on the 
> recently formatted and therefor empty partition, only 2.2MB of real data 
> was impacted)
> 
> Strangely, fdisk -l on the copied disk worked without a problem. According 
> to ddrescues output:
> 
> 	Bad region size 32768 at position 4096
> 	Bad region size 4096 at position 49152
> 	...
> 
> I verified fdisk's behaviour with strace and apparently it first reads the 
> first 512 bytes, but then strangely reads the first 8k. Since that fails, 
> I was out of luck.
> 
> 
> 
>>try to mount the drive with ro (read only option we do not need to
>>change anything on it, we just want the data)
> 
> 
> Don't do this after a reboot, chances are the disk is dying, might go bad 
> while using it and the filesystem might not recover from the problems 
> anyway. If the system was still running, you might want to copy files off 
> the filesystem (since the disk might not come back after a reboot). If you 
> rebooted the system, use a rescue CD (knoppix) that has dd_rescue on it 
> and use that to copy the complete block-device.
> 
> You can also download gnu ddrescue to your knoppix ramdisk, compile it and 
> use that. It is more sophisticated and you can first recover the major 
> working areas with a big blocksize and later refine the bad areas (when 
> the disk might be even less reliable).
> 
> 
> 
>>If this fails for any reason, try to dd the whole disk to another
>>(good one) and then mounting and perhaps fsck might give you your data
>>back.
> 
> 
> dd will not work if you have bad blocks, it fails on the first bad block.
> 
> Also, before running fsck you might want to make a second copy, in case 
> the fsck fails. You don't need to copy everything back from the broken 
> disk, but instead try to refine copying the bad areas (some reports say 
> freezing the disk in the freezer helps ?).
> 
> In my case it took 18h to copy the good parts, but refining the bad areas 
> takes 4 secs for 1 bad block (512 bytes). So you might not want to do that 
> at first or it could take a week (in my case 3 days for 30MB) refining 
> every bad area.
> 
> --   dag wieers,  dag@xxxxxxxxxx,  http://dag.wieers.com/   --
> [all I want is a warm bed and a kind word and unlimited power]
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
> 
> 
> 


-- 
John Newbigin
Computer Systems Officer
Faculty of Information and Communication Technologies
Swinburne University of Technology
Melbourne, Australia
http://www.ict.swin.edu.au/staff/jnewbigin


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux