On Thu, Apr 08, 2010 at 06:36:15PM +0300, Avi Kivity wrote:
> Shouldn't it do that then? What's the point of fsyncing guest data if
> qcow2 metadata is volatile?
Not my territory - but in the end getting qcow2 as-is solid in face
of crashes will be an uphill battel - I'd rather recommend not us
On 04/08/2010 06:34 PM, Christoph Hellwig wrote:
On Thu, Apr 08, 2010 at 06:28:54PM +0300, Avi Kivity wrote:
When it updates qcow2 metadata or when the guest issues a barrier. It's
relatively new. I have a patch that introduces cache=volatile somewhere.
qcow2 does not issues any fsy
On Thu, Apr 08, 2010 at 06:28:54PM +0300, Avi Kivity wrote:
> When it updates qcow2 metadata or when the guest issues a barrier. It's
> relatively new. I have a patch that introduces cache=volatile somewhere.
qcow2 does not issues any fsyncs by itself, it only passes throught the
guests ones.
On Thu, Apr 08, 2010 at 06:28:54PM +0300, Avi Kivity wrote:
> On 04/08/2010 06:26 PM, Chris Mason wrote:
> >>
> >>>Once the O_DIRECT read patch is in, you can switch to that, or tell qemu
> >>>to use a writeback cache instead.
> >>Even with writeback qemu will issue a lot of fsyncs.
> >Oh, I didn't
On Thu, Apr 08, 2010 at 11:26:15AM -0400, Chris Mason wrote:
> With O_DIRECT the writeback rates are very reasonable. I'll work up a
> way to pass the barrier down from the guest to btrfs to force logging of
> updated metadata when required.
Barriers are implemented in the guest kernel using queu
On 04/08/2010 06:26 PM, Chris Mason wrote:
Once the O_DIRECT read patch is in, you can switch to that, or tell qemu
to use a writeback cache instead.
Even with writeback qemu will issue a lot of fsyncs.
Oh, I didn't see that when I was testing, when does it fsync?
When it
On Thu, Apr 08, 2010 at 05:58:17PM +0300, Avi Kivity wrote:
> On 03/30/2010 03:56 PM, Chris Mason wrote:
> >On Sun, Mar 28, 2010 at 05:18:03PM +0200, Diego Calleja wrote:
> >>Hi, I'm using KVM, and the virtual disk (a 20 GB file using the "raw"
> >>qemu format according to virt-manager and, of cour
Avi Kivity wrote:
On 03/30/2010 03:56 PM, Chris Mason wrote:
On Sun, Mar 28, 2010 at 05:18:03PM +0200, Diego Calleja wrote:
Hi, I'm using KVM, and the virtual disk (a 20 GB file using the "raw"
qemu format according to virt-manager and, of course, placed on a btrfs
filesystem, running the la
On 03/30/2010 03:56 PM, Chris Mason wrote:
On Sun, Mar 28, 2010 at 05:18:03PM +0200, Diego Calleja wrote:
Hi, I'm using KVM, and the virtual disk (a 20 GB file using the "raw"
qemu format according to virt-manager and, of course, placed on a btrfs
filesystem, running the latest mainline git)
On Sun, Mar 28, 2010 at 05:18:03PM +0200, Diego Calleja wrote:
> Hi, I'm using KVM, and the virtual disk (a 20 GB file using the "raw"
> qemu format according to virt-manager and, of course, placed on a btrfs
> filesystem, running the latest mainline git) is awfully slow, no matter
> what OS is run
>Hi, I'm using KVM, and the virtual disk (a 20 GB file using the "raw"
>qemu format according to virt-manager and, of course, placed on a btrfs
>filesystem, running the latest mainline git) is awfully slow, no matter
>what OS is running inside the VM. The PCBSD installer says it's copying
>data at
Hi, I'm using KVM, and the virtual disk (a 20 GB file using the "raw"
qemu format according to virt-manager and, of course, placed on a btrfs
filesystem, running the latest mainline git) is awfully slow, no matter
what OS is running inside the VM. The PCBSD installer says it's copying
data at a 40-
12 matches
Mail list logo
