On Wed, 27 May 2026 at 22:06, Thor Lancelot Simon <[email protected]> wrote: > > On Wed, May 27, 2026 at 09:43:17AM -0400, Jason Thorpe wrote: > > > > > On May 27, 2026, at 8:15???AM, Anders Magnusson <[email protected]> > > > wrote: > > > > > bad144 is not used by NetBSD/vax. > > > > Well, that???s . . . awkward :-) > > The executable may not be built, but don't the drivers (or the disklabel > code -- yow!!) still respect the bad sector lists? The most likely use > I can see for STD 144 handling in the kernel is if one needs to read a > disk, or even a disk image, which has sectors reallocated using this > mechanism. > > For example, trying to recover an RL02 pack that had sectors spared out > before it was last written, or an image of such a pack, is going to return > errors or bogus data by reading the spared sectors instead of what they were > remapped to. From the comments in the first BSD version of bad144.c, it > appears that "standard formatters" (under RSTS or VMS?) would usually have > tested the media and written this information, so the kernel support even in > the very beginning was much more important than the Unix utility. > > A middle ground between effectively putting this back into the individual > drivers whence it came and ripping it out totally might be to add a utility > that reads the remapping data, and then constructs a disk image that doesn't > need it.
Presumably the "modern" approach would be to implement it as a layered filesystem? (I'm not sure how much of a :) to add here... David
