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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6998EC0032E for ; Fri, 20 Oct 2023 20:06:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2DA6800CE; Fri, 20 Oct 2023 16:06:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB72A800CD; Fri, 20 Oct 2023 16:06:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D595D800CE; Fri, 20 Oct 2023 16:06:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id BFCBA800CD for ; Fri, 20 Oct 2023 16:06:56 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 948A6C051D for ; Fri, 20 Oct 2023 20:06:56 +0000 (UTC) X-FDA: 81366923232.24.B693F0D Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf11.hostedemail.com (Postfix) with ESMTP id 8797F4000A for ; Fri, 20 Oct 2023 20:06:54 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=PvloEc9N; dmarc=none; spf=pass (imf11.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697832414; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FJwcfh7XT4p/d8xdEQd3o4yb8QA8P7Clkcjdf6k/CEg=; b=Jzpp1fxpaJqBW3zu1kadVkgWf2f3nhI6HrOndOMETmLuJympcNNztqKrQ9jco1S19XGIaV zekLSCEN7xAG/SXCJfaiEXTaaVYYbPiSFMOw8LO3q6HdHMco2YqTdt3TmpQSBQgldjpr0U RvEOnOpz89Jj8hnZOxAQYQ2n+Vx+dL4= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=PvloEc9N; dmarc=none; spf=pass (imf11.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697832414; a=rsa-sha256; cv=none; b=DTdfzVGqjm1wx99Jf5EtRUi/TWSBDgP4w7CGb3oMOm96/nBNUWc9m+25R8YQm4ImFMxST1 dPVXu9lG5WjH4MOUnhYpSo28nKCPHi7qKjUeQsqh5Z0glk7xyfEKaTBkdNX8YLwvAOIwY5 V4vWqphs1/WdgwA+yYzcLoLdPY3E88A= Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-507962561adso1706954e87.0 for ; Fri, 20 Oct 2023 13:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1697832412; x=1698437212; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FJwcfh7XT4p/d8xdEQd3o4yb8QA8P7Clkcjdf6k/CEg=; b=PvloEc9Nq+s3ztPGVYpzTDpypP7PxroDuPmDdr6O+vo9LmEomsYl6W/Ov5uIhWrIxL FaLr2WAE3A/dC31ra6wrJopMm4VnNmVZ7/64DoAOby/lphfy9hf6fIg7YL3DjrJrShjl eFbUncE5btPx0QBVfiPnNFHz39QHTtkn61TRE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697832412; x=1698437212; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FJwcfh7XT4p/d8xdEQd3o4yb8QA8P7Clkcjdf6k/CEg=; b=B/5B2AT4bJKDTR6XqdYyHSdPTCPFJR/mcrBQyW5faFitnXc4c90SKzg00TVONMO3i+ QzbGNIpEpQzMmNscnL+/s565cSAJyCsgfud2y7VSr/M0IwgVTLf2LfDKXO6jRfUMgOsy rQf1sUo9FhPaHm5DQK+JFE5bgd/iuZukT83rcqdl+CazWy3BGrUMplPcx87xslxHOqmv 8xMzYLBAa/b5O0DrHe2mOpu3+dOihbGFh1L80dEjGf52deECHJnm4VkQ0YK6vaMa/OIO 0xzNpyxqJwXgwH6lolaBRe8MTj4a8afg4+qwWf7Pf5L1I7ybHGLtg5Cqvnf8jZoOjnDO 1y0w== X-Gm-Message-State: AOJu0Yxohwmztxdh/Sdgz4GX7MC1BMsnFINYgil3Kea0viYaJs3K/Dc2 2hV8d9HnwQ1Z2K09+E4lEaDvaT2L4UxIjq+Y00DEZJJg X-Google-Smtp-Source: AGHT+IFIIGddo2IltlG69wbnAJ7cAhty/GDiEughTj3dlb1mtoBnpIRGKPi/2g/OtcFqZqWE+kY3CA== X-Received: by 2002:ac2:4101:0:b0:4ff:a8c6:d1aa with SMTP id b1-20020ac24101000000b004ffa8c6d1aamr2090000lfi.48.1697832412368; Fri, 20 Oct 2023 13:06:52 -0700 (PDT) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com. [209.85.208.182]) by smtp.gmail.com with ESMTPSA id p3-20020a056512312300b005033948f108sm498023lfd.272.2023.10.20.13.06.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Oct 2023 13:06:52 -0700 (PDT) Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2c51388ccebso18290661fa.3 for ; Fri, 20 Oct 2023 13:06:52 -0700 (PDT) X-Received: by 2002:a17:907:c1f:b0:9ba:65e:752b with SMTP id ga31-20020a1709070c1f00b009ba065e752bmr2061794ejc.39.1697832390868; Fri, 20 Oct 2023 13:06:30 -0700 (PDT) MIME-Version: 1.0 References: <20231018-mgtime-v1-0-4a7a97b1f482@kernel.org> <20231018-mgtime-v1-2-4a7a97b1f482@kernel.org> <5f96e69d438ab96099bb67d16b77583c99911caa.camel@kernel.org> <20231019-fluor-skifahren-ec74ceb6c63e@brauner> <0a1a847af4372e62000b259e992850527f587205.camel@kernel.org> In-Reply-To: From: Linus Torvalds Date: Fri, 20 Oct 2023 13:06:13 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC 2/9] timekeeping: new interfaces for multigrain timestamp handing To: Jeff Layton Cc: Dave Chinner , Kent Overstreet , Christian Brauner , Alexander Viro , John Stultz , Thomas Gleixner , Stephen Boyd , Chandan Babu R , "Darrick J. Wong" , "Theodore Ts'o" , Andreas Dilger , Chris Mason , Josef Bacik , David Sterba , Hugh Dickins , Andrew Morton , Amir Goldstein , Jan Kara , David Howells , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8797F4000A X-Stat-Signature: kd3fp8a4q5bm9aaiy8zgxmhixzyw88ru X-HE-Tag: 1697832414-527001 X-HE-Meta: U2FsdGVkX18sw028D9UAZDB3pvH2PQi2B6+v17m7FCnKXLx7/03o2wBqfKGv7k27D2WmXWSraV3fJUxaDwa8LTnBV7d592VSVs+nPHatyob4mSTSIT+bKyxgrHxKZs7ZPWnpALwjmAApvPTESsIPyle0NQ9SxQDtKLRNmp5m8J3ERF49bffAQszbKFsTg4JrnVtV27iNwJT3G46Fx+yLOe0/BwpllXqXub7Cw+j5/ol4AY/BpWLI2u3BjIStdITMrJSu//fFRvEcMTmJmwjJV4ODKWfM9Ev0VUrC01Mq++HROtNmVs1fDXTk6Kg7ra7C8ru9T/caktbtzpVIvUb//Nklbf44I0jIcgbKeH5JfoecA4PRPZYBHPM81I7qxjYvaxkMnT+EcdkQAAaRyoYOFCiSiymvjlX3WV1qqxYVhSvRDq9aPicVU99p4x93NLQrpm85V7wuUODyyL6ZvQ8zqUYoBr3RSoAYrLqdnJGNdTsXL8bkm6LDSa7JMt1mY9/vBENgC3MCpDYGCbrTnonnbGyu1b7Oicg5umQ4fiB/T4H7/K2bXAUCs/3WabOx3oG5SheWfTxbrUz5LN1FGx1iiS1nYtviUtfgsEawMk7NgLmAdk6KMIVCTvrP+lTHzVydD+PA03zCTbkTzi4AA1WC+AUCeaYCF7glAZVXtfHCW1P+E5ayN71jRe1gibgIl21udzaU/DrHkl12SWo3Wm0k9fP1ojH/laDcABwLJaqWgDBS8AnZZ2OeKTKsKz3PwJ81W10KzUGilwkQXlV+kdfr0okqpFQyZMndabeRZCBPveXzSmdunHTp7ovmRV358Ub3f4SwW1P5fI/U5fZG5zUKL4/3Ujqagtli+o4p/PIHEiMMjtbb8AkpQ2Wj6fCY4DfWh8QaqrgwfZGf2u+S65u7P9qhH+apXaOEhB4qpbStUj5ocQOYo0Su7QQc22yeA51M2NtCx/bcAdYtHg/01jU bF2q/+gz +Ld2ij4mST/z4lnj4BQZxUkKk4lFCGCwY95c/rWI+VR2I+K2ghx5w6/UnEXl6/7h+/060Xiu9MUFrGPnIqsM47Vaah/apVPAlz8sBJzIooVq+tabehZoew2RmfBCISvkwj0d85vgVIGWjfi7uoSpug9aZ7nKJB2cq2pRPItBg40WkrRbO/rjGD6jFzBqtmHdwGdgfM4uaDJrHUTlF+hy63n96RepnYkgD1Qb1z4ir1JUhVlD7ztVVZL5Np/xJFR9rD5LEHZQUBWJU2fIbOwyw3Uy+wgUacXIgJWKe+dbQCNLDoL0WKgkok0Qiu03sy+bFwtelat3M3/nrSnkqjIQ2S8BsloMUS3oynH81aB4BLB6AfvmWhVHhrJ8Fp7f9IqpOx2Y0zoGCRIg+MQekzpFTwOKLO8MF5yGoZ1Mjg1AoyIwsh+W88U66TlqPAf/23YpOrBu454fKSero6DU8c5wXW6UrRtfV82/bVjXNPC7q/9MUJ+dlEVeg+rFo0wdniWOvdMysdI2G6GIFrZno9wVtmS3jrK+2e9KtGH9mzcu1XKt/YrZCWPsvsCuN4w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 20 Oct 2023 at 05:12, Jeff Layton wrote:. > > I'd _really_ like to see a proper change counter added before it's > merged, or at least space in the on-disk inode reserved for one until we > can get it plumbed in. Hmm. Can we not perhaps just do an in-memory change counter, and try to initialize it to a random value when instantiating an inode? Do we even *require* on-disk format changes? So on reboot, the inode would count as "changed" as far any remote user is concerned. It would flush client caches, but isn't that what you'd want anyway? I'd hate to waste lots of memory, but maybe people would be ok with just a 32-bit random value. And if not... But I actually came into this whole discussion purely through the inode timestamp side, so I may *entirely* miss what the change counter requirements for NFSd actually are. If it needs to be stable across reboots, my idea is clearly complete garbage. You can now all jump on me and point out my severe intellectual limitations. Please use small words when you do ;) Linus