Thor Lancelot Simon <[email protected]> writes: > On Sun, May 31, 2026 at 10:16:39AM -0400, Jason Thorpe wrote: >> >> > On May 31, 2026, at 10:10???AM, Jason Thorpe <[email protected]> wrote: >> > >> > >> >> On May 31, 2026, at 7:07???AM, Thor Lancelot Simon <[email protected]> wrote: >> >> >> >> The underlying hardware's often the same (CDC made the guts of plenty of >> >> DEC drives), SMD drives internally have no facility for sparing out >> >> sectors, >> >> and I wonder whether Sun did in fact do it. However, I just Googled >> >> around >> >> for SunOS 3 source code and I see no evidence of a bad144 utility, though >> >> I did not dig through the kernel looking for driver support. >> > >> > SunOS 3 certainly had a flag for "use DEC std 144" in the dk_info >> > structure (<sun/dkio.h>). >> >> ???and it certainly appears that the SunOS 3 ???xy??? driver uses it, >> including with big-endian fields, heh. > > Huh. I wonder how it got populated. I'm vaguely remembering they might > have had a "format" utility or something. > > Means moving a drive physically from a DEC system to a Sun VME system > would have lost the bad block table, right? I remember seeing exactly > that done a few times with CDC drives that went from VAXen with Emulex > controllers to Sun replacements which I expect had Xylogics controllers. > I guess to do this safely must have required a low-level reformat by > something that wrote the bad144 data in the expected byte order.
SunOS 4 has a 'format' command and, assuming my memory about it has not faulted, it could be used to do a low level format and I have some memories that could populate a bad blocks table. I know I used it that way once (whether it was meant to be used that way is mostly what I don't remember). At least for SCSI disks, if you didn't use a Sun branded disk you could use 'format' to tell the system what sort of drive you had (I think you could specify the geometry). Probably what NetBSD's sunlabel does. -- Brad Spencer - [email protected]
