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

[Johnny Billquist <bqt%softjar.se@localhost>]

On 5/27/26 14:00, Jason Thorpe wrote:
> I am on a quest to properly unify the m68k user-land, which means addressing some long-standing ABI differences in some of the darker corners ofthe system.  One particularly dark corner is BSD disklabel handling, which, from where I sit, is a giant toxic dumpster fire raging in the middleof the Bog of Eternal Stench.  But I don’t have time for that rant this morning.

Hehe. This will be fun...

> So, let’s focus on DEC STD 144, a.k.a. bad144, a.k.a. dkbad.  It’s a 1970s-era bad sector remapping scheme that was already mostly obsolete by the mid-80s (ever since SCSI drives were able to maintain their own bad sector remapping information).  It is totally and completely useless on any drive made since the 1990s.  And yet, its tendrils infest many a NetBSD port’s BSD disklabel handling because, as far as I can tell, cargo-cultism.

I was always both surprised and annoyed by bad144 in NetBSD.
More on that below...

> I figure there are a handful of legit use cases for bad144 in NetBSD still:
>
> - The vax port, obviously, but only with the really old drives.  (VAX peeps please help me out here - is bad144 useful drives behind an MSCP-compliant controller?)

No. Any drive using MSCP do not use bad144. MSCP, just like SCSI, 
guarantees an error free disk. Any bad block mapping happens in the 
controller.

*However*, other drives do use DEC STD 144. So that means RL, RM and RP 
drives (which are still supported on the VAX side). But with that said, 
bad144 have never (as far as I know) been supported/allowed on VAXen. 
Which annoys/perplex me to no end. The only platform that actually have 
disks using DEC STD 144 is one where bad144 is not built. How did that 
come about???

From the Makefile in /usr/src/usr.sbin/bad144:

.if ${MACHINE_ARCH} == "alpha" || ${MACHINE_ARCH} == "i386"
PROG=   bad144
.endif


So, only built for i386 and Alpha. :-(


I guess technically some DEC Mips based machines could have RL drives, 
so apart from VAX, possibly Mips would be the only really valid user.

> - hp300 port maybe (for HP-IB drives).

Do those really have a bad block list on the last track done the same 
way as DEC STD 144 specifies?

> - sun3 / sun4 (Xylogics controllers and SMD drives)

Same question.

> - i386 (ESDI, ST506, other ancient drive technologies that can plug into ISA or MCA)

Same question.

> What I would like to propose is that bad144 be completely decoupled from “disklabel” and refactored out as set of library routines (slash module) that drivers can use.  But, most importantly, get it out of the main “BSD disklabel” code path.
>
> And so, let’s discuss.

bad144 should be reading the bad block list from the last track of a 
media, and I guess it then populates a list of bad blocks in the disk 
label, right?
So is there really a couplinng in here? Or isn't just bad144 one way of 
populating that bad block list in the disklabel. But the list as such 
needs to be somewhere where the disk driver can access it and handle it 
accordingly, no?
And that is independent of bad144 as such.

But I might have missed something.

  Johnny