Moved from Ext4 to BTRFS, now DIR quotas have no effect

Hello,

First I installed Debian 13 with Incus 7.0.1 (backports) in a single Ext4 partition for whole OS. I enabled “prjquota” and succeeded on setting containers’ device root size.

After this, I created a separate BTRFS partition and moved /var to it, so all Incus data (with VPS, VM, etc.) is there now. The move was done from an external session (Debian 13 Live) by only copying files: cp -a /media/user/rootvolume/var/* /media/user/var/

Once rebooted into static media (Debian+Incus), I see containers have devices:root:size set but this setting has no effect. Inside each container whole host partition space is seen.

From host I see:

$ sudo btrfs qgroup show -r /var
Qgroupid    Referenced    Exclusive  Max referenced   Path
0/5          987.34GiB    987.34GiB            none   

What should I do to apply storage quotas to containers again?

Thank you.

hmm, I’d have expected that enabling quotas on btrfs and then re-applying your root size limits would populate things. Though I don’t remember btrfs quotas being reflected in df or similar in the container, so that part may be normal.

Ext4 quotas (prjquota) were reflected in guest df

How do I see this when using btrfs filesystem for DIR containers?

This command has no effect with my btrfs, as a way to re-apply root size limit:

$ incus config device set MyContainerName root size=20GiB

I’ve also tried with new container creation, and I find same lack of disk limit appearance:

$ incus launch images:debian/13 MyContainerName2 --device root,size=20GiB

And also tested reality of limits; no limit in effect:

$ incus config device set MyContainerName2 root size=5GiB
$ incus exec MyContainerName2 -- dd if=/dev/urandom bs=1M count=10240 of=test1.dat

I see from incus admin init wizard:

  • Do you want to configure a new local storage pool? (yes/no) [default=yes]:
  • Name of the storage backend to use (dir, btrfs) [default=btrfs]:
  • Would you like to create a new btrfs subvolume under /var/lib/incus? (yes/no) [default=yes]:

I suppose when it’s asking between {dir, btrfs} i really means {ext4, btrfs} because btrfs is used with DIR driver; am I right?

Do I need to do some storage pool conversion from DIR[ext4] to DIR[btrfs] ?

Yes, the kernel report project quotas in disk usage, it doesn’t report the btrfs qgroups though.
That’s not something we control ourselves.

Ah, so yeah, if you’re using the dir driver on top of btrfs, then you get the worse of both worlds :slight_smile:
Basically you don’t get the btrfs subvolume based stuff, so still duplicate a lot of data AND you don’t get quotas at all because you don’t have project quotas and aren’t using the driver that knows how to do qgroups.

Then you mean for btrfs I also need to run tune2fs -O project -Q prjquota to this volume? Or I need to create subvolumes? Or this can be done by running incus admin init wizard again?

Is it the same to get deduplication/CoW feature?

Documentation is a bit confusing about dir/btrfs; If BTRFS driver means not DIR, this should be clear, and then mention DIR driver has only sense on top of Ext3/Ext4.

dir works on any filesystem and therefore supports almost no features. You can run it on ext3/ext4, you can run it on vfat, on xfs or on top of btrfs or ZFS. It will basically always work, just equally as bad everywhere.

btrfs is what you want when you want to run on btrfs (as the name kinda implies) and it therefore uses btrfs features like subvolumes, quota groups, send/receive, compression, …

tune2fs is the ext3/ext4 configuration tool, so that cannot do anything useful on a btrfs filesystem.