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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
