nbdkit-lzip-filter(1)

📦
version 1.48.1 · 10 versions
, in fedora 44

💖 nbdkit-lzip-filter 💖

okay so this is the manual page for nbdkit-lzip-filter from the NBDKIT manual (section 1), bestie. pull up a chair, grab a strawberry 🍓, and let's get into it.

🌸 NAME 🌸

nbdkit-lzip-filter — the nbdkit lzip filter. that's it, that's the name, it ate 💅

✨ SYNOPSIS ✨

nbdkit --filter=lzip file FILENAME.lz

nbdkit --filter=lzip curl https://example.com/FILENAME.lz

like. look at that. two whole lines. iconic.

🦋 DESCRIPTION 🦋

nbdkit-lzip-filter is a filter for nbdkit(1) that transparently decompresses an lzip(1)-compressed file. no cap, it just does it, you don't even have to think about it 🫶

so you can stack this filter on top of nbdkit-file-plugin(1) to decompress a local .lz file, or on top of other plugins, like for example nbdkit-curl-plugin(1):

nbdkit curl --filter=lzip https://example.com/disk.lz

and if you pair it with nbdkit-partition-filter(1) you can mount one specific partition of a compressed disk image. main character behaviour tbh:

nbdkit curl --filter=partition --filter=lzip \
       https://example.com/disk.img.lz partition=2
🚨 heads up bestie: the filter only supports read-only connections. it's giving "look but don't touch" and honestly, respect.

also important: this filter was made primarily for multi-member files. single-member files are currently only supported up to a size of lzip-max-block and their contents are kept in memory. so like, don't come for it about the single-member thing, it's a known vibe.

💀 Single-member files and multi-member files 💀

okay so here's the lore: an lzip-compressed file is made of one or more members, and each member contains an LZMA stream plus some metadata. most lzip files? just a single member holding all of the compressed data. simple. slay.

you can find out the number of members in an lzip file by doing this:

$ lzip --list --verbose lfs.img.lz
  dict   memb  trail   uncompressed   compressed   saved  name
  8 MiB     1      0    10737418240   1808781538  83.15%  lfs.img.lz
          ↑↑↑
         members

seeking an lzip file works by seeking directly to the lower member boundary, then decompressing data until the precise byte is reached. and because of that? single-member files are not seekable and have to be decompressed entirely 😭 no shortcuts, no skips, we're reading the whole thing.

🔥 Getting the best random access performance 🔥

want that good good random access? use the plzip(1) parallel compressor with the --data-size option set to a small-ish block size. plzip first splits the input file into fixed-size data blocks before compressing each block as a separate member. so cute of it.

for example, this is the same image as above compressed with plzip on default settings, resulting in a block size of 16 MiB:

$ lzip --list --verbose lfs.img.lz
  dict   memb  trail   uncompressed   compressed   saved  name
  8 MiB   640      0    10737418240   1839569039  82.87%  lfs.img.lz
          ↑↑↑
         members

look at those 640 members. the way that file allows random access in constant time 🧚 at most 16 MiB will have to be decompressed to seek to any byte, and the position of the member that needs to be decompressed can be computed directly. periodt.

if you don't have access to plzip, you can achieve the same result using the split(1) utility together with regular lzip:

$ split -b 16m disk.img disk.img.part
$ lzip disk.img.part*
$ cat disk.img.part*.lz > disk.img.lz
🙈 do NOT just use lzip with the --member-size option, because that option refers to member size, not data block size. they are not the same thing and this is the trap, bestie, i'm telling you now so you don't find out the hard way.

🌈 Multi-member files with variable-size data blocks 🌈

some ways of creating multi-member lzip files — like the --member-size option or the tarlz(1) utility — result in data blocks of varying sizes. in that case, seeking requires a binary search on the member index and random access takes logarithmic time. still fine, just not constant time. it's giving "we do it, but we do it the long way" 💅

🎀 PARAMETERS 🎀

  • lzip-max-block=SIZE — the maximum block size that the filter will read. the filter will refuse to read lzip files that contain any data block larger than this size. ngl this value refers to the size of the uncompressed block, not the size of the member holding it. this parameter is optional. if not specified it defaults to 512M.
  • lzip-max-depth=N — maximum number of blocks stored in the LRU block cache. this parameter is optional. if not specified it defaults to 8. 💭 and btw, the filter may allocate up to maximum block size in file × maxdepth bytes of memory per connection. so like, mind your RAM, queen.

🌟 FILES 🌟

  • $filterdir/nbdkit-lzip-filter.so — the filter. that's the one. use nbdkit --dump-config to find the location of $filterdir. iykyk.

⭐ VERSION ⭐

nbdkit-lzip-filter first appeared in nbdkit 1.42. it is derived from nbdkit-xz-filter which first appeared in nbdkit 1.10. glow up fr fr 🌱➡️🌳

👑 SEE ALSO 👑

nbdkit(1), nbdkit-filter(3), nbdkit-curl-plugin(1), nbdkit-file-plugin(1), nbdkit-bzip2-filter(1), nbdkit-gzip-filter(1), nbdkit-partition-filter(1), nbdkit-xz-filter(1), lzip(1), plzip(1), tarlz(1).

💜 AUTHORS 💜

Jan Felix Langenbach

Richard W.M. Jones

Copyright Jan Felix Langenbach

Copyright Red Hat

📜 LICENSE 📜

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  • Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  • Neither the name of Red Hat nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY RED HAT AND CONTRIBUTORS ''AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL RED HAT OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

and that's the whole page, bestie 🫶 this came out of nbdkit-1.48.1, dated 2026-08-29 💖 go forth and decompress responsibly ✨🎀🦋

📦 where this page comes from