On Wed, Aug 31, 2016 at 4:47 PM, Jeff Mahoney [off-list ref] wrote:

On 8/31/16 5:48 PM, Chris Murphy wrote:

quoted

OK it looks like with -w flag I can get a reliable indication of
whether quota is enabled or not:

[root@f24s ~]# btrfs quota enable /mnt/0
[root@f24s ~]# btrfs quota rescan -w /mnt/0
quota rescan started
[root@f24s ~]# btrfs quota disable /mnt/0
[root@f24s ~]# btrfs quota rescan -w /mnt/0
ERROR: quota rescan failed: Invalid argument


So if you did not enable quota support, and aren't sure if it's
enabled you can try 'btrfs quota rescan -w <mp>' but this might
actually be a bad idea, a rescan could take a while if you're actually
using quotas, I have no idea because I don't use them.

It can take a while, but the code is smart enough not to get too much in
the way of other activity.  It maintains a progress marker and only does
live accounting on extents that have already been scanned.

quoted

Perhaps someone can point out an easier way to determine whether
quotas are enabled?

btrfs qgroup show <path>

Wow, thanks but that's not obvious at all. man btrfs quota is
described as "btrfs-quota - control the global quota status of a btrfs
filesystem" so it stands to reason the state command for whether it's
enabled or disabled would be in that subcommand not in some other
subcommand.

But this is sidetracking. Does Ronan's call trace showing
/fs/btrfs/qgroup.c:2667

btrfs_qgroup_free_meta implicate qgroups as a possible source of his problem? That trace would only happen if quotas were enabled, right?

-- 
Chris Murphy