Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp106030ybt; Thu, 18 Jun 2020 19:46:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwArgovG6meeES0a9HjPR/I1q4klKL+h8wCoYdud8NiyoQSigfrBTam3TrAGPxdZJ+Kpn+z X-Received: by 2002:a05:6402:b13:: with SMTP id bm19mr1206700edb.82.1592534785326; Thu, 18 Jun 2020 19:46:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592534785; cv=none; d=google.com; s=arc-20160816; b=HIu7k5Msg0BFzL2KGflkmRtpdocYsfj4umGFz9WfplxJO67Wg5vYpvXm+vaXltRsG2 SfY3CvVjtfpwCi9rUlJIwH3F06eP7O9e6Ct1/tb3O79R2Q150p0CVczE+uGr+GmT4Lum c8Io+UcvJJYJYFRRjNBPG5HA07yu1S2RyxAgKtcFBz8dNh2+BtJouEKY6OxijZl24zTN vnkQNLYw/FvhIrmMOWi/GMANKVkV97tPWUvaHO5zZHiV8aUReZU+pBZUnfjsyE5zWRrB pcB6+euOksfU2LSAp1g75aXLOHhhXoM0LZKiXgOOR8/bAyjP/3x4AoSff9taYaM4tXiO +g0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=hVuGMFevzkCpnc+wXsCx24hpX2LiCkBMKQ2SwveqF5M=; b=CM8qlwvpLJcDnPkNlJMcSgW3pDE3ZTyWrcicBzBxlvckugNWrCwZjHlXBsqm2EH5BC oAg8RVUTAhiIf8zsQS1BD8IjmswI+BUIkF3ypRQECbbxhXyWeaxA/W3DN8iraYkPVjFN ly5lepmnbXseogrI+cAPNsiTbLzhfTlQHOOX31qndDC3VtX5CpxbGu4YAUbJwFDmbdqo 18rjUasg1CBu2Ap8twVEx+4AuQMURM0iTHF8HpJNlw2mmx82KRlTGtuftiLhMRfLgYlF NLlqJSVXuHyEOeDH+vvVpaZtGqXq38BSzVRh5JasJMNAGkZJSw0gYad09jIHMF2EtEzH trMg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id qq18si3151539ejb.195.2020.06.18.19.46.01; Thu, 18 Jun 2020 19:46:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727853AbgFSCpZ (ORCPT + 99 others); Thu, 18 Jun 2020 22:45:25 -0400 Received: from [211.29.132.246] ([211.29.132.246]:35947 "EHLO mail104.syd.optusnet.com.au" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1726906AbgFSCpZ (ORCPT ); Thu, 18 Jun 2020 22:45:25 -0400 Received: from dread.disaster.area (unknown [49.180.124.177]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 55C568236D9; Fri, 19 Jun 2020 12:44:58 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1jm71T-0002Jl-8d; Fri, 19 Jun 2020 12:44:55 +1000 Date: Fri, 19 Jun 2020 12:44:55 +1000 From: Dave Chinner To: "J. Bruce Fields" Cc: Masayoshi Mizuma , Eric Sandeen , "Darrick J. Wong" , Christoph Hellwig , Theodore Ts'o , Andreas Dilger , Alexander Viro , Masayoshi Mizuma , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-xfs , jlayton@redhat.com Subject: Re: [PATCH] fs: i_version mntopt gets visible through /proc/mounts Message-ID: <20200619024455.GN2005@dread.disaster.area> References: <20200617172456.GP11245@magnolia> <8f0df756-4f71-9d96-7a52-45bf51482556@sandeen.net> <20200617181816.GA18315@fieldses.org> <4cbb5cbe-feb4-2166-0634-29041a41a8dc@sandeen.net> <20200617184507.GB18315@fieldses.org> <20200618013026.ewnhvf64nb62k2yx@gabell> <20200618030539.GH2005@dread.disaster.area> <20200618034535.h5ho7pd4eilpbj3f@gabell> <20200618223948.GI2005@dread.disaster.area> <20200619022005.GA25414@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200619022005.GA25414@fieldses.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=QIgWuTDL c=1 sm=1 tr=0 a=k3aV/LVJup6ZGWgigO6cSA==:117 a=k3aV/LVJup6ZGWgigO6cSA==:17 a=kj9zAlcOel0A:10 a=nTHF0DUjJn0A:10 a=VwQbUJbxAAAA:8 a=20KFwNOVAAAA:8 a=7-415B0cAAAA:8 a=Ddvq-uZmtdYEE3EvMV8A:9 a=CjuIK1q_8ugA:10 a=AjGcO6oz07-iQ99wixmX:22 a=biEYGPWJfzWAr4FL6Ov7:22 Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Jun 18, 2020 at 10:20:05PM -0400, J. Bruce Fields wrote: > On Fri, Jun 19, 2020 at 08:39:48AM +1000, Dave Chinner wrote: > > On Wed, Jun 17, 2020 at 11:45:35PM -0400, Masayoshi Mizuma wrote: > > > Thank you for pointed it out. > > > How about following change? I believe it works both xfs and btrfs... > > > > > > diff --git a/fs/super.c b/fs/super.c > > > index b0a511bef4a0..42fc6334d384 100644 > > > --- a/fs/super.c > > > +++ b/fs/super.c > > > @@ -973,6 +973,9 @@ int reconfigure_super(struct fs_context *fc) > > > } > > > } > > > > > > + if (sb->s_flags & SB_I_VERSION) > > > + fc->sb_flags |= MS_I_VERSION; > > > + > > > WRITE_ONCE(sb->s_flags, ((sb->s_flags & ~fc->sb_flags_mask) | > > > (fc->sb_flags & fc->sb_flags_mask))); > > > /* Needs to be ordered wrt mnt_is_readonly() */ > > > > This will prevent SB_I_VERSION from being turned off at all. That > > will break existing filesystems that allow SB_I_VERSION to be turned > > off on remount, such as ext4. > > > > The manipulations here need to be in the filesystem specific code; > > we screwed this one up so badly there is no "one size fits all" > > behaviour that we can implement in the generic code... > > My memory was that after Jeff Layton's i_version patches, there wasn't > really a significant performance hit any more, so the ability to turn it > off is no longer useful. Yes, I completely agree with you here. However, with some filesystems allowing it to be turned off, we can't just wave our hands and force enable the option. Those filesystems - if the maintainers chose to always enable iversion - will have to go through a mount option deprecation period before permanently enabling it. > But looking back through Jeff's postings, I don't see him claiming that; > e.g. in: > > https://lore.kernel.org/lkml/20171222120556.7435-1-jlayton@kernel.org/ > https://lore.kernel.org/linux-nfs/20180109141059.25929-1-jlayton@kernel.org/ > https://lore.kernel.org/linux-nfs/1517228795.5965.24.camel@redhat.com/ > > he reports comparing old iversion behavior to new iversion behavior, but > not new iversion behavior to new noiversion behavior. Yeah, it's had to compare noiversion behaviour on filesystems where it was understood that it couldn't actually be turned off. And, realistically, the comaprison to noiversion wasn't really relevant to the problem Jeff's patchset was addressing... Cheers, Dave. -- Dave Chinner david@fromorbit.com