Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Make it possible to store images and backups on a storage pool #5515
Right now, the original image artifacts and the container backups are stored on the main system storage, not on any of LXD's storage pools.
This is surprising to users who may then run themselves out of disk space despite having a lot of storage directly assigned to LXD.
I believe we should introduce two new configuration options (daemon level):
When not set, we store things directly in the directory as we used to.
Those settings may be changed and data will be moved around as needed.
Those storage volumes must be adequately protected so that they may not get attached to a container and may not be deleted or renamed while in use.
We also need to disallow the use of CEPH for this as CEPH+cluster would fail miserably.
Indeed this has happened to me. It's nice to see a project manager so responsive that he see the need to solve my problem before I have it :-)
But is it a real problem for images ? Images are usually 150-200 mb and only one at a time is stored temporarily on the file system
There is the problem of snap adding 'protection' to file accesses for people using lxd with snapcraft, though. Maybe that's the reason you want to add all this stuff.
From what I see, export does on the file system a full copy of all container data AND a tarball AND the gzipped tarball, needing so about 2,5 times the actual container size. Probably for the best, but lxc-export doc (if it actually existed) should say clearly that you need at least that on the temporary workspace. Many people would assume that 50% over the biggest container should be more than enough. Possibly the container copy could be zapped before creating the gzipped tar from the tarball. I don't quite see why it's needed at this point. I'd dare to say that efforts to make this more efficient could be actually useful.