From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40298 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P9sEO-0005Ic-OD for qemu-devel@nongnu.org; Sun, 24 Oct 2010 00:30:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P9sEN-0004PT-MY for qemu-devel@nongnu.org; Sun, 24 Oct 2010 00:30:52 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:41554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P9sEN-0004PN-Eh for qemu-devel@nongnu.org; Sun, 24 Oct 2010 00:30:51 -0400 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e39.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o9O4Jsbh005912 for ; Sat, 23 Oct 2010 22:19:54 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o9O4Uoej215708 for ; Sat, 23 Oct 2010 22:30:50 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o9O4UocS005477 for ; Sat, 23 Oct 2010 22:30:50 -0600 Message-ID: <4CC3B67B.5020303@linux.vnet.ibm.com> Date: Sat, 23 Oct 2010 21:30:51 -0700 From: "Venkateswararao Jujjuri (JV)" MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] [virtio-9p] Add datasync to server side TFSYNC/RFSYNC for dotl References: <1287774922-19033-1-git-send-email-jvrao@linux.vnet.ibm.com> <4CC301A5.8030303@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org On 10/23/2010 11:27 AM, Blue Swirl wrote: > On Sat, Oct 23, 2010 at 3:39 PM, Venkateswararao Jujjuri (JV) > wrote: >> On 10/23/2010 5:44 AM, Blue Swirl wrote: >>> On Fri, Oct 22, 2010 at 7:15 PM, Venkateswararao Jujjuri (JV) >>> wrote: >>>> SYNOPSIS >>>> size[4] Tfsync tag[2] fid[4] datasync[4] >>>> >>>> size[4] Rfsync tag[2] >>>> >>>> DESCRIPTION >>>> >>>> The Tfsync transaction transfers ("flushes") all modified in-core data of >>>> file identified by fid to the disk device (or other permanent storage >>>> device) where that file resides. >>>> >>>> If datasync flag is specified data will be fleshed but does not flush >>>> modified metadata unless that metadata is needed in order to allow a >>>> subsequent data retrieval to be correctly handled. >>>> >>>> Signed-off-by: Venkateswararao Jujjuri >>>> --- >>>> hw/file-op-9p.h | 2 +- >>>> hw/virtio-9p-local.c | 8 ++++++-- >>>> hw/virtio-9p.c | 11 ++++++----- >>>> 3 files changed, 13 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/hw/file-op-9p.h b/hw/file-op-9p.h >>>> index 21d60b5..c7731c2 100644 >>>> --- a/hw/file-op-9p.h >>>> +++ b/hw/file-op-9p.h >>>> @@ -86,7 +86,7 @@ typedef struct FileOperations >>>> int (*fstat)(FsContext *, int, struct stat *); >>>> int (*rename)(FsContext *, const char *, const char *); >>>> int (*truncate)(FsContext *, const char *, off_t); >>>> - int (*fsync)(FsContext *, int); >>>> + int (*fsync)(FsContext *, int, int); >>>> int (*statfs)(FsContext *s, const char *path, struct statfs *stbuf); >>>> ssize_t (*lgetxattr)(FsContext *, const char *, >>>> const char *, void *, size_t); >>>> diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c >>>> index 0d52020..d0c79e4 100644 >>>> --- a/hw/virtio-9p-local.c >>>> +++ b/hw/virtio-9p-local.c >>>> @@ -490,9 +490,13 @@ static int local_remove(FsContext *ctx, const char *path) >>>> return remove(rpath(ctx, path)); >>>> } >>>> >>>> -static int local_fsync(FsContext *ctx, int fd) >>>> +static int local_fsync(FsContext *ctx, int fd, int datasync) >>>> { >>>> - return fsync(fd); >>>> + if (datasync) { >>>> + return fdatasync(fd); >>> >>> Please use qemu_fdatasync(). >> >> This file and functions in it are intended as wrappers of syscalls >> which can be used in threadlets. Per Anthony's statement about avoiding >> any QEMU specific code in threadlets, l I am planning to avoid any QEMU specific >> calls >> in the virtio-9p-local.c library. > > That way would lead to code duplication, reduced functionality and > portability. If the problem is threading and that the current > functions are not thread safe, then we should add new functions to > QEMU instead. Thanks, Sent another patch with qemu_fdatasync. The function in its current form has no issues with threading. Thanks, JV >