How to diagnose cause of grep returning "sense key Medium Error" on a particular file
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
How to diagnose cause of grep returning "sense key Medium Error" on a particular file
Running Monta Vista Linux, I want to learn how to determine what might have caused a particular (log) file to get into a state such that grep returns "sense key Medium Error" and "input/output" error, but cat works fine. Note - the file is located on a local hard disk, and all the other files in the same directory are OK. There is no removable media involved.
# grep -Ri extno *
SCSI error : <4 0 1 0> return code = 0x8000002
Info fld=0x2504ed6, Current sda: sense key Medium Error
Additional sense: Read retries exhausted
end_request: I/O error, dev sda, sector 38817488
grep: ex289224.log: Input/output error
But,
# cat ex289224.log
works fine.
Both grep and cat presumably open and read the whole file, so I don't understand what could be wrong with a file where grep would consistently fail but cat would work. Root has write read & write permissions:
ls -latr ex289224.log
-rw-r--r-- 1 root root 7968450 Oct 7 19:46 ex289224.log
I know that e2fsck might fix the problem, but I'm trying first to determine exactly what the problem was and how it might have occurred.
Could be something to do with the difference being grep is trawling through whatever file/directories you have there, while cat is just looking at one file.
Do you get any error if you cat the log into grep via a pipe? (You shouldn't, but it's a quick check.)
The error is, quite explicitly, telling you that the system was unable to read sector 38817488 of /dev/sda, and that that sector contains data from ex289224.log. So the cause of the error is that the sector could not be read.
All that's fairly clear. If you're asking why the sector was unreadable, consider consulting any omnipotent god to which you have access.
Any way to determine what is stored at a given sector ?
Thank you for the information.
The problem is repeatable, and although that particular file is listed in the error message, it is apparently not the source of the problem - because running grep on the cat'd file is ok.
Is there any simple way to determine what is stored at the problem sector ?
In other words, knowing that sector 38817488 has a problem, and that grep -R * has problems trying to access that sector as it progresses - I would like to be able to find out what file or directory structure actually contains that sector. Is that doable ?
If you've got the resources, you could image the drive (using dd) to preserve it in case it's ailing, and see if the image has the same problem. Since the message does seem to relate to a hardware issue, you should - of course - keep your backup current.
That being said, there are several tools you could use to look at what's readable on a specific drive. (I've only used a few of them, mostly for recovery of inadvertently erased files when the backups were not current, so I can't offer specific advice.) Try "Google" for suggestions.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.