How to display quota limit on btrfs subvolume?

Use options -r and -e:

btrfs qgroup show -pcre /path

I created a simple script that will show the quota limit for each sub-volume in the specified path and the used space too. The syntax is pretty simple:

./quota.sh path

To print the used space for all sub-volumes use the -a flag:

./quota.sh path -a

Don't forget to add execution permissions to the script.

Script:

#! /bin/sh
volumes=$(btrfs subvolume list  $1 | cut -d " " -f 9 )
snapshots=$(btrfs subvolume list -s  $1 | cut -d " " -f 14 )
regsnap=$(echo $snapshots | sed 's/ /,/g')
normalv=$(echo $volumes | sed "s/\($regsnap\)//g" )

if [ ! -z "$snapshots" ] ; then
    echo SNAPSHOTS
for p in $snapshots; do 
    quot=$(btrfs qgroup show -rF $1/$p | tail -1)
    if [ -z $2 ]; then
        (echo $quot | grep -q none) || echo $p $quot
    else
     [ "$2" == "-a" ] && echo $p $quot
    fi
done
fi

if [ ! -z "$normalv" ] ; then
    echo SUBVOLUMES
for p in $normalv; do 
    quot=$(btrfs qgroup show -rF $1/$p | tail -1)
    if [ -z $2 ]; then
        (echo $quot | grep -q none) || echo $p $quot
    else
     [ "$2" == "-a" ] && echo $p $quot
    fi
done

fi

It will print first the traditional sub-volumes and below the snapshots volumes. Sample output:

SNAPSHOTS
apple 0/258 1.32MiB 16.00KiB 20.00MiB
SUBVOLUMES
citrus/orange 0/256 1.32MiB 16.00KiB 20.00MiB

As we speak, btrfs is broken by design in this regard.

There is currently no function in btrfs-progs, to show which subvolume has which quota. You have to write a script (and many who fell for btrfs do), to parse the abstract quota group numbers it outputs, and list the subvolumes inside those quota groups below them. It could be added, but the btrfs developers religiously refuse to do this.

Even worse, there is not only no way to show how much of the quota a subvolume currently uses up. Which is why df only shows the total free space. It is not possible to do this at all due to how btrfs is designed at its very core. This is because subvolumes work like snapshots. Meaning, to find out how much data is in a subvolume, you’d have to scan the entire file system, and find all the files linked to that subvolume/snapshot, and add them up. Just like the du command. Which takes a lot of time. I have no idea how btrfs then knows a quota is full at all… The IRC channel could not provide me with any answer to that. (They were to busy defending their fragile over-inflated egos.) The sensible thing would be, to change the subvolume counter each time data is added or removed. Which kinda must be how btrfs knows it is full. At least I don’t know any other way. But why they would then chose to keep this available info basically a military-guarded state secret, I don’t know…

If zfs wouldn’t have such insane RAM requirements (1GB per TB … not an option on e.g. a single-board ARM computer) and the risk of data loss, due to not writing data early, due to being designed for servers with crash protection, I would recommend dumping btrfs in its favor.