----- Original Message -----
From: "Matthew Ahrens" <mahr...@delphix.com>
snip.
How did you generate the send stream? Please include the exact command you
used.
zfs send -R zfs/ROOT@auto-2014-09-19_22.30 >test.zfs
How big is the send stream?
1.7G
Can you provide the send stream?
http://blog.multiplay.co.uk/dropzone/freebsd/test.zfs.gz
What is the output of "zfs recv"? Does it fail?
No output, succeeds without issue.
What is the "freeing" property?
0
What is the "leaked" property?
0
If you write to the pool (before it runs completely out of space), does the
free space jump back up to where it should be?
Nope
I tried a simple test on my system, sending one pool to another and
receiving with the flags you mentioned (on DelphixOS, which is not too
different from illumos trunk) and the problem did not reproduce. After the
receive, the pool is idle (no i/o observed with iostat, no change to "free"
property).
Thanks Matt be interested to see of the steam file above changes that.
I took a look at the pool image you linked. The "leaked" space is consumed
by deferred frees (zdb -bb will tell you this). My first guess would be
that something is causing us to not process the deferred free list when we
should. i.e. spa_sync() is not calling spa_sync_deferred_frees(), but it
is subsequently syncing real changes to disk and adding more deferred
frees. This code looks somewhat fragile -- we are essentially checking
"will there be changes this txg", but the answer is not enforced. There
were some changes to dsl_scan_active() as part of the commit you mentioned,
which could be involved.
The limited tests I did last night after finding the problem revision seem to
agree
with that as dtrace was showing that without this revision dsl_scan_sync was
always processing the same txg but with it txg was continually incrementing e.g.
dtrace -n 'dsl_scan_sync:entry {printf("%lu < %lu", ((dsl_pool_t *)arg0)->dp_scan->scn_restart_txg, ((dmu_tx_t *)arg1)->tx_txg);}'
dtrace: description 'dsl_scan_sync:entry ' matched 1 probe
CPU ID FUNCTION:NAME
20 36713 dsl_scan_sync:entry 0 < 485
20 36713 dsl_scan_sync:entry 0 < 485
20 36713 dsl_scan_sync:entry 0 < 485
20 36713 dsl_scan_sync:entry 0 < 485
20 36713 dsl_scan_sync:entry 0 < 485
20 36713 dsl_scan_sync:entry 0 < 485
20 36713 dsl_scan_sync:entry 0 < 486
20 36713 dsl_scan_sync:entry 0 < 486
20 36713 dsl_scan_sync:entry 0 < 486
20 36713 dsl_scan_sync:entry 0 < 486
20 36713 dsl_scan_sync:entry 0 < 487
20 36713 dsl_scan_sync:entry 0 < 487
20 36713 dsl_scan_sync:entry 0 < 487
20 36713 dsl_scan_sync:entry 0 < 487
20 36713 dsl_scan_sync:entry 0 < 487
20 36713 dsl_scan_sync:entry 0 < 487
15 36713 dsl_scan_sync:entry 0 < 488
15 36713 dsl_scan_sync:entry 0 < 488
15 36713 dsl_scan_sync:entry 0 < 488
15 36713 dsl_scan_sync:entry 0 < 488
_______________________________________________
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
