From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:49220)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mjt@tls.msk.ru>) id 1SEnRf-0003sr-0Y
	for qemu-devel@nongnu.org; Mon, 02 Apr 2012 16:01:47 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mjt@tls.msk.ru>) id 1SEnRc-0002mr-NG
	for qemu-devel@nongnu.org; Mon, 02 Apr 2012 16:01:42 -0400
Received: from isrv.corpit.ru ([86.62.121.231]:54360)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mjt@tls.msk.ru>) id 1SEnRc-0002mh-FR
	for qemu-devel@nongnu.org; Mon, 02 Apr 2012 16:01:40 -0400
Message-ID: <4F7A05A2.4010301@msgid.tls.msk.ru>
Date: Tue, 03 Apr 2012 00:01:38 +0400
From: Michael Tokarev <mjt@tls.msk.ru>
MIME-Version: 1.0
References: <1333388150-12491-1-git-send-email-namei.unix@gmail.com>
In-Reply-To: <1333388150-12491-1-git-send-email-namei.unix@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] sheepdog: implement SD_OP_FLUSH_VDI
	operation
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Liu Yuan <namei.unix@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org, morita.kazutaka@lab.ntt.co.jp

On 02.04.2012 21:35, Liu Yuan wrote:
> From: Liu Yuan <tailai.ly@taobao.com>
> 
> Flush operation is supposed to flush the write-back cache of
> sheepdog cluster.
> 
> By issuing flush operation, we can assure the Guest of data
> reaching the sheepdog cluster storage.
> 
> Cc: Kevin Wolf <kwolf@redhat.com>
> Reviewd-by: MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>
> Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
> ---
>  block/sheepdog.c |   50 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 50 insertions(+), 0 deletions(-)
> 
> diff --git a/block/sheepdog.c b/block/sheepdog.c
> index 00276f6f..c08c69b 100644
> --- a/block/sheepdog.c
> +++ b/block/sheepdog.c
> @@ -32,9 +32,11 @@
>  #define SD_OP_RELEASE_VDI    0x13
>  #define SD_OP_GET_VDI_INFO   0x14
>  #define SD_OP_READ_VDIS      0x15
> +#define SD_OP_FLUSH_VDI      0x16
>  
>  #define SD_FLAG_CMD_WRITE    0x01
>  #define SD_FLAG_CMD_COW      0x02
> +#define SD_FLAG_CMD_CACHE    0x04
>  
>  #define SD_RES_SUCCESS       0x00 /* Success */
>  #define SD_RES_UNKNOWN       0x01 /* Unknown error */
> @@ -179,6 +181,8 @@ typedef struct SheepdogInode {
>      uint32_t data_vdi_id[MAX_DATA_OBJS];
>  } SheepdogInode;
>  
> +static int cache_enabled;

Why it is a global property instead of per-device
(in BDRVSheepdogState) property?

> @@ -1011,6 +1024,10 @@ static int sd_open(BlockDriverState *bs, const char *filename, int flags)
>      QLIST_INIT(&s->outstanding_aio_head);
>      s->fd = -1;
>  
> +    if (flags & BDRV_O_CACHE_WB) {
> +            cache_enabled = 1;
> +    }

You test per-device flag here, and set a global variable, why?

> +static int coroutine_fn sd_co_flush_to_disk(BlockDriverState *bs)
> +{
> +    BDRVSheepdogState *s = bs->opaque;
> +    SheepdogObjReq hdr = { 0 };
> +    SheepdogObjRsp *rsp = (SheepdogObjRsp *)&hdr;
> +    SheepdogInode *inode = &s->inode;
> +    int fd, ret;
> +    unsigned int wlen = 0, rlen = 0;
> +
> +    fd = connect_to_sdog(s->addr, s->port);
> +    if (fd < 0) {
> +        return -1;
> +    }

Do you really need _another_ connection here?
How about resolving server names, handling
connection timeouts (in case the server can't
accept new connection for some reason) and
other surrounding things?

Thanks,

/mjt