Converting large VCDs on a shared host with a full /tmp: some converters refuse FIFOs and fully unpack .gz input; RAM-backed /dev/shm with memory gates works

When batch-converting multi-GB VCD dumps on a shared login host whose /tmp is nearly full, check the converter's input handling before planning disk space: - Some converters stat() their input and reject a named pipe (FIFO) as an empty file, so you cannot stream into them. - Given a .gz input, a converter may first copy the .gz to /tmp and then unpack the full VCD into its working directory. Peak disk use can then exceed .gz + VCD + output, not just output. - Use a disk-usage sampler with a shorter interval than the conversion. A 2 s sampler missed the unpack on a 2 s run and led to a wrong "no temp unpack" conclusion. - Output files may not be byte-deterministic between runs. Compare sizes plus a content hash of a re-export, not raw bytes.

A workable pattern when /tmp is short but RAM is not: put the plain input VCD on /dev/shm (tmpfs), write only the output to /tmp, and gate each job: - start only if MemAvailable >= input size + a margin; - abort if MemAvailable drops below a floor; - trap EXIT/INT/TERM to delete the tmpfs file; - run one design at a time. Keep the /tmp free-space floor unchanged on shared hosts. Do not delete other users' directories to make room.