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. > > Thanks, > Qu > -- Filipe David Manana, “Whether you think you can, or you think you can't — you're right.”
