Description of problem: md5sum sporadically returns "Input/output error", and syslog contains: Jun 13 21:29:27 hummer kernel: attempt to access beyond end of device Jun 13 21:29:27 hummer kernel: hde1: rw=0, want=13380703400, limit=240121665 Jun 13 21:29:27 hummer kernel: attempt to access beyond end of device Jun 13 21:29:27 hummer kernel: hde1: rw=0, want=29353197728, limit=240121665 Jun 13 21:29:27 hummer kernel: attempt to access beyond end of device Jun 13 21:29:27 hummer kernel: hde1: rw=0, want=13499710168, limit=240121665 Jun 13 21:29:27 hummer kernel: attempt to access beyond end of device Jun 13 21:29:27 hummer kernel: hde1: rw=0, want=23159240096, limit=240121665 Jun 13 21:29:27 hummer kernel: attempt to access beyond end of device Jun 13 21:29:27 hummer kernel: hde1: rw=0, want=25480704808, limit=240121665 Jun 13 21:29:27 hummer kernel: attempt to access beyond end of device Jun 13 21:29:27 hummer kernel: hde1: rw=0, want=13380703400, limit=240121665 Version-Release number of selected component (if applicable): latest as updated with yum How reproducible: I have 200+ GB of music FLaC files (on a separate automounted hard-drive), and checksumming always fails on random files, with the "Input/output error". Steps to Reproduce: 1. Fill a hard-drive with lots of files 2. Run find <path> -type f -exec md5sum '{}' ';' > /dev/null Actual results: md5sum: <file-name>: Input/output error Expected results: <none> Additional info:
I'd suggest running fsck over that drive as a first course of action.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
Thanks, Dave. I will follow your advice. Give me a couple weeks though, because I'm in a middle of a cross-country move :)
What architecture is this?
And is the filesystem directly on /dev/hde1, or is there a software raid or lvm layer?
> What architecture is this? Dell PowerEdge SC 420 (Hyper-Threaded P4 2.8) > And is the filesystem directly on /dev/hde1, or is there a software raid or lvm layer? /dev/hde1 is a 120GB drive with a single ext2 partition. A few days ago I fsck'd the drive. Then, I ran "yum update", rebooted, and I still got same errors. So, apparently, the problem hasn't been fixed yet.
So nothing obvious in common with the new bug 165717 except for the error message.
Another hint: This md5 calculation used to run for months without problem on my older Athlon 700 server. Then I did a fresh FC3 install on Dell SC420, and the problem started occuring. So it's either a software bug that was introduced in the past 6 months, or it may be an older hardware-specific bug. Please let me know what else I can try..
In your tests which demonstrate the problem, how is the directory tree laid out - how many levels, how many files per directory (any symlinks or hard links?) and roughly how big are files? If it's not too big, perhaps provide a listing of part of the directory tree to show us.
The structure under /dev/hde1/ is like this: lost+found/ storage/ ArtistName/ AlbumTitle/ Track.flac There are ~100 artists, ~4 albums per artist, and ~10 tracks per album. Each track is about 20MB. There are no symlinks/hardlinks.
After some poking around, I narrowed down the problem to the Promise Ultra 66 IDE controller. I have two of them, and both result in I/O errors. Built-in controller works ok. So it's some kind of strange problem specific to hardware. Thanks everyone.