With my last post testing the write-protection with just one cartridge, we didn’t demonstrate any PLIST changes. While I took the GLIST changes as indicating the lists being both “fluid”, more concrete proof was desired in case one of the lists was frozen by the software-enabled write protection feature. Matson’s comment on my last posting pointed out an obvious oversight on my part – namely reusing a cartridge with a known “bouncy” PLIST to see whether it worked.
As a result, I ran downstairs and grabbed Cartridge #1 from two posts ago, the one with a known bouncy PLIST and write protected it without overwriting the cartridge (to avoid damaging the “bouncy” specimen). The disk was immediately ejected and the machine booted into Linux for reading out the PLIST and GLIST. If that stops PLIST changes, then the disk should report the same defect list time and time again.
The initial reported PLIST/GLIST:
Defect Lists ------------ 34 entries (272 bytes) in primary (PLIST) table. Format (5) is: physical blocks [Cyl:Head:Sect] Sector -1 marks whole track as bad. 116: 0: 38| 117: 0: 19| 239: 0: 53| 285: 0: 41| 479: 0: 54 604: 0: 18| 620: 0: 0| 621: 0: 44| 677: 0: 2| 678: 0: 46 703: 0: 58| 793: 0: 55| 908: 0: 14| 1259: 0: 8| 1260: 0: 43 1261: 0: 31| 1265: 0: 9| 1485: 0: 15| 1699: 0: 25| 1700: 0: 15 51: 1: 64| 142: 1: 13| 155: 1: 16| 380: 1: 8| 449: 1: 22 450: 1: 6| 451: 1: 50| 765: 1: 51| 972: 1: 14| 1222: 1: 2 1223: 1: 37| 1253: 1: 44| 1647: 1: 36| 1658: 1: 35| 1 entries (8 bytes) in grown (GLIST) table. Format (5) is: physical blocks [Cyl:Head:Sect] Sector -1 marks whole track as bad. 1: 1: 2|
After one dd-readout, the PLIST has changed, with the loss of 1666/1/26:
Defect Lists ------------ 35 entries (280 bytes) in primary (PLIST) table. Format (5) is: physical blocks [Cyl:Head:Sect] Sector -1 marks whole track as bad. 116: 0: 38| 117: 0: 19| 239: 0: 53| 285: 0: 41| 479: 0: 54 604: 0: 18| 620: 0: 0| 621: 0: 44| 677: 0: 2| 678: 0: 46 703: 0: 58| 793: 0: 55| 908: 0: 14| 1259: 0: 8| 1260: 0: 43 1261: 0: 31| 1265: 0: 9| 1485: 0: 15| 1699: 0: 25| 1700: 0: 15 51: 1: 64| 142: 1: 13| 155: 1: 16| 380: 1: 8| 449: 1: 22 450: 1: 6| 451: 1: 50| 765: 1: 51| 972: 1: 14| 1222: 1: 2 1223: 1: 37| 1253: 1: 44| 1647: 1: 36| 1658: 1: 35| 1666: 1: 26 1 entries (8 bytes) in grown (GLIST) table. Format (5) is: physical blocks [Cyl:Head:Sect] Sector -1 marks whole track as bad. 1: 1: 2|
This sector is different to the changed sector last time, showing that there is more than one PLIST sector which has “bouncy” tendencies on this cartridge.
As a result, we can conclude the software write protection does not freeze either PLIST nor GLIST and background defect management continues to operate. Maybe that now answers the question properly.
I am out of questions. 🙂
Great stuff! Time for me to move onto a few other things while i still have some time off. Glad I could answer them for you, and hopefully someone else might find this behaviour curious and interesting.
– Gough