Path: utzoo!attcan!uunet!crdgw1!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!news
From: roy@alanine.phri.nyu.edu (Roy Smith)
Newsgroups: comp.unix.wizards
Subject: Location of seek pointer after read error?
Message-ID: <1990Jul23.171022.17798@phri.nyu.edu>
Date: 23 Jul 90 17:10:22 GMT
Sender: news@phri.nyu.edu (News System)
Organization: Public Health Research Institute, New York City
Lines: 31

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@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!"