On 2017-03-28 09:53, Marat Khalili wrote:
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?
If we were going to reserve something, it should be a high number, not a
low one. Having 0 reserved makes some sense, but reserving other low
numbers seems kind of odd when they aren't already reserved.
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.
The subvolume create command lets you set a specific qgroup on subvolume
creation. When I said it won't prevent assigning a specific qgroup, I
meant using that, not some after-the-fact assignment, although I hadn't
realized that the snapshot command _does not_ have this argument, when
it absolutely should.
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.
I mean if it's placed in that qgroup itself. If you create a snapshot
of an idle subvolume, you only effectively double the metadata (and
possibly not even that completely), so unless it's got a very large
number of small files, it should take up next to zero space if it gets
put in it's parent's qgroup.
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.
Perhaps have an option (in the filesystem, not the mount options, this
is tied to qgroup policy, which should be independent of who mounts the
FS where) that specifies one of:
1. Current behavior.
2. Join parent's qgroup.
3. Join some other predefined 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.
The 0/N groups are accounting only until some limit is set, correct? If
that is the case, then that really isn't what I mean. Quotas can be
used for accounting, but when used, they are often intended for
restricting resource usage. New subvolumes going into unrestricted
qgroups by default completely eliminates any usability for resource
restriction the moment anybody but the admin has any shell access to the
system, and that's my biggest complaint against the current behavior.
Putting a snapshot in it's parent's qgroup would completely close this
hole and provide semantics that most people are likely to understand
pretty easily.
--
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
