Convert LZO to TAR.BZ2 Online (Speed-First Stream to a Slower, Tighter Archive)

A Bare LZO Stream Is One File, Not a Folder — Here's the Difference That Matters

A plain .lzo file, without a .tar in front of it, is a single file run through lzop, the command-line utility built on Markus Oberhumer's LZO compression library, which he began developing around 1996 and first released as lzop on August 10, 1997. Lzop's own documentation is explicit about this: it compresses one file at a time and leaves each output as a standalone compressed copy of that one input, the same way gzip works on a lone file. It does not bundle multiple files or folders together — that job belongs to tar, which is why a directory tree compressed this way shows up as .tar.lzo, not a bare .lzo. So converting a raw .lzo file to .tar.bz2 means decompressing one single file with lzop first, then feeding that recovered file into tar, which wraps it in tar's own 512-byte header blocks (recording name, permissions, and size) before bzip2 compresses the whole resulting stream.

LZO's whole design goal, stated directly in its documentation, is favoring decompression speed over squeezing the file down as far as possible. Its default method, lzo1x_1, does a simplified Lempel-Ziv-style scan that replaces repeated byte sequences with back-references and skips the entropy-coding step that most other compressors add on top. That missing step is exactly why an .lzo file is usually noticeably larger than the same data compressed with bzip2, but decompresses much faster.

Every file lzop produces also starts with a fixed nine-byte magic sequence (0x89 0x4C 0x5A 0x4F 0x00 0x0D 0x0A 0x1A 0x0A), a signature deliberately modeled on PNG's own magic-byte design, chosen so the format is easy to detect reliably and fails loudly rather than silently if it gets mangled by a text-mode transfer. The header that follows records the LZO method and level used, plus the original filename, timestamp, and Unix permission bits — metadata a bzip2-compressed tar file stores differently, since tar keeps that same information in its own per-entry header blocks instead of a compressor-level header.

Bzip2's Burrows-Wheeler Block Sort Works Nothing Like LZO's Byte Matching

Bzip2, written by Julian Seward and first released in 1996, compresses data through a completely different pipeline than LZO's back-reference matching. It runs each block of input through the Burrows-Wheeler Transform, which rearranges the bytes to group similar sequences together without changing the data itself, followed by move-to-front encoding and then Huffman coding to actually shrink the rearranged result. Bzip2 processes data in blocks of up to 900 KB (selectable from 100 KB up in 100 KB steps via its -1 through -9 flags), and each block carries its own compression state, which is part of why a bzip2 file can sometimes recover the blocks after a damaged one, unlike a single continuous LZO stream.

The practical result of these two different pipelines is a real, measurable trade: bzip2 typically produces a smaller file than LZO on the same data, especially on text and source code where the Burrows-Wheeler Transform finds patterns LZO's simpler matching misses, but bzip2 takes noticeably longer to both compress and decompress because of the extra transform and Huffman stages LZO skips entirely. Converting from LZO to tar.bz2 is a direct trade of that speed for that size.

What Rebuilding an LZO File as a Bzip2 Tarball Changes

• Gain — usually a smaller file: bzip2's Burrows-Wheeler Transform plus Huffman coding tends to beat LZO's simpler matching, sometimes substantially on text-heavy data.
• Gain — the ability to bundle more than one file: tar wraps the recovered file (and anything else added alongside it) into one archive with proper multi-file structure, something a bare .lzo file was never built to do.
• Lose — LZO's decompression speed advantage: bzip2's extra transform stages make it slower to unpack than the near-instant decompression lzop is specifically built for.
• Lose — LZO's very light CPU and memory footprint: bzip2's block sorting is considerably more demanding on both fronts, which matters on constrained or embedded hardware.
• Gain — wider desktop tool support: bzip2 is recognized by 7-Zip, most Linux archive managers, and many general-purpose tools by default, while LZO decompression usually needs lzop specifically installed.
• Lose — nothing about the file's actual bytes: once fully decompressed and recompressed, the recovered content is identical; only the container and compression method around it changed.

