Can I still extract just one file?

Often yes, but the decoder may have to process additional data in its solid block to reconstruct that file.

Does a solid archive have to use a single block?

No. A partly solid arrangement can use several blocks, limiting the extent of shared dependencies.

Will more similar files always produce a smaller archive?

Similarity creates an opportunity, not a guarantee. Ordering, compression history, overhead and the selected method influence the outcome.

AI Glossary / MLOps and deployment / Intermediate

Solid compression

Definition

Solid compression compresses data from several files together within a shared compression stream or block, allowing information from one file to help encode another. An archive can contain one large solid block or several independently compressed blocks, depending on its format and configuration.

What it means

Files often repeat one another: exported reports share headings, source files share code fragments, and configuration files share settings. Compressing each file independently limits the compressor's ability to exploit repetition across those file boundaries.

Solid compression makes some of that shared context available. The individual files can still retain names and boundaries in the archive's metadata; they have not become one indistinguishable document. The tradeoff is that retrieving one file may require processing other data from its block first. This matters when an AI project stores many small artifacts but regularly opens only a few.

How it works

The archiver groups files into blocks and feeds each block through a compressor. Within the available compression history, repeated material can be represented using information already encountered. The archive separately records what is needed to identify and reconstruct its constituent files.

File order, similarities, dictionary capacity and block boundaries influence the opportunity for reuse. Simply making a block enormous does not guarantee that all distant repetitions remain usable by a particular compressor.

To retrieve a file, a decoder may need to reconstruct the relevant block's earlier context. Smaller independent blocks can limit that work but also restrict cross-file compression opportunities. The 7-Zip decoder documentation describes partly solid archives and caching a decoded block when extracting more than one file. Exact access behavior depends on the format and implementation.

Three practical examples

1. Project snapshot: a team packages many similar text configuration files for transfer. Sharing compression context may reduce the archive size, and recipients expect to extract the whole snapshot together.

2. Experiment records: an AI group archives related metadata files. If reviewers frequently request one late file from a large block, the retrieval cost may matter more than the smallest possible archive.

3. Dataset distribution: a publisher tests grouping related annotation files into separate blocks. The comparison measures both transfer size and the cost of opening the subsets readers actually use.

Think of it this way

Think of several instruction booklets using one shared glossary of repeated phrases. The collection can be shorter because each booklet no longer has to introduce every phrase independently.

The limitation is access: a reader may need earlier shared material to interpret a later booklet. Real compressors operate on byte patterns and coding state, not human definitions, and the amount of reusable context is limited by their design.

Worked example

Suppose 100 text files total 20 MB. In an invented test, compressing them independently produces a 6 MB archive, while grouping them into five solid blocks produces a 4.5 MB archive. The saving relative to independent compression is 1.5 / 6 = 25%. Relative to the original files, the solid archive is 77.5% smaller.

Now assume the blocks each represent 4 MB of original data. If a requested 200 KB file is at the end of one block and decoding must start at that block's beginning, roughly 4 MB of data may need reconstruction to obtain it. That is about 20 times the requested file size, using decimal units.

This is a teaching scenario, not a benchmark or a universal extraction rule. A cached decoded block could make subsequent requests cheaper. The example shows why archive-size savings and per-file retrieval work should be measured separately.

Illustrative case study

Fictional case: BundleLane stores experiment summaries as monthly archives. The team chooses the configuration with the smallest file and later discovers that its review interface repeatedly waits while opening individual summaries.

Engineers measure representative requests, including cold-cache access and several files from the same block. They compare the original layout with smaller blocks organized around the groups reviewers usually request together. They also measure complete-month extraction, because that remains an important recovery operation.

The fictional decision is based on the mix of access patterns rather than a single compression percentage. A layout suitable for one bulk download need not suit an interactive browsing tool.

Common misconceptions and mistakes

“Solid” does not mean a physically solid storage device, stronger encryption or protection from corruption. It describes how file data participates in compression.

Do not confuse an archive's file list with independent compressed streams. Being able to list every filename does not guarantee immediate independent decoding of every file.

Nor is one archive necessarily one solid block. Multiple blocks allow different dependency boundaries. Finally, solid mode does not ensure substantial savings for every collection; unrelated or already compressed content may offer little useful repetition.

Business use

Businesses can evaluate solid compression when packaging related files for storage or transfer. Define whether users usually restore everything, retrieve individual items or request predictable groups. Those behaviors determine the cost of shared decoding work.

Compare actual archive bytes, creation time, memory needs, selective extraction and full restoration. Include an integrity check and verify that filenames and contents reconstruct correctly. Record block and ordering settings with the results so that another team can reproduce the comparison. Treat the chosen configuration as part of the archive design, not an incidental compression checkbox.

Check your understanding

two archives hold the same files. One is smaller but takes longer to retrieve a single report. Is that contradictory?

Answer: no. Sharing compression context can reduce stored bytes while requiring more decoding work for selective access. Which archive is preferable depends on the workload and measured tradeoffs.

Related terms

Lossless compression
LZMA
archive format
dictionary compression
compression ratio
random access
block compression
deduplication

Learn next

Compare independent-file compression with a few different solid block sizes on a disposable test collection. Keep the content identical, verify reconstructed files and measure both whole-archive extraction and representative single-file requests. Then study dictionary size separately from solid block size.

Sources

Primary sources: 7-Zip FAQ, discussion of file order and dictionaries in solid archives: https://www.7-zip.org/faq.html . Official 7-Zip repository, “7z ANSI-C Decoder” documentation, partly solid archives and block caching: https://raw.githubusercontent.com/ip7z/7zip/main/DOC/7zC.txt . The numerical comparison and BundleLane case are original illustrations, not product performance claims.

Previous: Software testing Next: Solomon four-group design