qgroup destroy / assign
how are qgroups accounted for? Are they specifially tied to one subvolume on creation?
If so, is it possible to auto delete relavant qgroups on deletion of the subvolume?
also, how exactly does qgroup assign work? I havent been able to get it to work at all.
in btrfsprogs cmds-cgroup.c
if ((args.src >> 48) >= (args.dst >> 48)) {
fprintf(stderr, "ERROR: bad relation requested '%s'\n", path);
return 1; }
always seems to fail. I tried creating another qgroup id 1000, and assigning it to as sub, and vice versa, as well as assigning the sub to the root, and vice versa, as well as one subvol to another. The fixme comment leads me to believe that the src should be a path not a qgroup ("FIXME src should accept subvol path")
but the progs let me create a qgroup without a subvol, which makes sense if you want to be able to have some meta-qgroup for a bunch of subvols. Further on noticing that a sub create also creates a qgroup with the same id as the subvol, it would seem that the qgroup is tied to the subvol via this shared id.
-Kevin Brandstatter
Hi Kevin,
Quoted 2 lines · Kevin Brandstatter
how are qgroups accounted for? Are they specifially tied to one subvolume on creation?
Qgroup implementation is aslo a little confusing for me at first:-) .
Yes, a qgroup is created automatically tied to one subvolume on creation with the same objectid.
To implement qgroup group, you may want to do something like following:
[1/1]
/ \
/ \
sub1(5) subv2(257)Quoted 3 lines
If so, is it possible to auto delete relavant qgroups on deletion of the subvolume?
I supposed so, according to latest qgroup patches flighting on, a subvolume qgroup should be destroyed safely, when it finished sub-tree space accounting.
Quoted 8 lines
also, how exactly does qgroup assign work? I havent been able to get it to work at all.
in btrfsprogscmds-cgroup.cif ((args.src >> 48) >= (args.dst >> 48)) { fprintf(stderr, "ERROR: bad relation requested '%s'\n", path); return 1; }
Oh, this is to implement a strict level qgroup group, which means a u64 is divided into two parts, 16bits for level and the rest for id.
So we ask parent qgroup's level must be greater than child's qgroup.that is the code you see above.
You could create a qgroup relation like this:
# btrfs qgroup assign 256 1/1 <mnt>
Hopely, this could help you.
Quoted 17 lines
always seems to fail. I tried creating another qgroup id 1000, and assigning it to as sub, and vice versa, as well as assigning the sub to the root, and vice versa, as well as one subvol to another. The fixme comment leads me to believe that the src should be a path not a qgroup ("FIXME src should accept subvol path")
but the progs let me create a qgroup without a subvol, which makes sense if you want to be able to have some meta-qgroup for a bunch of subvols. Further on noticing that a sub create also creates a qgroup with the same id as the subvol, it would seem that the qgroup is tied to the subvol via this shared id.-Kevin Brandstatter
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Wang,
Yes that certainly helps me make more sense of it. I was able to get the qgroup assigning to work properly.
I guess the next question would be if it would be a valid feature to implement automatic qgroup deletion
when a subvolume is destroyed. I suppose in order to help alleviate issues with that perhaps it may also be useful to
require user created qgroups to be at least level 1. that way it would be trivial to detect qgroups that were created for subvolumes, as they would all be level 0. I don't think this would cause any issues since you can't assign a subvolume to another qgroup from what I can tell, only a qgroup to another qgroup.
-Kevin
Quoted 64 lines · Wang Shilong
Hi Kevin,
Quoted 2 lines · Kevin Brandstatter
how are qgroups accounted for? Are they specifially tied to one subvolume on creation?
Qgroup implementation is aslo a little confusing for me at first:-) .
Yes, a qgroup is created automatically tied to one subvolume on creation with the same objectid.
To implement qgroup group, you may want to do something like following:
[1/1] / \ / \ sub1(5) subv2(257)Quoted 3 lines
If so, is it possible to auto delete relavant qgroups on deletion of the subvolume?
I supposed so, according to latest qgroup patches flighting on, a subvolume
qgroup should be destroyed safely, when it finished sub-tree space accounting.Quoted 8 lines
also, how exactly does qgroup assign work? I havent been able to get it to work at all.
in btrfsprogscmds-cgroup.cif ((args.src >> 48) >= (args.dst >> 48)) { fprintf(stderr, "ERROR: bad relation requested '%s'\n", path); return 1; }Oh, this is to implement a strict level qgroup group, which means a u64 is
divided into two parts, 16bits for level and the rest for id.So we ask parent qgroup's level must be greater than child's qgroup.that is the code you see above.
You could create a qgroup relation like this:
# btrfs qgroup assign 256 1/1 <mnt>Hopely, this could help you.
Quoted 18 lines
always seems to fail. I tried creating another qgroup id 1000, and assigning it to as sub, and vice versa, as well as assigning the sub to the root, and vice versa, as well as one subvol to another. The fixme comment leads me to believe that the src should be a path not a qgroup ("FIXME src should accept subvol path")
but the progs let me create a qgroup without a subvol, which makes sense if you want to be able to have some meta-qgroup for a bunch of subvols. Further on noticing that a sub create also creates a qgroup with the same id as the subvol, it would seem that the qgroup is tied to the subvol via this shared id.-Kevin Brandstatter
Signature · 4 lines
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html