Data Domain: La replicación de MTree muestra un Bytes_remaining incorrecto durante la inicialización

En la replicación de MTree, se muestran bytes incorrectos durante el proceso de inicialización de los MTree antiguos que nunca se utilizaron durante la replicación.

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

Las estadísticas muestran 92 TB de datos restantes después de crear una nueva replicación de MTree mediante los pasos anteriores:

# 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)

Mientras que las claves de registro subyacentes muestran bytes más 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   <---

En ddfs.info:
La estimación inicial de bytes virtuales se ve bien:

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.

Después de un par de minutos, el curso normal de mrepl_sends Comienza 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)

La siguiente instancia de vbytes_remain Muestra un tamaño diferente:

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

Así es como la replicación está diseñada para calcular los bytes lógicos restantes. Esta incompatibilidad se observa cada vez que el usuario comienza a replicar algún MTree antiguo. Sin embargo, esto no indica que la replicación de MTree replique esto de los datos, solo replica el tamaño actual del MTree, como lo indica el init_vbytes_remain. 

Una vez finalizada la fase de inicialización, restablezca vbytes_remain a 0 y también actualizar vbytes_written_and_replicated Con el cum_raw_bytes Por lo tanto, los respaldos posteriores no muestran estadísticas poco realistas, sino que informan solo los datos nuevos que se recopilan.