Jan, I have studied to some extent the PDF and the code. I have some questions; perhaps you can address them? 1) btrfs_qgroup_account_ref() calling btrfs_find_all_roots(): I understand that bytenr indicates some EXTENT_ITEM, which is a back-reference for extent, which is perhaps a tree block (leaf or node) or EXTENT_DATA. I also understand, that we want to receive a list of subvolume roots, that reference this extent at some point in time in the middle of a transaction. However, there is mentioning of "finding all extents that reference this extent", which is something basic I don't understand. How an extent can back-reference another extent? Also, how do we encounter roots (which is what we need in the output) during this walking? Hope you can shed some light, or you can let me continue digging in the code:) 2) btrfs_qgroup_account_ref() step 3: I understand that at this step, we look at all roots that we cannot reach from the new root (the one to/from which the ref is added/removed). And we check the refcnt before/after addition/deletion (respectively). Then we check that its refcnt before/after addition/deletion equals to the number of reachable roots before/after addition/deletion. I still don't understand fully why if these two values are equal, we can update exclusive count? My partial understanding is that such root, let's say before addition, was exclusive owner of the extent. And now (since this root is not reachable from new root), we are adding the extent to some "disjoint" qgroup, so the previous root is not exclusive owner anymore. Is this correct direction? 3) The paper mentions "tracking groups" to account for referenced/exclusive properly during snapshot creation. Looking at btrfs-progs, I see that currently the user is expected to correctly indicate which values should be copied from where, and kernel (more or less) blindly copies those values. Is this correct? 4) GROUP_RELATION items: We have two such items for every relation. How do we know which one is the child and which is the parent? It looks from the kernel code that it is expected that child-qgroupid < parent-qgroupid. Is this correct? If yes, who is enforcing this? Thanks for your help, Alex. On Thu, Jul 12, 2012 at 12:43 PM, Jan Schmidt <list.btrfs@xxxxxxxxxxxxx> wrote: > This is a new version of Arne's qgroup patches from last October. The > old patches didn't get the backref walking right, which is now based on > the tree modification log. > > You can limit the space available to subvolumes or any group of > subvolumes. You can determine the amount of space that will get freed > when deleting a snapshot. > > The initial scan is still missing, so expect negative counters when you > enable quotas on a non-empty volume and then delete stuff. > > Arne's introduction and concept description can still be found at > > http://sensille.com/qgroups.pdf > > You can pull these patches from my git repository > > git://git.jan-o-sch.net/btrfs-unstable qgroup > > The user mode patches required were sent at October 11, 2011 by Arne, > subject "[PATCH v0] btrfs-progs: add qgroup commands". > > I tried to include some fair benchmark results with this cover letter. > However, I tried several disk benchmarks from the phoronix test suite, > none of them resulted in any write throughput decrease. I will have to > create a more realistic setup on my own to benchmark the impact of > qgroups (suggestions welcome). For now, I just wanted to get that patch > set out :-) > > Thanks, > -Jan > > Arne Jansen (11): > Btrfs: qgroup on-disk format > Btrfs: add helper for tree enumeration > Btrfs: check the root passed to btrfs_end_transaction > Btrfs: added helper to create new trees > Btrfs: qgroup state and initialization > Btrfs: Test code to change the order of delayed-ref processing > Btrfs: qgroup implementation and prototypes > Btrfs: quota tree support and startup > Btrfs: hooks to reserve qgroup space > Btrfs: add qgroup ioctls > Btrfs: add qgroup inheritance > > Jan Schmidt (4): > Btrfs: fix buffer leak in btrfs_next_old_leaf > Btrfs: join tree mod log code with the code holding back delayed refs > Btrfs: call the qgroup accounting functions > Btrfs: hooks for qgroup to record delayed refs > > fs/btrfs/Makefile | 2 +- > fs/btrfs/backref.c | 30 +- > fs/btrfs/backref.h | 3 +- > fs/btrfs/ctree.c | 348 ++++++++---- > fs/btrfs/ctree.h | 233 +++++++- > fs/btrfs/delayed-ref.c | 56 +- > fs/btrfs/delayed-ref.h | 62 +-- > fs/btrfs/disk-io.c | 134 ++++- > fs/btrfs/disk-io.h | 6 + > fs/btrfs/extent-tree.c | 119 ++++- > fs/btrfs/ioctl.c | 244 +++++++- > fs/btrfs/ioctl.h | 62 ++- > fs/btrfs/qgroup.c | 1571 ++++++++++++++++++++++++++++++++++++++++++++++++ > fs/btrfs/transaction.c | 57 ++- > fs/btrfs/transaction.h | 11 + > 15 files changed, 2696 insertions(+), 242 deletions(-) > create mode 100644 fs/btrfs/qgroup.c > > -- > 1.7.3.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
