Data Domain: A replicação de MTree mostra Bytes_remaining incorreta durante a inicialização

A replicação de MTree mostra bytes incorretos durante o processo de inicialização para MTREEs antigos que nunca foram usados durante a replicação.

The following MTREE has been used [# mtree list]:
/data/col1/support           5965.4   RW

As estatísticas mostram 92 TB de dados restantes após a criação de uma nova replicação de MTree usando as etapas acima:

# replication show detailed-stats rctx://1

CTX:1
Destination:                               
mtree://dd-dr.support.com/data/col1/support
Network bytes sent to destination:          2,287,577,928
Pre-compressed bytes written to source:     92,046,090,413,266
Pre-compressed bytes sent to destination:   2,860,770,559
Bytes after synthetic optimization:         2,860,770,559
Bytes after filtering by destination:       2,253,845,068
Bytes after low bandwidth optimization:     2,253,845,068
Bytes after local compression:              2,258,791,288
Pre-compressed bytes remaining:             92,043,229,642,707   <----
Compression ratio:                          1.3
Sync'ed-as-of time:                         (initializing)

Embora as chaves de registro subjacentes mostrem bytes mais precisos:

repl.001.src_host = dd-prod.support.com
repl.001.src_path = /data/col1/support
repl.001.dst_host = dd-dr.support.com
repl.001.dst_path = /data/col1/support
repl.001.progress.task_name = initializing 3/3
repl.001.progress.init_vbytes = 5991145719813   <---

De ddfs.info:
A estimativa inicial de bytes virtuais parece OK:

09/21 10:58:45.157 (tid 0x2b0e208796e0): repl ctx 1: mrepl_create_init_snap creating initial snapshot.
09/21 10:58:48.068 (tid 0x2b0e208796e0): repl ctx 1: estimating init vbytes as 5991145719813
09/21 10:58:48.995 (tid 0x2b0e208796e0): repl ctx 1: Using init_resync_snapid 1433317767:1886. Total snap count = 2, curent snap cnt = 0.

Após alguns minutos, o curso normal de mrepl_sends Começa a aparecer:

09/21 11:19:04.136 (tid 0x327e760): repl ctx 1:3: mrepl_send_file: file 30:0:ac66:0:a30e9f46:556eb187:1d74 took 218 sec, net throughput 297 KB/s, virtual throughput 290 KB/s, refs_sent 7575, refs_features_sent 0, segs_sent 0, segs_features_sent 7575, size 63416832, vbytes 63416832, nbytes 64858812 (recid 361) (ch-xor 0x98f3c7e9) (hole_seen FALSE)
09/21 11:19:59.031 (tid 0x2b0e2083cde0): repl ctx 1:16: mrepl_send_file: file 30:0:ac68:0:fccc10a6:556eb187:1d74 took 237 sec, net throughput 286 KB/s, virtual throughput 280 KB/s, refs_sent 7908, refs_features_sent 0, segs_sent 0, segs_features_sent 7908, size 66419200, vbytes 66419200, nbytes 67938672 (recid 363) (ch-xor 0x462a1211) (hole_seen FALSE)

A próxima ocorrência de vbytes_remain mostra um tamanho diferente:

09/21 11:28:02.246 (tid 0x2b0e096ba050): repl ctx 1: mrepl_stats_local: vbytes_remain: 92036838018199

É assim que a replicação é projetada para calcular os bytes lógicos restantes. Essa disparidade é observada sempre que o usuário começa a replicar algum MTree mais antigo. No entanto, isso não indica que a replicação de MTree replica esses dados, ela apenas replica o tamanho atual do MTree, conforme indicado por init_vbytes_remain. 

Quando a fase de inicialização terminar, redefina vbytes_remain para 0 e também atualizar vbytes_written_and_replicated com o cum_raw_bytes Assim, os backups subsequentes não mostram estatísticas irrealistas, em vez disso, relatam apenas os novos dados que são ingeridos.