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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A6CCC433EF for ; Wed, 20 Jul 2022 14:15:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234489AbiGTOP5 (ORCPT ); Wed, 20 Jul 2022 10:15:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34522 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229712AbiGTOP5 (ORCPT ); Wed, 20 Jul 2022 10:15:57 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8A9023AB12 for ; Wed, 20 Jul 2022 07:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658326554; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zFK3tkfEyTe6jEh19UggWd/zo4/NbtsoQCP905aDbQo=; b=edhJeCQl+DeW4aIRz3fvmFWPrlQWQBRjeW9JSlV3+ijcJBQyYYYaSx2l5LgFZh+yY5ftp6 TksQGa4hj7l9urD8mml2MPe7IzkJol019LIN3JFkGXuet4W+2T31hH3K3WUkfIgNDpv+mP ZwsqKO+3sH05CKewmPpYcSNkYnGHtpg= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-401-dU7N4XjZMdq_AqhedIGCSg-1; Wed, 20 Jul 2022 10:15:50 -0400 X-MC-Unique: dU7N4XjZMdq_AqhedIGCSg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 139ED280F2AE; Wed, 20 Jul 2022 14:15:50 +0000 (UTC) Received: from fedora (unknown [10.40.194.108]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E29ADC1D3AD; Wed, 20 Jul 2022 14:15:48 +0000 (UTC) Date: Wed, 20 Jul 2022 16:15:46 +0200 From: Lukas Czerner To: Jeff Layton Cc: tytso@mit.edu, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, linux-fsdevel , Benjamin Coddington Subject: Re: should we make "-o iversion" the default on ext4 ? Message-ID: <20220720141546.46l2d7bxwukjhtl7@fedora> References: <69ac1d3ef0f63b309204a570ef4922d2684ed7f9.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69ac1d3ef0f63b309204a570ef4922d2684ed7f9.camel@kernel.org> X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, Jul 19, 2022 at 09:51:33AM -0400, Jeff Layton wrote: > Back in 2018, I did a patchset [1] to rework the inode->i_version > counter handling to be much less expensive, particularly when no-one is > querying for it. > > Testing at the time showed that the cost of enabling i_version on ext4 > was close to 0 when nothing is querying it, but I stopped short of > trying to make it the default at the time (mostly out of an abundance of > caution). Since then, we still see a steady stream of cache-coherency > problems with NFSv4 on ext4 when this option is disabled (e.g. [2]). > > Is it time to go ahead and make this option the default on ext4? I don't > see a real downside to doing so, though I'm unclear on how we should > approach this. Currently the option is twiddled using MS_I_VERSION flag, > and it's unclear to me how we can reverse the sense of such a flag. > > Thoughts? > > [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4b7fd7d34de5765dece2dd08060d2e1f7be3b39 > [2]: https://bugzilla.redhat.com/show_bug.cgi?id=2107587 Hi, I don't have the results myself yet, but a quick look at how it is done suggests that indeed the impact should be low. But not zero, at least every time the inode is loaded from disk it is scheduled for i_version update on the next attempted increment. Could that have an effect on some particular common workload you can think of? How would we approach making iversion a default? libmount is passing this option to the kernel as just a MS_I_VERSION flag that is set when -o iversion is used and left empty when the -o noiversion is used. This means that while we could make it a default in ext4, we don't have any way of knowing whether the user asked for -o noiversion. So that's not really an option. Updating the mke2fs/tune2fs to allow setting iversion as a default mount option I think has the same problem. So the only way I can see ATM would be to introduce another mountflag for libmount to indicate -o noiversion. This way we can make iversion a default on ext4 without loosing the information about user provided -o noiversion option. Is there a different way I am not seeing? If we can do reasonably extensive testing that will indeed show negligible impact when nothing is querying i_version, then I would be in favor of the change. Thanks! -Lukas > > -- > Jeff Layton >