SADUMP Format

Structure of a Fujitsu SADUMP file.

To my best knowledge, Fujitsu has never published official documentation of their SADUMP (stand-alone dump) format. The following information is based on reading makedumpfile and crash code and observing a sample SADUMP from a PRIMEQUEST 2000 system.

There are three SADUMP formats:

• single partition format
• diskset format
• media backup format

Only the beginning of the file is different:

	single-partition	diskset	media backup
sadump_media_header	—	—	YES
sadump_part_header	set_disk_set = 0	set_disk_set = 1	set_disk_set = x
sadump_disk_set_header	­—	YES	—

The partition header is padded with 32-bit integers, where magic[i+1] == (magic[i] + 7) * 11. The first number appears to be always zero, but any start value is recognized as valid by makedumpfile and crash.

The disk set header contains an array of per-volume information (vol_info). Each element of this array corresponds to one disk in the disk set. The total number of disks seems to be capped to 16 (or even 15, because the array is declared as having a size of DUMP_DEVICE_MAX - 1), although sadump_disk_set_header.disk_num is a 32-bit integer and the total size of the disk set header (in blocks) is stored in the first field (disk_set_header_size), so there is no inherent reason for limiting the number of disks.

The rest of the file contains:

• sadump_header
• Host-dependent header (extra_hdr_size) ?
  • currently unused; not even skipped by available tools if extra_hdr_size is not zero
• Arch-dependent header (sub_hdr_size); for Intel X86-64:
  • uint32_t: Total size of all smram_cpu_state data on all CPUs.
  • apic_state[nr_cpus]: APIC state for each CPU
  • smram_cpu_state[nr_cpus]: CPU state fore each CPU (indexed by APIC ID)
• Memory bitmap (bitmap_blocks)
• Dumped memory bitmap (dumpable_bitmap_blocks)
• Page data

For a diskset, the first partition contains all the headers, subsequent partitions (i.e. those with set_disk_set > 1) contain a sadump_header directly followed by page data.