Currently, preferred content "balanced=groupname:lackingcopies" does not cause any repository in the balanced group to want to drop content even when there are more than enough copies.
("balanced=groupname:lackingcopies=grouplimit" also doesn't cause a drop)
Using --rebalance does make it want to drop.
Is this a good thing? If so, it needs to be documented. Or it could be changed to drop when there are more copies than necessary.
Internally, the reason this behavior happens is that "balanced=groupname:number" is the same as "(fullybalanced=groupname:number and not copies=groupname:number) or present" until --rebalance is used. And "balanced=groupname:lackingcopies" inherited that "or present".
The "or present" is important to avoid moving objects between repositories of a balanced group when not rebalancing. But, it's behaving more broadly here and keeping copies when there are enough copies outside the group.
Could it be changed to want to keep present copies where they are when there are not enough copies outside the balanced group, but otherwise want to drop from the balanced group?
I think that would entail making "balanced=groupname:lackingcopies" work the same as "fullybalanced=groupname:lackingcopies or (present and not lackingcopies=groupname:0)" --Joey
Gave up on this one, as not able to be implemented. done --Joey
I tried implementing this (patch below) and found that it made objects be moved amoung nodes of the balanced group to balance, despite --rebalance not being used.
This patch actually makes it like "(present and lackingcopies=1)" but that is equvilant to "(present and not lackingcopies=0)" .. I think?
I do think that "present and foo" will work, with the right "foo". I'm just having trouble coming up with it, and it may be that it's not expressible with current preferred content syntax.
What's needed is something that only matches when there are too many copies.
"lackingcopies=groupname:0" matches when there are too many or the desired numcopies, which is not quite right.
Hmm, this behavior is not limited to balanced lackingcopies. Eg "balanced=pool:2" will keep 3 copies if there are already 3, until --rebalance is used.
But in that case, the only way there can be 3 copies is if one is manually made. And one reason to manually make an extra copy might be when moving a file between two nodes of the pool, where it's copied to the new node first, and then dropped from the second. It seems that the user would not want a
git-annex syncrun in the middle of that process to undo their copy.And the documentation does mention that:
In the case of eg, "balanced=pool:lackingcopies=backup", a new backup repository could be set up, and get a copy of a file (backup repositories want all files). Then the file would have more copies in the pool than the expression wants it to have.
Is that different enough to justify a different behavior of dropping a copy from the pool? At this point, before balanced lackingcopies is in a release, it can be done without being a behavior change still. It would be harder to justify it as a later behavior change.
What about the similar situation with a manual move between nodes with balanced lackingcopies? It seems the same reasoning applies to that as to balanced copies.
But then, how to make it want to drop in the one case, and not in the other case?
Maybe better to leave this up to the user. They could use eg "balanced=pool:lackingcopies=backup and not excesscopies=pool+backup=1" if excesscopies were implemented. Sadly, I failed to implement it, see e962788bd46eddf8c5a4b2ae96d5fab7298f1cca
Anyway, with no way to implement excesscopies, I don't think balanced lackingcopies can drop either. So this todo seems unable to be implemented.