Build failure: DSK0 device full when copying to backup

[lashtear]

Repeatable build break in build.tcl:193:

*:print backup;..new. (udir)
DSK0: BACKUP; ..NEW. (UDIR) - FILE NOT FOUND
:vk
*:copy .; @ it
s, dsk0: backup;
*:copy .; @ ddt, dsk0: backup;
*:copy .; @ salv, dsk0: backup;
*:copy sys; ts ddt, dsk0: backup;
DSK: BACKUP; _COPY_ OUTPUT - DEVICE FULL

The last command timed out.
make: *** [Makefile:155: out/pdp10-ka/rp03.2] Error 1

real	72m13.600s
user	0m27.729s
sys	0m11.331s

Booting afterward to take a peek afterward, I see:

:listf backup;

KA   BACKUP
FREE BLOCKS #2=0 #3=1000 #0=1311 #1=8380
  2   @      DDT    4 ! 9/13/2021 21:07:28
  2   @      ITS    67 ! -
  2   @      SALV   8 ! -

The m.f.d. (file) shows 223 directories in use.

[larsbrinkhoff]

I have seen this happen occasionally. At this point I have no better solution than "try again until it works".

I think this is due to the initial phase storing many files on DSK0: and apparently ITS distributes files randomly over the packs, or something like that. I have tried to locate and possibly improve the algorithm, but no success so far: #2049

[gwright83]

I've run out of disk space later in the build occasionally, for instance, building Space-War. Don't know if this provides any clue but I thought I'd note it.

jwar$d$$
$y dsk0:.;@ war
*:kill
*:midas;324 dsk0:.;@ spcwar_spcwar; spcwar
MIT-AI PDP-6/10 Space-War
Reply with <RETURN> to use default value.
ITS version (NO):
NO
Inter-processor interrupt (YES): NO
Maximun number of ships (1-4) (4):
Number of ship designs (4):
Maximum number of suns (0-3) (3):
Game recording (NO):

MIT-AI PDP-6/10 Space-War
This is version 166
IOCERROR: DSK: .; _MIDAS OUTPUT - DEVICE FULL
320233>>XCT 3
The last command timed out.
make: *** [out/pdp10-ka/rp03.2] Error 1

disk0 was being written to again.

[lashtear]

We really should refer to dsk0: there. It could go to any of them in the set of loaded packs if given an appropriate prefix, dsk1 etc. That may mitigate a build step manually in the short term, but the more general solution of how/when we decide where each file will go manually or use :dump's GFR... I'm not sure.

[larsbrinkhoff]

I think the problem got worse when I rearranged the build to use a bootstrap ITS possibly incompatible with the target ITS: #2048, #2052. The bootstrap ITS builds the target ITS plus DDT, MIDAS, SALV, etc. This is written to a tape and restored onto the target disk with SALV which only knows how to write to DSK0.

Possible fixes:

• Update the ITS file placement algorithm to avoid near-full packs.
• Update the SALV file placement algorithm.
• Add another step which makes it possible to restore with DUMP.
• Have the build script move files from DSK0 to other packs.

[larsbrinkhoff]

There seems to be code around QWRO2E in SYSTEM; DISK to detect when a disk unit is low on space and select another pack.

[larsbrinkhoff]

With more files being added to the system, this problem is slowly growing. It would be good to have this fixed soon. I tried to add one more pack, but it didn't help much. Supposedly ITS still keeps putting files on the overcrowded DSK0:.

There is another issue for this: #2049.

[larsbrinkhoff]

I'm closing this in favor of #2049, which has more information and seems to make progress towards a solution.