Re: bad144 - how useful still? Because it's annoyingly ubiquitous.

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]