On Wed, 05/16 18:52, Vladimir Sementsov-Ogievskiy wrote:
> 16.05.2018 18:32, Kevin Wolf wrote:
> > Am 16.05.2018 um 17:10 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > > 16.05.2018 15:47, Kevin Wolf wrote:
> > > > Am 14.05.2018 um 12:09 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > > > >
16.05.2018 18:32, Kevin Wolf wrote:
Am 16.05.2018 um 17:10 hat Vladimir Sementsov-Ogievskiy geschrieben:
16.05.2018 15:47, Kevin Wolf wrote:
Am 14.05.2018 um 12:09 hat Vladimir Sementsov-Ogievskiy geschrieben:
14.05.2018 09:41, Fam Zheng wrote:
On Wed, 04/18 17:00, Vladimir
Am 16.05.2018 um 17:10 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 16.05.2018 15:47, Kevin Wolf wrote:
> > Am 14.05.2018 um 12:09 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > > 14.05.2018 09:41, Fam Zheng wrote:
> > > > On Wed, 04/18 17:00, Vladimir Sementsov-Ogievskiy wrote:
> > > > > Is
16.05.2018 15:47, Kevin Wolf wrote:
Am 14.05.2018 um 12:09 hat Vladimir Sementsov-Ogievskiy geschrieben:
14.05.2018 09:41, Fam Zheng wrote:
On Wed, 04/18 17:00, Vladimir Sementsov-Ogievskiy wrote:
Is it possible, that target will change the disk, and then we return control
to the source? In
Am 14.05.2018 um 12:09 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 14.05.2018 09:41, Fam Zheng wrote:
> > On Wed, 04/18 17:00, Vladimir Sementsov-Ogievskiy wrote:
> > > Is it possible, that target will change the disk, and then we return
> > > control
> > > to the source? In this case bitmaps
On Mon, 05/14 13:23, Vladimir Sementsov-Ogievskiy wrote:
> > So, you agree, that dropping all bitmaps after inactivation is good
> > idea.. The second question, is it possible to not drop them? Is there a
> > way, to check that disk was not changed after pair of
> > inactivate-invalidate? I have
14.05.2018 13:09, Vladimir Sementsov-Ogievskiy wrote:
14.05.2018 09:41, Fam Zheng wrote:
On Wed, 04/18 17:00, Vladimir Sementsov-Ogievskiy wrote:
Hi all.
We now have the following problem:
If dirty-bitmaps migration capability is enabled, persistance flag is
dropped for all migrated bitmaps,
14.05.2018 09:41, Fam Zheng wrote:
On Wed, 04/18 17:00, Vladimir Sementsov-Ogievskiy wrote:
Hi all.
We now have the following problem:
If dirty-bitmaps migration capability is enabled, persistance flag is
dropped for all migrated bitmaps, to prevent their storing to the storage on
inactivate.
12.05.2018 00:23, John Snow wrote:
On 04/18/2018 10:00 AM, Vladimir Sementsov-Ogievskiy wrote:
Hi all.
We now have the following problem:
If dirty-bitmaps migration capability is enabled, persistance flag is
dropped for all migrated bitmaps, to prevent their storing to the
storage on
On Wed, 04/18 17:00, Vladimir Sementsov-Ogievskiy wrote:
> Hi all.
>
> We now have the following problem:
>
> If dirty-bitmaps migration capability is enabled, persistance flag is
> dropped for all migrated bitmaps, to prevent their storing to the storage on
> inactivate.
Why do we prevent
On 04/18/2018 10:00 AM, Vladimir Sementsov-Ogievskiy wrote:
> Hi all.
>
> We now have the following problem:
>
> If dirty-bitmaps migration capability is enabled, persistance flag is
> dropped for all migrated bitmaps, to prevent their storing to the
> storage on inactivate. It works ok,
* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> Hi all.
>
> We now have the following problem:
>
> If dirty-bitmaps migration capability is enabled, persistance flag is
> dropped for all migrated bitmaps, to prevent their storing to the storage on
> inactivate. It works ok,
Hi all.
We now have the following problem:
If dirty-bitmaps migration capability is enabled, persistance flag is
dropped for all migrated bitmaps, to prevent their storing to the
storage on inactivate. It works ok, persistence itself is migrated
through the migration channel. But on source,
13 matches
Mail list logo
