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

[Adrian Chadd <adrian%freebsd.org@localhost>]

On Wed, 27 May 2026 at 15:48, Thor Lancelot Simon <tls%panix.com@localhost> wrote:
>
> On Wed, May 27, 2026 at 10:56:46PM +0100, David Brownlee wrote:
> >
> > Presumably the "modern" approach would be to implement it as a layered
> > filesystem? (I'm not sure how much of a :) to add here...
>
> Actually, a pseudodevice could implement STD 144 pretty easily, and
> thereby free actual disk drivers *and* the disklabel code from any need
> to do so.  The only problem is that you couldn't reliably use such a
> disk as the root device.
>
> In my experience, DEC removable disk packs actually need this functionality,
> and the only ones of those that were common enough that anyone is likely to
> want to read them these days were the RL02 drives and packs and maybe
> the RK07.
>
> It looks like we have our own RL driver that didn't come from historical
> BSD, and unless I'm misreading, it doesn't handle remapped sectors on read.
> The other removable pack drives BSD traditionally supported on the VAX were
> the RK07 (we have no 'hk' driver), and various RM and RP series drives,
> as well as the CDC 97xx drives, all of which used the 'hp' massbus disk
> driver with various controllers.  We also seem to presently have no 'hp'
> drivfer.
>
> I would say this agitates for simple removal of the STD 144 code, in
> kernel (what drivers actually use it?) and userspace.

On x86, IIRC only the earliest IDE drives didn't do bad block remapping?
I'm pretty sure I needed it on FreeBSD and NetBSD way back when for MFM/RLL
drives were still cheap and plentiful and being thrown out for IDE drives.

I guess these days in FreeBSD you'd implement it as a geom provider and
you'd have to teach the bootloader where the badblocks were to solve
the bootstrap problem..



-adrian