Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2964488imm; Sun, 7 Oct 2018 16:29:44 -0700 (PDT) X-Google-Smtp-Source: ACcGV60hWWOzYAAPkaTbdO/lOlUtWeE5FBUE5yPhPzFghNtT7X8pdTSDS086xYcEOuNpSTygOOJk X-Received: by 2002:a63:a40a:: with SMTP id c10-v6mr19255136pgf.140.1538954984308; Sun, 07 Oct 2018 16:29:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538954984; cv=none; d=google.com; s=arc-20160816; b=0NeTKuOduNNj4zw5JOEs/5uhA46za7aFQw66zD8LERzzneeFWblDzUn45CIqmIILnF 7VUTHVCZbxPZNICVQZX+BhuXxRmNnFMWQCrWXSIFJqQXgEhxLyIojCHFDDqIeDSeCjrY caJ2vt7pTERSQ+7xzO/T8hQXtzKLn4eFO4RMj8bkNWO71tUGgDQ5kZgH0/Pmbzj8A8T8 W6/UFd/v7fHezqdb+fGaPtYGUijUBo8qRe4x/xfDZYVSThbO1b5YiMfuYOl1fAwiIvYn aduvbwYCKMgzJASnpR4U1PtBnUhuXSDkk8et3L7htemB9ttui+ULVeuafKPFQIFMLRwj N3Zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=AfsFRrZ6KAlLBf436Eo8OYltlmn/LipQqbccNRty++w=; b=Qv9VM85feVL5sJivcpPlWJXVTdCHAG3Rm5V0NnoaDkFVCjL0YX+S1TpXV1FDdu1xBc fq5kH27FtaZHkmO68Sqlwu96iJETrrR76kKeqQh2USo8TN0sHcrDa9M1DKb8414nlDCt cZlkG0vKhWk+vzmwZgyxt96o2vIIQxTxmPeha1LB4UbZ83RkAAG14XzVx7m7rXWWuH+l 9BJDEQWqzruv2mRRlnioLdNl44UnQyBXDYS7Ncfgnhswe94XMx2GXQmTPfOXKp52lHg5 Fnjk6y4G87/8w6VAIlUf940r4+wvToHGYP90Il89y3bhNGAC/WQsrZCF+eYVABzX5K6T 4PUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@omnibond-com.20150623.gappssmtp.com header.s=20150623 header.b=WWimZL5G; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m80-v6si17217053pfj.48.2018.10.07.16.29.29; Sun, 07 Oct 2018 16:29:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@omnibond-com.20150623.gappssmtp.com header.s=20150623 header.b=WWimZL5G; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728397AbeJHGhI (ORCPT + 99 others); Mon, 8 Oct 2018 02:37:08 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:41302 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727082AbeJHGhH (ORCPT ); Mon, 8 Oct 2018 02:37:07 -0400 Received: by mail-qt1-f196.google.com with SMTP id l41-v6so6700813qtl.8 for ; Sun, 07 Oct 2018 16:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=omnibond-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=AfsFRrZ6KAlLBf436Eo8OYltlmn/LipQqbccNRty++w=; b=WWimZL5GLgq3R/GRMWQL2pBx28YmlCB6UWU2Ed/Der3OhEfGxgwDq2hAPiLcQyORzu PHbS1zlcy0jvrII5euhA2NQ3hKl/A24JdMvVwhEr6749KW/Ycv15BbynIHDr0BiK+qKH zFkDz8Khs+os0lKEZSxOZQ5DkZHRw5lrFE81ceTZQLtt0UvLt0BK3Z3itnlxTdDiWOfO 4T8YAPzi2y64P25d8VH6o8nSXOUufVkiAKrqJljhwnUiZ5qR14QNqkeTobObVpA2QaE9 QwnFnVtZvlV1iIRBUKrQ4Y32GsQq8RninagJxxQryHIVvaIaIQCG6PTBf52v2xzDWSCM J3tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=AfsFRrZ6KAlLBf436Eo8OYltlmn/LipQqbccNRty++w=; b=PtW6GD6KhSIgkgsDzfqvgoGNBkf4x24WjHPhQ+5jAPZNMZBpsI0Pl5GC68VWJ4/xYA PAxV6QYE6ZgG+e2+8NTQ1A49MkagUTWmU3lPh7RBgUyeFSIW9md+GUKlE+g6wn4NzSwh nsjs0qcLlhu4SaQK9h+taAD9QYvGmuywz5FZrxtgkMeCRx9aeLm9t1OC2gqLVjDalec5 jsd6R02FzGKDo9kZ1VeeknhLTzkfhzvSJvOOiGYRmVz/ghwKQyH/HL4C8FHB231ZxFiw RkgGsmIeMftSI/R5zzRzMsY+btE7Wan3+tM5ng8zxQbrQ2+RLQy6rXMTN7mToh4mB2iu C/Bw== X-Gm-Message-State: ABuFfohs5y17tq1bMMjYSpJKsffFOP7szGhXKCoquWwr5JJu7gBXhKM0 FAbcCDKskLlXd/4BwcPdGYSPQg== X-Received: by 2002:a0c:c119:: with SMTP id f25-v6mr17277242qvh.219.1538954894640; Sun, 07 Oct 2018 16:28:14 -0700 (PDT) Received: from ip-172-31-22-34.ec2.internal (ec2-35-153-175-159.compute-1.amazonaws.com. [35.153.175.159]) by smtp.gmail.com with ESMTPSA id x38-v6sm6793915qtc.39.2018.10.07.16.28.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 07 Oct 2018 16:28:13 -0700 (PDT) From: Martin Brandenburg To: devel@lists.orangefs.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, hubcap@omnibond.com Cc: Martin Brandenburg Subject: [PATCH 15/19] orangefs: avoid fsync service operation on flush Date: Sun, 7 Oct 2018 23:27:32 +0000 Message-Id: <20181007232736.3780-16-martin@omnibond.com> X-Mailer: git-send-email 2.19.0 In-Reply-To: <20181007232736.3780-1-martin@omnibond.com> References: <20181007232736.3780-1-martin@omnibond.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- fs/orangefs/file.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/fs/orangefs/file.c b/fs/orangefs/file.c index 5eda483263ae..d5ecfea3288a 100644 --- a/fs/orangefs/file.c +++ b/fs/orangefs/file.c @@ -596,7 +596,24 @@ static int orangefs_lock(struct file *filp, int cmd, struct file_lock *fl) 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; + + 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); + } + + return filemap_write_and_wait_range(file->f_mapping, 0, LLONG_MAX); } /** ORANGEFS implementation of VFS file operations */ -- 2.19.0