Location of seek pointer after read error?

Roy Smith roy at alanine.phri.nyu.edu
Tue Jul 24 03:10:22 AEST 1990


The SunOS-3.5.2 man page for read(2) says:

	On objects capable of seeking, the read starts at a position
	given by the pointer associated with d (see lseek(2)).  Upon
	return from read, the pointer is incremented by  the  number
	of bytes actually read.

Now, if you are reading from a raw disk partition (say /dev/rxy0a) and get
a read error (because, for example, there is a bad block on the disk),
where should the pointer be after the read(2) call returns?  It turns out
that, at least for SunOS-3.5.2, the pointer is incremented, as if the bytes
in the bad block had actually been read.  I would consider this incorrect
behavior.  Do you agree?

This came up when I was trying to recover a disk that had started to go
sour.  I was getting lots of read errors (turned out to be a controller
problem, not a drive problem) and wanted to recover all the data on the
disk.  I played around and discovered that it looked like the errors were
all soft, and that if I just retried them enough times, I would be able to
read everything on the disk.  Just dd'ing the partition to another disk
didn't work, because dd's idea of "conv=noerror" is to just skip the block
and keep going, not to retry it.  What I put together was something to read
each block in turn, retrying every read that failed as many times as needed
to get an error-free read, and then writing the block to another disk.
After each read that failed, I had to do a seek to back up a block, other
wise I got the next block, not a retry of the one that failed.
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy at alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"



More information about the Comp.unix.wizards mailing list