Chris Cook: Thank you for looking into this. The drive is, as said, currently in perfect working order. After I read that a modern harddrive "will assign backup sectors to replace broken ones" when you try to write data on the damaged sectors, I utilised this fact and filled the partition in question (from /dev/zero, probably), which produced the wanted result. (What originally caused the fault was, I'm quite sure, a swift but naturally inadvertent kick in the computer case at a bad moment. ;-)
As for the logs, I've attached the output of "smartctl -a" for the drive. Theodore Ts'o: Thanks for confirming my suspicion about kernel behaviour in this case. The drive is an IDE/ATAPI drive. I can't confirm the DMA status at the time of the incident, or whether a problem could cause the kernel to drop out of using DMA to a backup "protocol". The current active mode for the drive is udma5. I've attached the output of "hdparm -gCiI". I've also attached the output of "lspci" and "lspci -v" for the controller. I hope the attached data is enough to identify the hardware. Please let me know if I can provide any more information. To sum up, the problem is not (at least not anymore) with faulty hardware, nor with lost data (luckily, the only thing lost in this case was recoverable from original CDs), but with non-responsive behaviour when facing said hardware errors. ** Attachment added: "smarthdb.log" http://launchpadlibrarian.net/15173520/smarthdb.log -- e2fsck / linux kernel chokes on I/O errors https://bugs.launchpad.net/bugs/64914 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
