XFS for LXC container

R

Reinis Rozitis

Member
Nov 2, 2016
11
2
8
42
Hello,
is there a workaround (or a tweak for mount options for the backup process) for a LXC container to work correctly with XFS mount point?

Currently for a newly created CT I can simply attach an ext4 volume from the GUI and then convert it to xfs volume but it breaks backup as XFS doesn't support the 'noload' mount option:

[ 2129.625945] XFS (dm-28): unknown mount option [noload].

Nov 2 19:54:53 box pvedaemon[13563]: ERROR: Backup of VM 113 failed - command 'mount -o ro,noload /dev/dm-28 /mnt/vzsnap0//data' failed: exit code 32
Nov 2 19:54:53 box pvedaemon[13563]: INFO: Backup job finished with errors
 
Last edited:
  • Like
Reactions: waltar
Reinis Rozitis said:
ext4 is the default filesystem for lxc but to attach an new one you just go to particular container in the GUI then choose Resources and there is an Add / Mount point option.
Click to expand...
I still don't understand how you are able to use XFS for the container's raw file when LXC containers seem to have been hard-wired to use ext4? Do you mind briefly running through it?
 
moxfan said:
I still don't understand how you are able to use XFS for the container's raw file when LXC containers seem to have been hard-wired to use ext4? Do you mind briefly running through it?
Click to expand...
Rather than raw files I'm using thin provisioned LVS volumes (probably would be the same with zfs backed zvols) so when the container is stopped you can convert (and mount if needed) the volumes on the host.

p.s. There is no (at least I don't know) straight forward ext4->xfs conversion without data loss. So while it's simple with empty volumes/mount points, for the rootfs you have to mount the volume, then backup the data, format and then sync it back. Afterwards you can just quickly clone new LXC cotainers with vzdump and pct restore to keep the setup .. just the backup function won't work from the GUI.
 
Last edited:
Reinis Rozitis said:
There is no (at least I don't know) straight forward ext4->xfs conversion without data loss. So while it's simple with empty volumes/mount points, for the rootfs you have to mount the volume, then backup the data, format and then sync it back. Afterwards you can just quickly clone new LXC cotainers with vzdump and pct restore to keep the setup .. just the backup function won't work from the GUI.
Click to expand...
What do you recommend to use to back up the rootfs? Rsync? Tar?
 
I am looking into using XFS because I have a large number of small files in the LXC CT application. With EXT4, I frequently run out of inodes, which is not an issue with XFS. Currently, I have to manually convert EXT4 to XFS using the CLI for Ceph RBD disks and then mount it. Having this functionality available in a GUI would be highly beneficial." to choose EXT4 or XFS as disk option; might be for specific storage type.
 
Deepen Dhulla said:
Currently, I have to manually convert EXT4 to XFS using the CLI for Ceph RBD disks and then mount it. Having this functionality available in a GUI would be highly beneficial." to choose EXT4 or XFS as disk option; might be for specific storage type.
Click to expand...
As the lxc templates are still all still created with ext4 inside you cannot have a choose option but a convert button could be possible (still manually converting ext4 to xfs too but just more for fun as our pve env is just for testing and has no real app loads which need that yet) :)
 
Well you could change the way they are provisioned. It already does so for ZFS filesystems.

However, my advice would be that if you are running out of inodes that's likely the wrong usecase for a container, mostly thinking on how painful it must be to backup that at a file level.

You could create a file backed ZFS pool. But that's a fragile setup.

Would still like an XFS option, seems like it shouldn't be that hard to implement it and would have minor performance advantages, as well as the ability to reflink.

Theoretically it should be possible to put everything behind a single XFS filesystem by using xfs quotas which may have performance and space efficiency advantages. However, this would require significant effort for probably little gain. https://docs.redhat.com/en/document...torage_administration_guide/xfsquota#xfsquota
 
iviso said:
However, my advice would be that if you are running out of inodes that's likely the wrong usecase for a container, mostly thinking on how painful it must be to backup that at a file level.
Click to expand...
iviso said:
Would still like an XFS option, seems like it shouldn't be that hard to implement it and would have minor performance advantages, as well as the ability to reflink.
Click to expand...
However ... if having the lxc on xfs backed nfs storage just do 1 reflink of the lxc image with it's million files inside, nothing easier than that.
For individual file restores mount the image and get desired files back. :)
 
I have created since a lot of XFS containers, and it works with little problems.

The method is either create a small almost empty container, create an XFS disk image (create an image, format XFS, mount, rsync my system template over, unount and replace image in the container config file), or usually using a second disk (mount) of XFS formatted disk image.

The only problem is that proxmox tools are unable to handle it, so you cannot grow it, for example, using the tools, and I am not sure now about snapshotting (I should find one and check, but tools may fail when they do ext4 specific things like syncing before backup). But I do not remember major problems, like backups work, start/stop/HA works, and there are no online migration and never will, so that's a non-problem as well. :-/

But it's rather easy to test, creating an XFS extra disk and check functions you use. Pity that it's still not supported even if it would be rather simple. I wonder whether they'd accept patches, but I shall check how messy the ext4 integration is.
 
Don't to forget that the container image don't have xfsprogs installed and must be done before copy over to xfs ... :)
I don't think it woul be a problem to grow the xfs as it's first still 1 image file and doing a mkfs.xfs onto. So just a dd attachment and xfs_growfs should do the job.
 
waltar said:
Don't to forget that the container image don't have xfsprogs installed and must be done before copy over to xfs ... :)
Click to expand...
Yes, that is probably the way to go if you want to use the filesystem. ;-)

waltar said:
I don't think it woul be a problem to grow the xfs as it's first still 1 image file and doing a mkfs.xfs onto. So just a dd attachment and xfs_growfs should do the job.
Click to expand...
I mean you cannot grow it using the GUI tools. Actually, yes, growing was a little pain because you cannot simply do online growing, since you cannot grow from inside, and you cannot simply mount it when it's running. I shall find my script which enters the namespace, grows the device and leave.
 
You must log in or register to reply here.
Top Bottom