Bug #6562
Refquota on receive doesn't account for overage
Status:
Closed
Priority:
Normal
Assignee:
-
Category:
zfs - Zettabyte File System
Start date:
2016-01-18
Due date:
% Done:
100%
Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Description
During acceptance testing of #4986, this pattern was discovered:
- 1. Create a filesystem.
- 2. Set a refquota.
- 3. Snapshot the filesystem.
- 4. Send a replication stream to a new filesystem.
- 5. On the original filesystem, fill it up to its quota.
- 6. Snapshot the original filesystem again.
- 7. Send an incremental stream to the same new filesystem.
What happens is that there's an overage on quota enforcement, limited by the size of a transaction. The idea was that ALL of the quota bytes would be available, even if it went over.
This is fine, until receipt of a replication stream occurs.
In the case of a change to an existing dataset, like above, there's a straightforward fix involving the reality checks around the final clone_swap paths in dsl_dataset.c.
In the case of a test like this, however:
- 1. Create a filesystem.
- 2. Set a refquota.
- 3. On the original filesystem, fill it up to its quota.
- 4. Snapshot the original filesystem.
- 5. Send a full replication stream to a new filesystem.
The send will happen, BUT the refquota property will not be received.
Related issues
History
Updated by Electric Monk almost 4 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
git commit 5f7a8e6d750cb070a3347f045201c6206caee6aa
commit 5f7a8e6d750cb070a3347f045201c6206caee6aa Author: Dan McDonald <danmcd@omniti.com> Date: 2016-02-09T19:37:16.000Z 6562 Refquota on receive doesn't account for overage Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com> Reviewed by: Toomas Soome <tsoome@me.com> Approved by: Gordon Ross <gwr@nexenta.com>
Updated by Michael Mounteney over 2 years ago
- Related to Bug #7998: zfs volumes sometimes grow on copying added