Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I run zfs as the storage pool for my incus (next lxd) services. It is the ideal fit. Here is a list:

- Instant, zero-copy container cloning from images via Copy-on-Write. If you boot a new image like the existing ones it's seconds.

- Atomic, millisecond-level instance snapshots regardless of storage size

- Block-level container migration using native 'zfs send' and 'zfs receive', very short command lines and seems to work perfectly.

- Granular dataset nesting (every instance, image, and custom volume gets its own ZFS dataset). You can see every filesystem even on the host.

- Transparent, inline data compression (LZ4/ZSTD) enabled automatically per dataset. For services that don't change much, you might as well use a compressed image to make them even smaller.

- Mirroring / Raid

- Sub-volume sharing and direct management via native ZFS administration tools. If my home directory has a build area and a million files, I can just save time and put my home, pre cooked into a new machine and not copy or even rebuild on my new machine.

- Dedup keeps blocks with the same data as a reference. This costs a lot of memory and has not saved much for me as a lot of my images are similar and already shared I think, but it's cool.



> - Dedup keeps blocks with the same data as a reference. This costs a lot of memory

To get around this you can add an SSD mirror as "Special" vdev, the dedup table will then be saved there, freeing up your memory.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: