From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCuyr-0002vx-6f for qemu-devel@nongnu.org; Mon, 10 Feb 2014 12:49:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WCuym-0000NV-7P for qemu-devel@nongnu.org; Mon, 10 Feb 2014 12:49:17 -0500 Received: from paradis.irqsave.net ([62.212.105.220]:49596) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCuyl-0000NK-SM for qemu-devel@nongnu.org; Mon, 10 Feb 2014 12:49:12 -0500 Date: Mon, 10 Feb 2014 18:49:11 +0100 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20140210174911.GA5205@irqsave.net> References: <925f4c0a62291c070991d1b3e75a770de986a686.1391541706.git.jcody@redhat.com> <20140205192535.GA3440@irqsave.net> <20140207034450.GB3787@in.ibm.com> <20140207142229.GA3081@irqsave.net> <20140207152734.GA16215@in.ibm.com> <20140207155733.GH29994@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20140207155733.GH29994@localhost.localdomain> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/2] block: gluster - code movements, state storage changes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, Bharata B Rao Le Friday 07 Feb 2014 =E0 10:57:33 (-0500), Jeff Cody a =E9crit : > On Fri, Feb 07, 2014 at 08:57:35PM +0530, Bharata B Rao wrote: > > On Fri, Feb 07, 2014 at 03:22:29PM +0100, Beno=EEt Canet wrote: > > > Le Friday 07 Feb 2014 =E0 09:14:50 (+0530), Bharata B Rao a =E9crit= : > > > > On Wed, Feb 05, 2014 at 08:25:36PM +0100, Beno=EEt Canet wrote: > > > > > Le Tuesday 04 Feb 2014 =E0 14:26:58 (-0500), Jeff Cody a =E9cri= t : > > > > > > =20 > > > > > > +static void qemu_gluster_parse_flags(int bdrv_flags, int *op= en_flags) > > > > > > +{ > > > > > > + assert(open_flags !=3D NULL); > > > > > > + > > > > > > + *open_flags |=3D O_BINARY; > > > > > > + > > > > > > + if (bdrv_flags & BDRV_O_RDWR) { > > > > > > + *open_flags |=3D O_RDWR; > > > > > > + } else { > > > > > > + *open_flags |=3D O_RDONLY; > > > > > > + } > > > > > > + > > > > > > + if ((bdrv_flags & BDRV_O_NOCACHE)) { > > > > > > + *open_flags |=3D O_DIRECT; > > > > > > + } > > > > > > +} > > > > >=20 > > > > > I saw the enable-O_SYNC option here. > > > > > http://www.gluster.org/community/documentation/index.php/Transl= ators/performance > > > > > Why the gluster driver does not allow to enable O_SYNC ? > > > >=20 > > > > I am not aware of any option in QEMU (like cache=3D etc) that wil= l force > > > > block driver (like gluster) to use O_SYNC. Do other drivers use O= _SYNC ? > > >=20 > > > [,cache=3Dwritethrough|writeback|none|directsync|unsafe][ > > >=20 > > > I think writethough is O_SYNC and directsync is O_DIRECT|O_SYNC. > >=20 > > May be I am missing something, but I checked the flags with which > > raw protocol driver opens the file image for different cache options > > and this is what I found by looking at open flags in util/osdep.c:qem= u_open() > >=20 > > (Ignoring O_CLOEXEC which is common for all the cases) > >=20 > > writethrough 02 O_RDWR > > writeback 02 O_RDWR=09 > > none 040002 O_DIRECT|O_RDWR > > directsync 040002 O_DIRECT|O_RDWR > > unsafe 02 O_RDWR > >=20 > > I do see the below comment in block/raw-posix.c:raw_parse_flags() > >=20 > > /* Use O_DSYNC for write-through caching, no flags for write-back= caching, > > * and O_DIRECT for no caching. */ > > if ((bdrv_flags & BDRV_O_NOCACHE)) { > > *open_flags |=3D O_DIRECT; > > } > >=20 > > But I don't see the driver actually setting O_DSYNC anywhere. > > >=20 > You are not mistaken. For qemu writethrough cache (the default), it > is not via O_SYNC/DSYNC directly in the protocol drivers, but > essentially done inside block.c (e.g., bdrv_flush()). >=20 >=20 Hmm sorry for spreading fud. It was not intentional.