Burning

Burning

burn writes the prepared folders or ISO files from a successful create run and verifies each finished disc. It works for both raw and DAR archives.

bd-archive burn -i /data/photos-gen1 -D /dev/sr0 -S 4

-i is the create output directory: a raw disc's disc/ folder with manifest.json beside it, a DAR set's discs/, or images/. Do not pass an individual folder/ISO or the container directory itself. Keep the names disc, or disc_0001, disc_0002, etc. (or .iso), unchanged. Folder output requires its manifest.json; incomplete sets and output with both folders and ISOs are refused. Existing ISO sets need no manifest. burn treats a raw disc/ folder like disc_0001.

-D is optional with drive auto-detection. -S 4 requests a 4× speed; omitting it leaves speed selection to the drive/tool. Actual speed depends on hardware and media.

Single-session burning only

Multisession is not supported and is not planned for the foreseeable future. Neither raw nor DAR mode can append files to an already burned disc, regardless of free space or folder/ISO output. Collect files on disk and burn the complete batch together, or use a new disc for later additions. --skip-fit-check does not enable appending, and --start resumes a disc set, not a session on a burned disc.

DAR --pack-with combines unburned contents before a new single-session burn. See Multisession support and research for the reasons, filesystem findings and alternatives considered.

What happens for each disc

1. Insert the requested blank disc and confirm the prompt.
2. For folders, mkisofs -print-size recomputes the exact filesystem size and file metadata is checked against the creation manifest. The detected media capacity is compared with the required write size: the measured filesystem size or existing ISO file size rounded up to a multiple of 32,768 bytes.
3. For folders, growisofs runs mkisofs with the same filesystem options and writes the stream directly to the disc. For ISOs it copies existing bytes. No intermediate ISO is written when burning folders.
4. The tray ejects; the tool attempts to close it (unless --no-close-tray) and waits for the burned disc in any drive.
5. The disc is mounted and verified in the drive where it was found. Only an OK result completes this step.
6. The verified disc is ejected and the next one is requested.

Slim drives may require you to push the tray in. Waiting for the disc to return has no hard timeout. Once the disc is ready, mounting is retried for up to 60 seconds; persistent failures offer an interactive retry.

Verify in another drive

The burned disc is recognized by its volume label in whichever drive it is loaded, regardless of how many drives are connected. You can therefore move it to another drive for verification and insert the next blank disc into the burner meanwhile. The next insert-disc prompt is still for the burner; if the blank disc is already inserted, confirm the prompt.

• Burner: whenever it reports a newly loaded disc, its volume label is read once. A blank disc has no label and is not mistaken for the burned one.
• Other drives: they are watched only through the udev database (/run/udev/data), where udev records the filesystem label of every medium it detects. Reading these records sends no command to any drive, so a drive that is burning in another process is not disturbed. Only the drive that reports the burned label receives readiness checks before mounting. A drive that already held a disc with the same label before the burn started is ignored until a different disc (or none) is detected in it. Without the udev database (for example in some containers), only the burner is watched; the tool says so at the start.

A tray-load burner closes its tray after burning, which would pull the disc back in. To move discs from such a burner, add --no-close-tray:

bd-archive burn -i /data/photos-gen1 -D /dev/sr0 --no-close-tray

Slim drives cannot close their tray, so the option makes no difference there.

Burn progress

Folder and ISO burns use growisofs's native status output: bytes written and total bytes, percentage, current speed (@...x), estimated remaining time, and buffer utilization as reported by growisofs:

• RBU: the software ring buffer feeding the writer.
• UBU: the drive's internal buffer.

For folder burns, -use-the-force-luke=moi selects this output and suppresses mkisofs's filesystem-generation progress. The displayed progress therefore follows the writer rather than the producer of the ISO stream. It is not a verification result; successful completion and post-burn verification still matter. Initial drive preparation can delay the first status update, and time estimates may fluctuate during startup and speed changes.

Ring buffer

growisofs keeps a ring buffer in RAM between the source and the drive. Its own default is 32 MiB, which covers about two seconds at 4× BD speed. bd-archive deliberately requests 512 MiB by default: a successfully burned disc matters more than anything else, every failed burn costs a disc, and 1 GB of RAM costs next to nothing today.

The buffer bridges pauses in reading the source. When the source stops delivering for longer than the buffer lasts, the drive's own buffer runs empty as well (RBU and UBU at 0%, speed at 0.0x). Drives bridge short pauses, but after a longer stall the drive can refuse the next write with INVALID ADDRESS FOR WRITE, which ends the burn and wastes the disc. See Troubleshooting.

Raise the buffer the slower or less reliable the source storage is, for example a NAS with hard disks, or a disk that is busy with other work during the burn:

bd-archive burn -i /data/photos-gen1 --buffer 1G

