There are a couple of reasons I'm advocating the specific behavior I
outlined:
Some of your points are valid, but some break current behaviour and
expectations or create technical difficulties.
1. It doesn't require any specific qgroup setup. By definition, you
can be 100% certain that the destination qgroup exists, and that you
won't need to create new qgroups behind the user's back (given your
suggestion, what happens when qgroup 1/N doesn't exist?).
This is a general problem with current qgroups: you have to reference
them by some random numbers, not by user-assigned names like files. It
would need to be fixed sooner or later with syntax like L:<path> in
place of L/N, or even some special syntax made specifically for path
snapshots.
BTW, what about reserving level 1 for qgroups describing subvolumes and
all their snapshots and forbidding manual management of qgroups at this
level?
2. Just because it's the default, doesn't mean that the subvolume
can't be reassigned to a different qgroup. This also would not remove
the ability to assign a specific qgroup through the snapshot creation
command. This is arguably a general point in favor of having any
default of course, but it's still worth pointing out.
Currently 0/N qgroups are special in that they are created automatically
and belong to the bottom of the hierarchy. It would be very nice to keep
it this way.
Changing qgroup assignments after snapshot creation is very inconvenient
because it requires quota rescan and thus blocks all other quota operations.
3. Because BTRFS has COW semantics, the new snapshot should take up
near zero space in the qgroup of it's parent.
Indeed it works this way in my experiments if you assign snapshot to 1/N
qgroup at creation where 0/N also belongs. Moreover, it does not require
quota rescan, which is very nice.
4. This correlates with the behavior most people expect based on ZFS
and LVM, which is that snapshots are tied to their parent.
I'm not against tying it to the parent. I'm against removing snapshot's
own qgroup.
At a minimum, it should belong to _some_ qgroup. This could also be
covered by having a designated 'default' qgroup that all new
subvolumes created without a specified qgroup get put in, but I feel
that that is somewhat orthogonal to the issue of how snapshots are
handled.
It belongs to its own 0/N' qgroup, but this is not probably what you mean.
--
With Best Regards,
Marat Khalili
--
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
