Can dataset compression be configured when launching a container?

LXD
1

I posted another question about pros/cons of using compression for the main LXD dataset.

Here I’m wondering if there’s a way to launch a lxd container & configure compression during that launch so the container’s zfs dataset is configured with or without compression, depending on what I specify during the launch command.

So instead of the lxd container inheriting the compression setting for all containers from whatever mypool/lxd is configured with I could have containers without compression or other containers using different compression algorithms.

For example, something like:

lxc launch ubuntu:22.04 ubuntu22 compression=zstd

Would cause the zfs dataset for that container to be created with something like:

zfs create -o compression=zstd ubuntu22

Is this possible?

2

ATM, it’s not possible natively, especially not at the instance/volume granularity. https://github.com/canonical/lxd/issues/13168 is asking for more flexibility in that area.

If you have a special instance that needs zstd and you cannot use it for all your instances/containers, I think you have no choice but to:

  1. create the instance and inherit the compression setting from the parent dataset
  2. stop the instance
  3. zfs send ... <instance> | zfs recv -o compression=zstd ... <instance-dest>
  4. zfs delete <instance-source>
  5. zfs rename <instance-dest> <instance>
  6. start the instance

The above is untested but you get the idea :slight_smile:

I’m a big fan of zstd and personally set it pool-wide and only disable it for known incompressible datasets.

1 Like
3

The workaround you mention seems it may be a good alternative. It was something I was thinking might work for this.

Generally, right now I’m just trying to determine whether to use none, lz4 or zstd on my lxd dataset so the containers that I’ll use for web hosting will inherit the setting. Being able to configure compression at lxd launch time would make that easier for comparing those options.

But I could also see it being beneficial at times to maybe being able to switch the zfs dataset compression used for containers. Maybe, for example, if someone needed to ease up on CPU usage or improve disk throughput, etc. Exporting the container & then importing it with the changed compression setting would make that process fairly easy.

The alternative you described seems it may also work well for this. I may test it out. Also I agree about zstd, I use that on my data pools but was unsure how much difference it may make for a webserver container.

Thanks for your reply.

4

From what I’ve seen/heard, lz4 is so cheap that it’s not worth not using it (none). There are 2 cases where I think using none makes sense:

  1. Super fast IO subsystem (think like Optane, Fusion-io) where comparatively slow CPU could cause latency/bandwidth issue if lz4 was used
  2. Dataset full of known incompressible data (think like JPEGs, MP3s, etc)

For everything else I think the question is lz4 or zstd.