> On 01/11/2013 05:34 PM, Paolo Bonzini wrote:
> > It is always true for the protocol. It is not always true for the
> > format.
>
> So you mean bdrv_enable_write_cache() always return true for Sheepdog
> at any time?
Yes, at least now. You could in principle have a format that calls
bdrv_set_e
On 01/11/2013 05:34 PM, Paolo Bonzini wrote:
> It is always true for the protocol. It is not always true for the format.
>
So you mean bdrv_enable_write_cache() always return true for Sheepdog at
any time?
Thanks,
Yuan
- Messaggio originale -
> Da: "Liu Yuan"
> A: "Paolo Bonzini"
> Cc: "Kevin Wolf" , "Stefan Hajnoczi" ,
> qemu-devel@nongnu.org, "MORITA Kazutaka"
>
> Inviato: Venerdì, 11 gennaio 2013 10:04:23
> Oggetto: Re: [Qe
Am 11.01.2013 08:52, schrieb MORITA Kazutaka:
> At Thu, 10 Jan 2013 13:38:16 +0800,
> Liu Yuan wrote:
>>
>> On 01/09/2013 11:10 PM, Paolo Bonzini wrote:
>>> Il 09/01/2013 14:04, Liu Yuan ha scritto:
>> 2 The upper layer software which relies on the 'cache=xxx' to choose
>> cache mode will
On 01/11/2013 05:00 PM, Paolo Bonzini wrote:
> That's not correct. Try hdparm with an IDE disk, or sysfs with a SCSI
> disk (recent kernels will also support sysfs with an IDE or virtio-blk
> disk) and you'll see that it changes.
Okay, at least at startup, even with cache=writehtough set, I saw
b
> bdrv_enable_write_cache() is always
> true for now, I guess this need generic change block layer to get the
> writethrough/writeback hints.
That's not correct. Try hdparm with an IDE disk, or sysfs with a SCSI
disk (recent kernels will also support sysfs with an IDE or virtio-blk
disk) and you'
On 01/11/2013 03:52 PM, MORITA Kazutaka wrote:
> At Thu, 10 Jan 2013 13:38:16 +0800,
> Liu Yuan wrote:
>>
>> On 01/09/2013 11:10 PM, Paolo Bonzini wrote:
>>> Il 09/01/2013 14:04, Liu Yuan ha scritto:
>> 2 The upper layer software which relies on the 'cache=xxx' to choose
>> cache mode wil
At Thu, 10 Jan 2013 13:38:16 +0800,
Liu Yuan wrote:
>
> On 01/09/2013 11:10 PM, Paolo Bonzini wrote:
> > Il 09/01/2013 14:04, Liu Yuan ha scritto:
> 2 The upper layer software which relies on the 'cache=xxx' to choose
> cache mode will fail its assumption against new QEMU.
> >>>
> >>>
Paolo Bonzini wrote:
> Il 10/01/2013 16:25, Jamie Lokier ha scritto:
> >> > Perhaps it's a bug that the cache mode is not reset when the machine is
> >> > reset. I haven't checked that, but it would be a valid complaint.
> > The question is, is cache=writeback/cache=writethrough an initial
> > set
Il 10/01/2013 16:25, Jamie Lokier ha scritto:
>> > Perhaps it's a bug that the cache mode is not reset when the machine is
>> > reset. I haven't checked that, but it would be a valid complaint.
> The question is, is cache=writeback/cache=writethrough an initial
> setting of guest-visible WCE that
Paolo Bonzini wrote:
> Il 09/01/2013 14:04, Liu Yuan ha scritto:
> > > > 2 The upper layer software which relies on the 'cache=xxx' to choose
> > > > cache mode will fail its assumption against new QEMU.
> > >
> > > Which assumptions do you mean? As far as I can say the behaviour hasn't
> > > ch
Am 10.01.2013 16:12, schrieb Jamie Lokier:
> Kevin Wolf wrote:
>> Am 08.01.2013 11:39, schrieb Liu Yuan:
>>> On 01/08/2013 06:00 PM, Kevin Wolf wrote:
Am 08.01.2013 10:45, schrieb Liu Yuan:
> On 01/08/2013 05:40 PM, Stefan Hajnoczi wrote:
>> Otherwise use sheepdog writeback and let QEM
Kevin Wolf wrote:
> Am 08.01.2013 11:39, schrieb Liu Yuan:
> > On 01/08/2013 06:00 PM, Kevin Wolf wrote:
> >> Am 08.01.2013 10:45, schrieb Liu Yuan:
> >>> On 01/08/2013 05:40 PM, Stefan Hajnoczi wrote:
> Otherwise use sheepdog writeback and let QEMU block.c decide when to
> flush. Never
On 01/09/2013 11:10 PM, Paolo Bonzini wrote:
> Il 09/01/2013 14:04, Liu Yuan ha scritto:
2 The upper layer software which relies on the 'cache=xxx' to choose
cache mode will fail its assumption against new QEMU.
>>>
>>> Which assumptions do you mean? As far as I can say the behaviour ha
Il 09/01/2013 14:04, Liu Yuan ha scritto:
> > > 2 The upper layer software which relies on the 'cache=xxx' to choose
> > > cache mode will fail its assumption against new QEMU.
> >
> > Which assumptions do you mean? As far as I can say the behaviour hasn't
> > changed, except possibly for the pe
On 01/09/2013 08:42 PM, Kevin Wolf wrote:
> Am 09.01.2013 13:07, schrieb Liu Yuan:
>> Besides performance, I think backward compatibility is more important:
>> 1 if we run a old kernel host (quite possible for a long running
>> server) which doesn't support WCE, then we will never have a chance t
Am 09.01.2013 13:07, schrieb Liu Yuan:
> Besides performance, I think backward compatibility is more important:
> 1 if we run a old kernel host (quite possible for a long running
> server) which doesn't support WCE, then we will never have a chance to
> choose writethrough cache for guest OS agai
On 01/09/2013 08:07 PM, Liu Yuan wrote:
> and my proposal (adding another field to BlockDriverState to allow
> self-interpretation cache flag) can work well with current block layer:
>
> Sheepdog driver behavior:
>cache flagsWCE toggled and resulting behavior
>writethrough
On 01/09/2013 08:07 PM, Liu Yuan wrote:
> $ qemu-system-x86_64 --enable-kvm -drive
> file=~/images/test1,if=virtio,cache=writeback -smp 2 -cpu host -m 1024
> -drive file=sheepdog:test,if=virtio,cache=writeback
To emulate old impl, I modified the sheepdog block driver as following:
diff --git a/bl
On 01/09/2013 06:46 PM, Liu Yuan wrote:
>> 1) how slower is QEMU's emulated-writethrough mode for writes, due to
>> > the extra requests?
>> >
> I'll collect some numbers on it.
>
Okay I got some nubmers. I run three sheep daemon on the same host to
emulate a 3 nodes cluster, Sheepdog image has
Il 09/01/2013 11:58, Liu Yuan ha scritto:
> On 01/09/2013 06:46 PM, Liu Yuan wrote:
>> I'll collect some numbers on it.
>
> Well, when I use hdparm -W 0 /dev/vdx to choose the writethrough cache
> in the Guest (virtio disk), it says:
>
> test@vm1:~$ sudo hdparm -W 0 /dev/vdb
>
> /dev/vdb:
> set
Am 09.01.2013 11:36, schrieb Liu Yuan:
> On 01/09/2013 06:25 PM, Paolo Bonzini wrote:
>> But why is it useful to force-disable writeback caching? Do you have
>> any performance numbers?
>
> This is not related to performance. What I want is to allow users to
> choose Sheepdog cache mode (writethr
On 01/09/2013 06:46 PM, Liu Yuan wrote:
> I'll collect some numbers on it.
Well, when I use hdparm -W 0 /dev/vdx to choose the writethrough cache
in the Guest (virtio disk), it says:
test@vm1:~$ sudo hdparm -W 0 /dev/vdb
/dev/vdb:
setting drive write-caching to 0 (off)
HDIO_DRIVE_CMD(identify)
On 01/09/2013 06:40 PM, Paolo Bonzini wrote:
> 1) how slower is QEMU's emulated-writethrough mode for writes, due to
> the extra requests?
>
I'll collect some numbers on it.
> 2) how slower is QEMU's writeback mode for reads, due to the different
> structure of the cache?
Sorry, I don't get you
Il 09/01/2013 11:36, Liu Yuan ha scritto:
>> But why is it useful to force-disable writeback caching? Do you have
>> > any performance numbers?
> This is not related to performance. What I want is to allow users to
> choose Sheepdog cache mode (writethrough/writeback/directio) from cache=xxx.
>
>
On 01/09/2013 06:25 PM, Paolo Bonzini wrote:
> But why is it useful to force-disable writeback caching? Do you have
> any performance numbers?
This is not related to performance. What I want is to allow users to
choose Sheepdog cache mode (writethrough/writeback/directio) from cache=xxx.
Obvious
Il 08/01/2013 14:18, Liu Yuan ha scritto:
> Maybe not for a second thought. See following combination:
>
>cache flagsWCE toggled and resulting behavior
>writethrough writethrough
>writeback writetrhough (writeback + flush as expected)
>
> cache flags
Il 08/01/2013 13:12, Kevin Wolf ha scritto:
>> > Okay, I see the code indeed support WCE but it requires Guest kernel to
>> > support it. For the kernel doesn't support it, there is no way to
>> > disable write cache, no?
> With Linux guests, it's possible for SCSI. I'm not sure about
> virtio-blk,
On 01/08/2013 09:18 PM, Liu Yuan wrote:
> So the result is *not* broken. If we set cache=writethrough for
> sheepdog, then WCE won't take any effect because 'flush' request will be
> ignored by Sheepdog driver.
The merit of this 'writethrough' is that, write request will never be
interpreted as t
On 01/08/2013 08:12 PM, Kevin Wolf wrote:
> Ok, thanks. It would be good if it was before the hard freeze for 1.4.
>
Oops, sorry. It is a false alarm. Last time I was running latest QEMU on
tmpfs which service the request too fast.
> It seems it is hard to restore into old seman
Am 08.01.2013 12:35, schrieb Liu Yuan:
> On 01/08/2013 07:19 PM, Kevin Wolf wrote:
>> I can't see a reason why it would do that. Can you bisect this?
>>
>
> Sure, bisect it is on my schedule, but I can't promise a deadline.
Ok, thanks. It would be good if it was before the hard freeze for 1.4.
>
On 01/08/2013 07:19 PM, Kevin Wolf wrote:
> I can't see a reason why it would do that. Can you bisect this?
>
Sure, bisect it is on my schedule, but I can't promise a deadline.
>>> It seems it is hard to restore into old semantics of cache flags due to
>>> new design of QEMU block laye
Am 08.01.2013 12:08, schrieb Liu Yuan:
> On 01/08/2013 06:51 PM, Kevin Wolf wrote:
>> Am 08.01.2013 11:39, schrieb Liu Yuan:
>>> This also explains why
>>> I saw a regression about write performance: Old QEMU can issue multiple
>>> write requests in one go, but now the requests are sent one by one
On 01/08/2013 06:51 PM, Kevin Wolf wrote:
> Am 08.01.2013 11:39, schrieb Liu Yuan:
>> On 01/08/2013 06:00 PM, Kevin Wolf wrote:
>>> Am 08.01.2013 10:45, schrieb Liu Yuan:
On 01/08/2013 05:40 PM, Stefan Hajnoczi wrote:
> Otherwise use sheepdog writeback and let QEMU block.c decide when to
>
Am 08.01.2013 11:39, schrieb Liu Yuan:
> On 01/08/2013 06:00 PM, Kevin Wolf wrote:
>> Am 08.01.2013 10:45, schrieb Liu Yuan:
>>> On 01/08/2013 05:40 PM, Stefan Hajnoczi wrote:
Otherwise use sheepdog writeback and let QEMU block.c decide when to
flush. Never use sheepdog writethrough beca
On 01/08/2013 06:00 PM, Kevin Wolf wrote:
> Am 08.01.2013 10:45, schrieb Liu Yuan:
>> On 01/08/2013 05:40 PM, Stefan Hajnoczi wrote:
>>> Otherwise use sheepdog writeback and let QEMU block.c decide when to
>>> flush. Never use sheepdog writethrough because it's redundant here.
>>
>> I don't get it
Am 08.01.2013 10:45, schrieb Liu Yuan:
> On 01/08/2013 05:40 PM, Stefan Hajnoczi wrote:
>> Otherwise use sheepdog writeback and let QEMU block.c decide when to
>> flush. Never use sheepdog writethrough because it's redundant here.
>
> I don't get it. What do you mean by 'redundant'? If we use vir
On 01/08/2013 05:40 PM, Stefan Hajnoczi wrote:
> Otherwise use sheepdog writeback and let QEMU block.c decide when to
> flush. Never use sheepdog writethrough because it's redundant here.
I don't get it. What do you mean by 'redundant'? If we use virtio &
sheepdog block driver, how can we specify
On Tue, Jan 08, 2013 at 01:42:35PM +0800, Liu Yuan wrote:
> On 01/07/2013 09:23 PM, Kevin Wolf wrote:
> > No, and in theory they shouldn't have to care.
> >
> > Why do you want to handle writethrough semantics in the block driver
> > rather than letting qemu care for sending the right flushes?
>
On 01/07/2013 09:23 PM, Kevin Wolf wrote:
> No, and in theory they shouldn't have to care.
>
> Why do you want to handle writethrough semantics in the block driver
> rather than letting qemu care for sending the right flushes?
Because Sheepdog itself provide the client side cache implementation a
On 01/07/2013 08:31 PM, Stefan Hajnoczi wrote:
> On Sat, Jan 05, 2013 at 03:56:11PM +0800, Liu Yuan wrote:
>> On 01/05/2013 01:29 PM, Liu Yuan wrote:
>>> On 01/05/2013 12:40 PM, Liu Yuan wrote:
On 01/05/2013 12:38 AM, Stefan Hajnoczi wrote:
> Hi Yuan,
> BDRV_O_NOCACHE means bypass host
Am 05.01.2013 08:56, schrieb Liu Yuan:
> On 01/05/2013 01:29 PM, Liu Yuan wrote:
>> On 01/05/2013 12:40 PM, Liu Yuan wrote:
>>> On 01/05/2013 12:38 AM, Stefan Hajnoczi wrote:
Hi Yuan,
BDRV_O_NOCACHE means bypass host page cache (O_DIRECT).
BDRV_O_CACHE_WB specifies the cache sem
On Sat, Jan 05, 2013 at 03:56:11PM +0800, Liu Yuan wrote:
> On 01/05/2013 01:29 PM, Liu Yuan wrote:
> > On 01/05/2013 12:40 PM, Liu Yuan wrote:
> >> On 01/05/2013 12:38 AM, Stefan Hajnoczi wrote:
> >>> Hi Yuan,
> >>> BDRV_O_NOCACHE means bypass host page cache (O_DIRECT).
> >>>
> >>> BDRV_O_CACHE_W
On 01/05/2013 01:29 PM, Liu Yuan wrote:
> On 01/05/2013 12:40 PM, Liu Yuan wrote:
>> On 01/05/2013 12:38 AM, Stefan Hajnoczi wrote:
>>> Hi Yuan,
>>> BDRV_O_NOCACHE means bypass host page cache (O_DIRECT).
>>>
>>> BDRV_O_CACHE_WB specifies the cache semantics that the guest sees - that
>>> means whe
On 01/05/2013 12:40 PM, Liu Yuan wrote:
> On 01/05/2013 12:38 AM, Stefan Hajnoczi wrote:
>> Hi Yuan,
>> BDRV_O_NOCACHE means bypass host page cache (O_DIRECT).
>>
>> BDRV_O_CACHE_WB specifies the cache semantics that the guest sees - that
>> means whether the disk cache is writethrough or writeback
On 01/05/2013 12:38 AM, Stefan Hajnoczi wrote:
> Hi Yuan,
> BDRV_O_NOCACHE means bypass host page cache (O_DIRECT).
>
> BDRV_O_CACHE_WB specifies the cache semantics that the guest sees - that
> means whether the disk cache is writethrough or writeback.
>
> In other words, BDRV_O_NOCACHE is a hos
On Thu, Jan 03, 2013 at 09:43:53PM +0800, Liu Yuan wrote:
> On 12/25/2012 04:45 PM, Liu Yuan wrote:
> > Well, I found setting cache=directsync will contain 'BDRV_O_CACHE_WB'.
> > Is this a bug for current master? If no, my current scheme will be the
> > only way to bypass cache of sheepdog.
>
> Pi
On 12/25/2012 04:45 PM, Liu Yuan wrote:
> Well, I found setting cache=directsync will contain 'BDRV_O_CACHE_WB'.
> Is this a bug for current master? If no, my current scheme will be the
> only way to bypass cache of sheepdog.
Ping. Can anyone confirm it is a bug that 'cache=directsync' will pass
B
On 12/25/2012 03:47 PM, MORITA Kazutaka wrote:
> I wonder if we should disable cache when cache=none. Many management
> frontend uses cache=none by default but, I think, users still expect
> that data is cached (e.g. by disk write cache when a raw format is
> used). cache=none only means that the
On 12/25/2012 03:47 PM, MORITA Kazutaka wrote:
> I wonder if we should disable cache when cache=none. Many management
> frontend uses cache=none by default but, I think, users still expect
> that data is cached (e.g. by disk write cache when a raw format is
> used). cache=none only means that the
At Thu, 20 Dec 2012 02:29:31 +0800,
Liu Yuan wrote:
>
> From: Liu Yuan
>
> Sheepdog supports both writeback/writethrough write but has not yet supported
> DIRECTIO semantics which bypass the cache completely even if Sheepdog daemon
> is
> set up with cache enabled.
>
> Suppose cache is enabled
From: Liu Yuan
Sheepdog supports both writeback/writethrough write but has not yet supported
DIRECTIO semantics which bypass the cache completely even if Sheepdog daemon is
set up with cache enabled.
Suppose cache is enabled on Sheepdog daemon size, the new cache control is
cache=writeback # en
52 matches
Mail list logo
