From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52576 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P9gBm-0003Cn-3u for qemu-devel@nongnu.org; Sat, 23 Oct 2010 11:39:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P9gBk-0003Z4-Tk for qemu-devel@nongnu.org; Sat, 23 Oct 2010 11:39:22 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]:38211) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P9gBk-0003Yq-RO for qemu-devel@nongnu.org; Sat, 23 Oct 2010 11:39:20 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o9NFW0He030480 for ; Sat, 23 Oct 2010 11:32:01 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o9NFdH4t136294 for ; Sat, 23 Oct 2010 11:39:17 -0400 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 o9NFdHtA009948 for ; Sat, 23 Oct 2010 09:39:17 -0600 Message-ID: <4CC301A5.8030303@linux.vnet.ibm.com> Date: Sat, 23 Oct 2010 08:39:17 -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> 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 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. While these are just wrappers for now, what is the future direction of this kind of calls like qemu_fdatasync() qemu_malloc() etc? Will they be OK to call in threadlets without any locks? If so, may be we can use them in this function. Thanks, JV