[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command |
Date: |
Tue, 21 May 2013 12:36:33 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 |
Il 21/05/2013 12:34, Stefan Hajnoczi ha scritto:
> On Tue, May 21, 2013 at 10:30:22AM +0200, Paolo Bonzini wrote:
>> Il 21/05/2013 09:31, Stefan Hajnoczi ha scritto:
>>> On Mon, May 20, 2013 at 09:23:43AM +0200, Paolo Bonzini wrote:
>>>> Il 20/05/2013 08:24, Stefan Hajnoczi ha scritto:
>>>>>>> You only need to fdatasync() before every guest flush, no?
>>>>> No, you need to set the dirty bit before issuing the write on the
>>>>> host. Otherwise the image data may be modified without setting the
>>>>> appropriate dirty bit. That would allow data modifications to go
>>>>> undetected!
>>>>
>>>> But data modifications can go undetected until the guest flush returns,
>>>> can't they?
>>>
>>> You are thinking about it from the guest perspective - if a flush has
>>> not completed yet then there is no guarantee that the write has reached
>>> disk.
>>>
>>> But from a host perspective the dirty bitmap should be conservative so
>>> that the backup application can always restore a bit-for-bit identical
>>> copy of the disk image. It would be weird if writes can sneak in
>>> unnoticed.
>>
>> True, but that would happen only in case the host crashes. Even for a
>> QEMU crash the changes would be safe, I think. They would be written
>> back when the persistent dirty bitmap's mmap() area is unmapped, during
>> process exit.
>
> I'd err on the side of caution, mark the persistent dirty bitmap while
> QEMU is running. Discard the file if there was a power failure.
Agreed. Though this is something that management must do manually,
isn't it? QEMU cannot distinguish a SIGKILL from a power failure, while
management can afford treating SIGKILL as a power failure.
> It really depends what the dirty bitmap users are doing. It could be
> okay to have a tiny chance of missing a modification but it might not.
Paolo
- Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command, (continued)
- Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command, Paolo Bonzini, 2013/05/17
- Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command, Stefan Hajnoczi, 2013/05/20
- Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command, Paolo Bonzini, 2013/05/20
- Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command, Stefan Hajnoczi, 2013/05/21
- Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command, Paolo Bonzini, 2013/05/21
- Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command, Stefan Hajnoczi, 2013/05/21
- Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command,
Paolo Bonzini <=
- Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command, Dietmar Maurer, 2013/05/21
- Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command, Stefan Hajnoczi, 2013/05/22
- Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command, Dietmar Maurer, 2013/05/22
- Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command, Dietmar Maurer, 2013/05/22
- Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command, Stefan Hajnoczi, 2013/05/23
- Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command, Dietmar Maurer, 2013/05/23
- Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command, Stefan Hajnoczi, 2013/05/24
- Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command, Dietmar Maurer, 2013/05/24