@stevenburgess Good sanity check. It turns out that zfs_send_007_pos.ksh is
bugged; the `diff -r` needs a log_must statement, so it wasn't actually failing
the test if there was an error. Once I fixed the test, I discovered that you
guys are right; this patch doesn't fix the issue in all cases. I've found the
bug and am posting a fix for review internally. If you want to test it
yourself, the fix basically looks like this:
```
--- a/usr/src/uts/common/fs/zfs/dmu_traverse.c
+++ b/usr/src/uts/common/fs/zfs/dmu_traverse.c
@@ -231,8 +231,7 @@ traverse_visitbp(traverse_data_t *td, const dnode_phys_t
*dnp,
ASSERT(0);
}
- if (bp->blk_birth == 0 && (!td->td_realloc_possible ||
- zb->zb_object == DMU_META_DNODE_OBJECT)) {
+ if (bp->blk_birth == 0) {
/*
* Since this block has a birth time of 0 it must be one of two
* things: a hole created before the SPA_FEATURE_HOLE_BIRTH
@@ -255,7 +254,9 @@ traverse_visitbp(traverse_data_t *td, const dnode_phys_t
*dnp,
* Note that the meta-dnode cannot be reallocated, so we needn't
* worry about that case.
*/
- if (td->td_hole_birth_enabled_txg <= td->td_min_txg)
+ if ((!td->td_realloc_possible ||
+ zb->zb_object == DMU_META_DNODE_OBJECT) &&
+ td->td_hole_birth_enabled_txg <= td->td_min_txg)
return (0);
} else if (bp->blk_birth <= td->td_min_txg) {
return (0);
```
@sensille That sounds like it may or may not be a related issue. It might just
be that the filesystem has marked the files as "to be deleted" but hasn't
actually freed the space yet when you take the snapshot. I'd be a bit
surprised if it was actually fixed by this patch, and wasn't just a timing
issue, but I haven't tried reproducing it with and without this patch. Do you
have hole birth enabled? If so, when was it enabled?
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/37#issuecomment-173712185_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