Which Systems Actually Ship lzop and bzip2 Ready to Use

Bzip2 support is close to universal on Linux and macOS: both operating systems' command lines include bzip2 or a bzip2-aware tar by default, and 7-Zip on Windows opens .tar.bz2 archives without any extra plugin. Lzop, by contrast, isn't preinstalled nearly as often — it's a separate package on most Linux distributions (commonly named lzop) and generally has to be installed explicitly before a .lzo file can be decompressed at all, since mainstream tools like 7-Zip and WinRAR generally don't include native LZO support out of the box.

This asymmetry is exactly why a conversion path from LZO to tar.bz2 has real value: a .lzo file arriving from an embedded Linux device, a router firmware dump, or a kernel-adjacent tool like zram or Btrfs (which both document LZO as a supported compression backend) may not open at all on a machine that doesn't already have lzop installed, while the resulting tar.bz2 opens with tools that are already standard almost everywhere.

The LZO library and lzop itself are both released under the GNU General Public License, version 2 or later, a copyleft license that some proprietary embedded-firmware projects have documented as a real factor when choosing a fast compressor, since GPL code carries redistribution obligations a more permissively licensed option wouldn't. Bzip2's own source code, by contrast, is distributed under a simple BSD-style license with no such copyleft requirement, which is one reason it appears bundled into so much general-purpose and commercial software without licensing friction.

The Actual Problems That Show Up Converting a Raw LZO File

A recurring, documented issue is a downloaded .lzo file simply failing to open in 7-Zip, WinRAR, or a generic online extractor — this isn't corruption; those tools generally don't include LZO decompression at all, since the format is used almost exclusively in Linux, embedded, and kernel contexts where lzop is already available specifically for this purpose. Installing lzop itself, or a tool that wraps it, resolves this reliably.

A second common point of confusion involves the file actually being a .tar.lzo (or its shortened cousin .tzo) that was renamed or mislabeled as plain .lzo — since a bare .lzo holds exactly one file, trying to treat it as a multi-file archive and getting only one item back out is expected behavior, not a bug, and checking whether the original file was actually a tar archive first resolves the mismatch.

A third pattern involves memory-constrained environments choking on bzip2's block-sort step during the compression side of this conversion; bzip2's Burrows-Wheeler Transform is considerably more memory-hungry per block than LZO's matching, so very large files can compress noticeably more slowly, or need a smaller block size (via bzip2's -1 through -9 flags) on machines with limited RAM.

LZO's Speed Priority Against Bzip2's Size Priority, Side by Side

Questions About Moving a Raw LZO File Into a Bzip2 Tarball

Is a bare .lzo file the same thing as a .tar.lzo file?
No. Lzop's own documentation treats plain .lzo as one file compressed by itself, while .tar.lzo (or .tzo) is a whole tar archive of multiple files that's been compressed afterward — mixing the two up leads to unexpected results.

Why does bzip2 take longer than LZO on the same file?
Because bzip2 runs a Burrows-Wheeler Transform and Huffman coding pass on top of its matching, stages LZO deliberately skips to keep decompression fast — the extra work is exactly what buys bzip2 its smaller output.

Do I need lzop installed to open a .lzo file?
Usually, yes. Mainstream tools like 7-Zip and WinRAR generally don't include native LZO support, so the lzop utility, or a tool built around its library, is typically required.

Will converting to tar.bz2 change the actual file content?
No. Once the original file is fully decompressed and rebuilt inside the bzip2 tarball, its bytes are identical — only the surrounding compression and container format changed.

Why would anyone still use LZO if bzip2 compresses smaller?
Because LZO's entire purpose is fast decompression on constrained hardware — kernel subsystems like zram and Btrfs use it specifically because speed matters more than file size in those contexts.