ebersman@sysu-0 (mt700) (10/14/87)
I had always been told that UNIX had no means of flagging bad blocks on a disk so that they would not be allocated. However, I was reading the V.2 man pages on our system, and bumped into addbad(1LM) and bdblk(1M). We are running on PDP 11/74's with RP05 disk drives. Has anyone out there used these functions? Will they work on our hardware, and if so, what changes would we need to make to the software to implement it? Thanks for the help.
steve@nuchat.UUCP (Steve Nuchia) (10/17/87)
In article <9762@brl-adm.ARPA>, ebersman@sysu-0 (mt700) writes: > I had always been told that UNIX had no means of flagging > bad blocks on a disk so that they would not be allocated. This is true - there is no unix-wide method for doing this. Obviously, however, any given unix is going to have _some_ way to deal with the problem. Early systems allocated bad blocks to a "bad blocks" file, which is similar to what many mainframe systems do. A few systems may have been taught to leave bad blocks out of the free list, but I haven't heard of them. The remaining schemes involve sparing - mapping bad {cylinders,tracks,sectors} to a reserved area at one end of the disk. This is done either in the controller circuitry or in the driver logic. DEC, in their newer drives, has a standard that involves formatting a spare sector onto each track - these are 30+ sector/track drives, so the overhead is not onerous. I don't know how well any particular unix deals with this standard, unless it is implemented in the controllers (likely). > However, I was reading the V.2 man pages on our system, > and bumped into addbad(1LM) and bdblk(1M). > We are running on PDP 11/74's with RP05 disk drives. > Has anyone out there used these functions? Will they My client's 11/73 is running 2.9, and at least in that one case the bad blocks are handled in the (overly) smart controller board, so the driver sees a clean (and distorted) drive. I don't know what sysV does, but at a guess (and that's all most of us can do - anything this vendor-dependant in unix is almost never documented) I'd say it is marking blocks bad in whatever place the controller or driver is looking for that info, and it is a pretty safe bet it will work, modulo the effect that moving the sparing quantum will have on the filesystem. Unless you can confirm that you are working with a _sector_ sparing scheme you should plan on rebuilding the involved filesystems from backup. -- Steve Nuchia | [...] but the machine would probably be allowed no mercy. uunet!nuchat!steve | In other words then, if a machine is expected to be (713) 334 6720 | infallible, it cannot be intelligent. - Alan Turing, 1947