> 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
51 matches
Mail list logo
