Message ID | 20230218003323.2322580-5-ericvh@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp146959wrn; Fri, 17 Feb 2023 16:44:41 -0800 (PST) X-Google-Smtp-Source: AK7set+fy+v4m6GXXIHTq96THW6L2nq1DkhOUHJxSwm28GZasbJbkALo8BF/DvI2Ncp4jpzdEpxM X-Received: by 2002:a05:6a20:4b14:b0:c7:49c4:c28c with SMTP id fp20-20020a056a204b1400b000c749c4c28cmr5767246pzb.20.1676681080764; Fri, 17 Feb 2023 16:44:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676681080; cv=none; d=google.com; s=arc-20160816; b=OVY5bEFPDYzIDnprow8etKLrZqhUolDAm9hf3kAfqBN/0ZqToeBQxkbRUlKSsf9tme t99Lcrpv0XKwXtdOvAXQtGMP8gTnBqiNHqbQh0lfe2FNfRWndnU9cS0ExO7GkcaaP6Hb khVPkZXTGZ46+u1esGfAa/o+C4YsjTphAOlvdTnBi2rOYiaU5P3ThwJXCRqjwmDK/Sjh t/Eu8M3ImR8XjUwDnOsXVMPHTumPJGK18meNrdh/adzutlbrmeqyJXZ1x+vqLJOSSEBR TLrWDaB0nbUTey+yFzVqvDAyGgs3QMOEKYV9+BItlTUKR9NtfA9lw+HaYImbXPgMs1PZ YDZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=gRV/L1eN8c4leoO294fZ9F5eOKzUWH55ikdGdVVmuQs=; b=z+cLt32fZKy9PBFs2Nl1+RqXQv+EeS4GMf7j3fM51+4Iiu8dEiwtkN0tprd3lfdMIh Eeu6r1d72fA15OE+ym8z4PE6gQmUWNcXPyLLEG6Lwr4HW/K41lYg5UcjG5VivGo06Vzg tLeHpEwYg4VOcx1MgSizvRW0UthkuRo+uC+is83CfTgsLySdqvaBfA8bK7v6mJ7FzUdm tfTtkSxL8hHvP3GeePS7CEAOYc73/n32mBiSEn2KDoBYQhQNA4lutiOmDHNnaN2RRHrn WbdusTowgG42h3FggTukWGxYme79UPrIm+LtYfeZ0lGavIidfMXhn5FIeyzjSdRx1gQe Eh6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=sDJ1tW0n; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b12-20020a655ccc000000b004fb3861be41si6670103pgt.290.2023.02.17.16.44.28; Fri, 17 Feb 2023 16:44:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=sDJ1tW0n; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229555AbjBRAfx (ORCPT <rfc822;daweilics@gmail.com> + 99 others); Fri, 17 Feb 2023 19:35:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229585AbjBRAfw (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 17 Feb 2023 19:35:52 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDFC883F7; Fri, 17 Feb 2023 16:35:19 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 98EF6620A7; Sat, 18 Feb 2023 00:33:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F4C2C433A0; Sat, 18 Feb 2023 00:33:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1676680438; bh=r7VYuVAQDU98smxxlBwk5mo68iLowdZ4mILXuE17YKU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sDJ1tW0nJd35lXKg/oEsGs3Ne79q5RUlNKJDhBoD/8r2U17+sfDm/9TIdBPUfTFp8 PGDwxrROXHSZvpgHxEO+DmkbufWFUSZ1tKsY+eywqQMKQhG7nOrY8YylC0Co29AjER Tang6L0vTIU+SYJJo8r3oqG3c5+CWkIRlNTZfMw73FCXjXQXE0yqX8lqC4pzGL0qzo UUg22R5WDeTe3nTQpDehgTaMut4l+XnBpZp+H7x9EoaPrWg7WKqkTEgdW5zMQEYbl9 zcULamDlKZwhtpnYeq+ogRkPovsOb9QrWMOLPWUvUGdr+iCZLPQ6TWtpvjrGlEfsw/ TaEUfsQFg9uWg== From: Eric Van Hensbergen <ericvh@kernel.org> To: v9fs-developer@lists.sourceforge.net, asmadeus@codewreck.org, rminnich@gmail.com, lucho@ionkov.net Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux_oss@crudebyte.com, Eric Van Hensbergen <ericvh@kernel.org> Subject: [PATCH v4 04/11] fs/9p: Remove unnecessary superblock flags Date: Sat, 18 Feb 2023 00:33:16 +0000 Message-Id: <20230218003323.2322580-5-ericvh@kernel.org> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20230218003323.2322580-1-ericvh@kernel.org> References: <20230124023834.106339-1-ericvh@kernel.org> <20230218003323.2322580-1-ericvh@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758127540940980581?= X-GMAIL-MSGID: =?utf-8?q?1758127540940980581?= |
Series |
Performance fixes for 9p filesystem
|
|
Commit Message
Eric Van Hensbergen
Feb. 18, 2023, 12:33 a.m. UTC
These flags just add unnecessary extra operations.
When 9p is run without cache, it inherently implements
these options so we don't need them in the superblock
(which ends up sending extraneous fsyncs, etc.). User
can still request these options on mount, but we don't
need to set them as default.
Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org>
---
fs/9p/vfs_super.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Comments
Eric Van Hensbergen wrote on Sat, Feb 18, 2023 at 12:33:16AM +0000: > These flags just add unnecessary extra operations. > When 9p is run without cache, it inherently implements > these options so we don't need them in the superblock > (which ends up sending extraneous fsyncs, etc.). User > can still request these options on mount, but we don't > need to set them as default. Hm, I don't see where they'd add any operations -- if you have time would you mind pointing me at some? As far as I can see, it's just about 'sync' or 'dirsync' in /proc/mounts and the ST_SYNCHRONOUS statvfs flag; that looks harmless to me and it looks more correct to keep to me. (Sorry, didn't take the time to actually try taking a trace; I've checked the flag itself and the IS_SYNC/IS_DIRSYNC -> inode_needs_sync wrappers and that only seems used by specific filesystems who'd care about users setting the mount options, not the other way aorund.)
That's fair -- and it didn't seem to hurt anything to have DIRSYNC at the moment, so I can drop this patch if we think its too much noise. I guess it was more of a reaction the filesystem implicitly setting mount flags which might override whatever the user intended. FWIW SB_SYNCHRONOUS did seem to have an effect on behavior (although I didn't specifically track down where) -- I noticed this because the problems Christian found seemed to go away if I mounted the filesystem with sync (which basically ended up overriding aspects of the cache configuration I guess). -eric On Sat, Feb 18, 2023 at 3:34 AM <asmadeus@codewreck.org> wrote: > > Eric Van Hensbergen wrote on Sat, Feb 18, 2023 at 12:33:16AM +0000: > > These flags just add unnecessary extra operations. > > When 9p is run without cache, it inherently implements > > these options so we don't need them in the superblock > > (which ends up sending extraneous fsyncs, etc.). User > > can still request these options on mount, but we don't > > need to set them as default. > > Hm, I don't see where they'd add any operations -- if you have time > would you mind pointing me at some? > > As far as I can see, it's just about 'sync' or 'dirsync' in /proc/mounts > and the ST_SYNCHRONOUS statvfs flag; that looks harmless to me and it > looks more correct to keep to me. > > (Sorry, didn't take the time to actually try taking a trace; I've > checked the flag itself and the IS_SYNC/IS_DIRSYNC -> inode_needs_sync > wrappers and that only seems used by specific filesystems who'd care > about users setting the mount options, not the other way aorund.) > > -- > Dominique
Eric Van Hensbergen wrote on Sat, Feb 18, 2023 at 10:24:17AM -0600: > That's fair -- and it didn't seem to hurt anything to have DIRSYNC at > the moment, so I can drop this patch if we think its too much noise. > I guess it was more of a reaction the filesystem implicitly setting > mount flags which might override whatever the user intended. FWIW > SB_SYNCHRONOUS did seem to have an effect on behavior (although I > didn't specifically track down where) -- I noticed this because the > problems Christian found seemed to go away if I mounted the filesystem > with sync (which basically ended up overriding aspects of the cache > configuration I guess). I guess it doesn't hurt either way; happy to keep this patch in doubt.
diff --git a/fs/9p/vfs_super.c b/fs/9p/vfs_super.c index 266c4693e20c..65d96fa94ba2 100644 --- a/fs/9p/vfs_super.c +++ b/fs/9p/vfs_super.c @@ -84,9 +84,7 @@ v9fs_fill_super(struct super_block *sb, struct v9fs_session_info *v9ses, sb->s_bdi->io_pages = v9ses->maxdata >> PAGE_SHIFT; } - sb->s_flags |= SB_ACTIVE | SB_DIRSYNC; - if (!v9ses->cache) - sb->s_flags |= SB_SYNCHRONOUS; + sb->s_flags |= SB_ACTIVE; #ifdef CONFIG_9P_FS_POSIX_ACL if ((v9ses->flags & V9FS_ACL_MASK) == V9FS_POSIX_ACL)