Question about Replication

[phillxnet (Philip Guyton)]

@m1dori Hello again.
Re:

@m1dori

However, note how the second larger share still has a snapshot share, is this just because it is taking time to process the snapshot and extract it to the destination share?

Pretty much yes. But more specifically it’s down to our replication taking 5 replication events (from memory) to settle down into it’s stable state. We keep the last 3 I think it is and so once the 5th event has taken place you should no longer see these strange .snapshot shares appearing. It’s a bit messy on our part but the replication subsystem is non trivial so does take time and attention which we are often short in. But in time these rougue shares should no longer be surfaced. An attempt was made to hide them but it failure and represents an aesthetic bug of sorts.

@m1dori

I noticed that the snapshot for the m1dori share has disappeared.

Yes, that one likely has now settled and so now only has 3 snapshots (I think it is) in it’s origin. And no odd .snapshot ones.

@m1dori

The other question is, when there is a change to the file system, and a replication task is started, I assume it will only process the new items in the share for replication?

Correct. Only the changes are transmitted. Hence the need to keep consistency on both sides and that it only works in one direction. Btrfs knows what block on disk have changed between the two snapshots (once just taken and the last one used in the send). And will send the change at the block level (or btrfs’s equivalent).

@m1dori

UPDATE 1: I want to add, now the .snapshot has gone away but no data is in the replication share.

OK, so that last replication (btrfs send) event managed to reach the stable state of 5 repititions (replication sends). So our strange surfacing bug on these snapshots no longer shows these share/subvols-by-a-strange-name.

@m1dori

UPDATE 2: Okay, so I see that the reason it states 0, is because quota size is disabled

Yes, quotas has been super expensive in the past, getting better all the time - but only gradually. I think modern kernels are now quite workable in btrfs with quota enabled. Plus we don’t yet fully report quotas as well as we could. But all in good time.

@m1dori

This however, cannot be turned back on. I have tried multiple times and it keeps defaulting to disabled.

You will likely have to enable it via the command line. We have seen this happen before - and may be related to imported pools - or a hack we had to put in way back that is still there re enabling quotas twice as once wasn’t enough at one point !! So look to enabling quotas on the pool via the command line. There after you should be able to disable/re-enable via the Web-UI.

@m1dori

The share seems to have properly replicated however.

Sorted.

Thanks for the full length test/report here. What version/channel of Rockstor (and what OS base) are you currently seeing this all on incidentally?