On 2021/1/11 下午8:15, Filipe Manana wrote:
On Sat, Nov 14, 2020 at 12:09 AM Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote:
On 2020/11/13 下午11:19, David Sterba wrote:
On Thu, Nov 12, 2020 at 07:50:22AM +0800, Qu Wenruo wrote:
+$BTRFS_UTIL_PROG quota enable $SCRATCH_MNT
+$BTRFS_UTIL_PROG quota rescan -w $SCRATCH_MNT >> $seqres.full
+
+# Set the limit to just 512MiB, which is way below the existing usage
+$BTRFS_UTIL_PROG qgroup limit 512M $SCRATCH_MNT $SCRATCH_MNT
$SCRATCH_MNT twice by mistake, though the command still works and the
test still reproduces the issue.
Nope, that's the expected behavior.
Btrfs qgroup limit <size> <path>|<qgroupid> <path>
The first path is to determine qgroupid, while the last path is to
determine the fs.
In this particular case, since we're limit the 0/5 qgroup, it's also the
as the mount point, thus we specific it twice.
So why didn't you specify 0/5 so it's clear?
Oh no, my brain just shorted, and forgot that it's 0/5 fixed for fs tree.
0/5 is indeed much better.
Any reason this wasn't merged? What happened?
Thanks for the reminder.
Let me just resend with 0/5 to replace the $SCRATCH_MNT.
Thanks,
Qu
Thanks.
Thanks,
Qu
