>I'm surprised bad144 hasn't been killed off yet, but I see it also hasn't
>made much forward progress.

I think it's just been quietly bit-rotting, because no one has wanted to
do anything about it.

>-> Now, if there's a giant outcry, and people think that bad144 should die
>-> a horrible death, then that's fine ... but I'd prefer that in _that_ case,
>-> we should just remove the damn thing so people don't think that it actually
>-> works and waste time with it.
>
>The other thing I found horribly annoying is that bad144 has a pretty tiny
>limit of sectors it allows you to remap... I found on the drives that needed
>it, you almost always overflowed the table 8-<

Yeah, only 126 sectors.  I'm guessing that's some limit left over from
the original DEC format.

Maybe what is needed is something completely new.  I'm wondering if it
still makes sense to stick with the bad144 format, or take the ideas from
it and try to come up with something new.  It looks like the in-kernel
support is mostly the same no matter what you do on-disk.  One thing
right off that would be required is to get rid of the linear search
for remapped blocks; with 126 it's not so bad, but I can see it really
sucking as time goes on.

Does anyone think it still makes sense to stick with bad144?

--Ken