From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50793 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PueGG-0001lM-Ed for qemu-devel@nongnu.org; Wed, 02 Mar 2011 00:06:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PueGE-000632-Vh for qemu-devel@nongnu.org; Wed, 02 Mar 2011 00:06:08 -0500 Received: from e28smtp07.in.ibm.com ([122.248.162.7]:53880) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PueGE-00060J-6l for qemu-devel@nongnu.org; Wed, 02 Mar 2011 00:06:06 -0500 Received: from d28relay01.in.ibm.com (d28relay01.in.ibm.com [9.184.220.58]) by e28smtp07.in.ibm.com (8.14.4/8.13.1) with ESMTP id p2255tPG005321 for ; Wed, 2 Mar 2011 10:35:55 +0530 Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p2255tvx3543110 for ; Wed, 2 Mar 2011 10:35:55 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p2255s0O026293 for ; Wed, 2 Mar 2011 16:05:55 +1100 From: "Aneesh Kumar K. V" Subject: Re: [Qemu-devel] [PATCH -V2 4/6] hw/9pfs: Implement syncfs In-Reply-To: References: <1298961534-8099-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <1298961534-8099-4-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <87k4gievf2.fsf@linux.vnet.ibm.com> <87r5aqhg7e.fsf@linux.vnet.ibm.com> Date: Wed, 02 Mar 2011 10:35:47 +0530 Message-ID: <874o7m6ris.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org On Tue, 1 Mar 2011 20:27:19 +0000, Stefan Hajnoczi wro= te: > On Tue, Mar 1, 2011 at 6:02 PM, Aneesh Kumar K. V > wrote: > > On Tue, 1 Mar 2011 15:59:19 +0000, Stefan Hajnoczi = wrote: > >> >> Please explain the semantics of P9_TSYNCFS. =C2=A0Won't returning s= uccess > >> >> without doing anything lead to data integrity issues? > >> > > >> > I should actually do the 9P Operation format as commit message. Will > >> > add in the next update. Whether returning here would cause a data > >> > integrity issue, it depends what sort of guarantee we want to > >> > provide. So calling sync on the guest will cause all the dirty pages= in > >> > the guest to be flushed to host. Now all those changes are in the ho= st > >> > page cache and it would be nice to flush them =C2=A0as a part of syn= c but > >> > then since we don't have a per file system sync, the above would imp= ly > >> > we flush all dirty pages on the host which can result in large > >> > performance impact. > >> > >> You get the define the semantics of P9_TSYNCFS? =C2=A0I thought this is > >> part of a well-defined protocol :). =C2=A0If this is a .L extension th= en > >> it's probably a bad design and shouldn't be added to the protocol if > >> we can't implement it. > > > > It is a part of .L extension and we can definitely implement it. There > > is patch out there which is yet to be merged > > > > http://thread.gmane.org/gmane.linux.file-systems/44628 >=20 > A future Linux-only ioctl :/. >=20 > >> Is this operation supposed to flush the disk write cache too? > > > > I am not sure we need to specify that as a part of 9p operation. I guess > > we can only say maximum possible data integrity. Whether a sync will > > cause disk write cache flush depends on the file system. For ext* that > > can be controlled by mount option barrier. >=20 > So on a host with a safe configuration this operation should put data > on stable storage? >=20 > >> > >> I think virtio-9p has a file descriptor cache. =C2=A0Would it be possi= ble > >> to fsync() those file descriptors? > >> > > > > Ideally we should. But that would involve a large number of fsync calls. >=20 > Yep, that's why this is a weird operation to support, especially since > it's a .L add-on and not original 9P. What's the use-case since > today's Linux userland cannot directly make use of this operation? I > guess it has been added in order to pass-through a Linux internal vfs > super block sync function? IMHO it would be nice to have a syncfs 9p operation because that enables the client to say "if possible" flush the dirty data on the server. I guess we should consider this as something server can choose to ignore. In a cloud setup even doing a per file system sync can imply performance impact because VirtFS export may not 1:1 map to mount point on host. There is also plan to add a new option to the VirtFs export point which enable write to exported files to be either O_SYNC or O_DIRECT, similar to the way done for image files. That would imply Tsyncfs doesn't have much to do because we don't have dirty data on host pagecache anymore.=20 So from 9p .L protocol point of view, it is a valid operation which enables client to request a flush of server cache if possible. And qemu 9p server choose to ignore because of the performance impact. If you are not comfortable with not doing anything specific in Tsyncfs operation, we can add sync(2) call as part of this 9p operation and later switch to FS_IOC_SYNCFS when it become available. -aneesh