I ran into I/O error (error 5) when copying files. Tried to copy the file in question to the same filesystem and to the different filesystem using cp, copy and tar - same problem, so looks like system could not read the source file.
The system SCO OSR 5.0.7 runs under VMWare and the storage is IBM SAN. Support already ran fsck from SCO and the IBM utility on SAN (have no details), both came clean.
What would gurus do in this situation?
The guest OS file was moved from the NAS to another storage for now, but I don't have a warm feeling about the situation.
the file you are copying may not be a regular text or binary file ... see if skipping the file lets your copy/tar job complete ...
JustIce reply is not applicable... I know which file I can copy, it is a plain 200+Mb data file.
Any ideas?
what is the output from file data-file as well as strings data-file ? if neither of these commands are able to read the file, there is a very high probability that your file is corrupted since disk and filesystem corruption "has already been" ruled out ...
I said this is a plain file with binary data in it, so the strings command is not meaningful.
$ file FNAME.dat
FNAME.dat: data
What do you mean by
?
The binary content of the file is corrupted? Only application would be able to tell, as it know how to interpret the content, but I was getting I/O error 5 when doing plain old copy.
Anybody ever seen this on RAID SAN?
Sorry for repeating question, I really would love to understand when guest OS decides to throw disk I/O and the h/w manufacturer's tools show disk is good.
since both ibm san utility and sco fsck utility say the drive and the filesystem are both okay, the possibility that your file is corrupted is over 95% imo considering the error you are getting ...
try having the application that generated the file read it ... if the application is having issues reading the file, the file is corrupted ... if the application can read the file normally, have your sys admins check all the system logs for any errors ...
Yes, syslog messages should explain the i/o error.
Can you copy or cat the file to /dev/null ?
Can you copy with dd command? Try different block sizes.