Kangurek wrote:
Thanks for info.
My idea was to traverse changing filesystem, now I see that it will not
work.
I will try to traverse snapshots. Zreplicate will:
1. do snapshot @replicate_leatest and
2. send data to snapshot @replicate_leatest
3. wait X sec ( X = 20 )
4. remove
Matthew Ahrens wrote On 03/24/07 12:13,:
Kangurek wrote:
Thanks for info.
My idea was to traverse changing filesystem, now I see that it will
not work.
I will try to traverse snapshots. Zreplicate will:
1. do snapshot @replicate_leatest and
2. send data to snapshot @replicate_leatest
3.
Neil Perrin wrote:
I'm not sure exactly what will be slow about taking snapshots, but one
aspect might be that we have to suspend the intent log (see call to
zil_suspend() in dmu_objset_snapshot_one()). I've been meaning to
change that for a while now -- just let the snapshot have the
Matthew Ahrens wrote On 03/24/07 12:36,:
Neil Perrin wrote:
I'm not sure exactly what will be slow about taking snapshots, but
one aspect might be that we have to suspend the intent log (see call
to zil_suspend() in dmu_objset_snapshot_one()). I've been meaning to
change that for a while
How it got that way, I couldn't really say without looking at your code.
It works like this:
In new ioctl operation
zfs_ioc_replicate_send(zfs_cmd_t *zc)
we open filesystem ( not snapshot )
dmu_objset_open(zc-zc_name, DMU_OST_ANY,
DS_MODE_STANDARD |
Łukasz wrote:
How it got that way, I couldn't really say without looking at your code.
It works like this:
...
we set max_txg
ba.max_txg = (spa_get_dsl(filesystem-os-os_spa))-dp_tx.tx_synced_txg;
So, how do you send the initial stream? Presumably you need to do it
with ba.max_txg = 0?
