From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5FC67C10F14 for ; Thu, 18 Apr 2019 18:43:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 355D72064A for ; Thu, 18 Apr 2019 18:43:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555612981; bh=bXa9NGWbrqkasDp8LPA2B4cMrzExVSrAgqNTo3KH2EA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=wVQatmxVdvaAg/Bv9zKe98J/vUJEAIcK1lnqrKKH+/8djME0so9x0qD+1vI74zGu8 fzBI/N+ZmBzN33Gezj4IYUwUCJGtQjuqsO8TUcVvYuv3vrLDxQhz2WNfJYTM7mQ4OS Rvlw+nKtNx82CRnPYa0H8BM4sPXsFFrlU9FV9QFU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390025AbfDRSnA (ORCPT ); Thu, 18 Apr 2019 14:43:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:60818 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389952AbfDRSm6 (ORCPT ); Thu, 18 Apr 2019 14:42:58 -0400 Received: from localhost.localdomain (unknown [24.213.116.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7D50D21871; Thu, 18 Apr 2019 18:42:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555612978; bh=bXa9NGWbrqkasDp8LPA2B4cMrzExVSrAgqNTo3KH2EA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fJYwDNDuPAR5eQ5DMu4Z/ZTSyaN4imSizopRTOsRMTOYSb9IGMsseqYhBOSxwZGlB Y6Xm05/lQGvijJf3rwRjL8MC9ll1TqSvD+b9clbHe4WDs+eADULZz/HfWYim6vjjxU ZQpwvvJ+GmEqu315NV9ZBDkzR1+AR7tJaFVkOuFY= From: hubcap@kernel.org To: linux-fsdevel@vger.kernel.org, christoph@lameter.com Cc: Martin Brandenburg , Mike Marshall Subject: [PATCH 16/22] orangefs: avoid fsync service operation on flush Date: Thu, 18 Apr 2019 14:41:08 -0400 Message-Id: <20190418184113.9152-17-hubcap@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190418184113.9152-1-hubcap@kernel.org> References: <20190418184113.9152-1-hubcap@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org From: Martin Brandenburg Without this, an fsync call is sent to the server even if no data changed. This resulted in a rather severe (50%) performance regression under certain metadata-heavy workloads. In the past, everything was direct IO. Nothing happend on a close call. An explicit fsync call would send an fsync request to the server which in turn fsynced the underlying file. Now there are cached writes. Then fsync began writing out dirty pages in addition to making an fsync request to the server, and close began calling fsync. With this commit, close only writes out dirty pages, and does not make the fsync request. Signed-off-by: Martin Brandenburg Signed-off-by: Mike Marshall --- fs/orangefs/file.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/fs/orangefs/file.c b/fs/orangefs/file.c index f4e20d5ed207..26d8ff410b0a 100644 --- a/fs/orangefs/file.c +++ b/fs/orangefs/file.c @@ -487,7 +487,29 @@ static int orangefs_lock(struct file *filp, int cmd, struct file_lock *fl) static int orangefs_flush(struct file *file, fl_owner_t id) { - return vfs_fsync(file, 0); + /* + * This is vfs_fsync_range(file, 0, LLONG_MAX, 0) without the + * service_operation in orangefs_fsync. + * + * Do not send fsync to OrangeFS server on a close. Do send fsync + * on an explicit fsync call. This duplicates historical OrangeFS + * behavior. + */ + struct inode *inode = file->f_mapping->host; + int r; + + if (inode->i_state & I_DIRTY_TIME) { + spin_lock(&inode->i_lock); + inode->i_state &= ~I_DIRTY_TIME; + spin_unlock(&inode->i_lock); + mark_inode_dirty_sync(inode); + } + + r = filemap_write_and_wait_range(file->f_mapping, 0, LLONG_MAX); + if (r > 0) + return 0; + else + return r; } /** ORANGEFS implementation of VFS file operations */ -- 2.20.1