SIZE is a whole number of MiB, or a size with an M or G suffix (MiB or GiB), from 1M to 64G. growisofs allocates ring buffers in powers of two, so the value is rounded up accordingly; the effective size is logged before the burn (Ring buffer: 512 MiB). growisofs itself halves a buffer that does not fit into a fraction of the physical memory. Approximate pause coverage:

Buffer	2× (9 MB/s)	4× (18 MB/s)	6× (27 MB/s)
32 MiB (growisofs default)	4 s	2 s	1 s
512 MiB (bd-archive default)	60 s	30 s	20 s
1 GiB	120 s	60 s	40 s

growisofs fills the whole buffer before the first write, so the burn starts once the source has delivered that much data. A larger buffer evens out pauses; it does not help when the source stays slower than the drive for longer than the buffer lasts. Repeat a custom size when resuming a set.

Memory locking

growisofs locks its memory against swapping when it can raise its locked-memory limit (RLIMIT_MEMLOCK) to 48 MiB. A hard limit between 48 MiB and the buffer size would then make the buffer allocation fail before any write. bd-archive therefore sets the limit in the growisofs process only: where the hard limit covers the buffer plus 64 MiB, or is unlimited, the soft limit is raised to it and the whole buffer is locked; otherwise the hard limit is lowered so growisofs skips locking and the buffer stays pageable. No system setting is changed. Running as root locks the buffer regardless of limits.

Write command timeout

Every burn uses a bundled native helper to give drive write commands a minimum of 180 seconds. This applies to both folder streams and existing ISOs. To request a different minimum:

bd-archive burn -i /data/photos-gen1 --write-timeout 900

The range is 1–86400 seconds. Longer timeouts already requested by growisofs are preserved; a small value does not shorten growisofs's own timeout. This is per write command, not a limit on the whole burn. It gives slow drive startup more time, but does not guarantee success for a faulty medium or drive. Read, calibration, flush and session-closing command timeouts are unchanged. A truly stuck write can take longer to fail, and cancellation may have to wait for the kernel command to return. Repeat a custom timeout when resuming a set.

The installed growisofs binary is unchanged. Before starting it for burning, bd-archive probes the helper in that executable without accessing the drive. A missing, incompatible or ignored helper stops the operation; there is no silent fallback to the old timeout. The helper is process-local and is not loaded into mkisofs or other executed child programs. No kernel, udev or global loader configuration is changed. See Installation for build requirements and Troubleshooting for activation failures.

Capacity checks

growisofs fills the last write block with zero bytes, for both folders and ISOs. The capacity gate includes this padding: required bytes are ((image_bytes + 32767) // 32768) * 32768. An image already aligned to 32 KiB needs no extra block. For example, 34,816 image bytes require 65,536 writable bytes; 65,535 available bytes are refused before burning.

For sets with more than one image, a medium more than 5% larger than the set's largest padded write size is also rejected to avoid wasting a larger media class. A partly filled last image still uses the largest image as its comparison point.

Single-image sets allow unused capacity. --skip-fit-check disables both checks. If capacity cannot be detected, folder burning stops unless you explicitly use --skip-fit-check. The legacy ISO path still warns and proceeds without a fit check in that case.

Keep folders unchanged until burning finishes. The manifest guards file paths, sizes, permissions and mtimes; it is not a content hash and cannot detect every form of corruption or prevent concurrent writes. verify checks integrity. Size is recalculated with the currently installed mkisofs, so its current overhead is checked even if the tool changed since creation.

Use blank, unformatted BD-R media for the intended capacity model. The burner passes -use-the-force-luke=spare=none; sizing assumes it will not reserve a new Outer Spare Area. Previously formatted BD-R media may not match that assumption. See Storage and layout.

Resume a set

After three discs have finished successfully, continue with disc 4:

bd-archive burn -i /data/photos-gen1 --start 4

--start counts prepared discs starting at 1. It is not an automatic burn-history lookup. Keep the complete folder/image set in place so numbering and capacity-class detection remain consistent. The tool prints resume hints when interrupted.

For a planned break, let the current disc finish burning and verifying, then cancel at the next insert-disc prompt. During the actual burn, the first Ctrl+C only warns; a second within five seconds aborts growisofs and can leave an unusable disc. Outside the burn, Ctrl+C cancels normally.

Verification failures

A freshly burned disc must verify as OK. Repairable damage is still a failed post-burn check: cancel the retry loop with q and burn that image on fresh media using --start N. Reinsert and retry first if mounting or loading was the problem.

--no-verify skips the check entirely; it is not an option to accept a known repairable disc as verified. Verification needs par2 when recovery indices are present, or uses Python SHA-512 when they are absent.

After burning

Keep prepared folders/images until burning and verification are complete and you have checked your restore workflow. Keep DAR catalogs and checksum sidecars in your regular backup for future incrementals.

The final message states that the burned files remain in the input directory. Burning never deletes disc folders, images or catalogs. Review the output's contents before removing anything yourself; it can also hold local DAR catalogs.

See also: Verification · Troubleshooting