On 8/31/16 6:58 PM, Chris Murphy wrote: > On Wed, Aug 31, 2016 at 4:47 PM, Jeff Mahoney <je...@suse.com> wrote: >> On 8/31/16 5:48 PM, Chris Murphy wrote: >>> 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. >> >>> 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.
Agreed. The tools interface has some warts. > 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? > Yeah. That warning doesn't get checked unless they're enabled. -Jeff -- Jeff Mahoney SUSE Labs
signature.asc
Description: OpenPGP digital signature
