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 E7674C0032E for ; Fri, 20 Oct 2023 20:21:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6ADA4280005; Fri, 20 Oct 2023 16:21:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 63757280004; Fri, 20 Oct 2023 16:21:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D798280005; Fri, 20 Oct 2023 16:21:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 3ABAD280004 for ; Fri, 20 Oct 2023 16:21:42 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0CAE5A072A for ; Fri, 20 Oct 2023 20:21:42 +0000 (UTC) X-FDA: 81366960444.05.64FBB7A Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf10.hostedemail.com (Postfix) with ESMTP id 11808C0024 for ; Fri, 20 Oct 2023 20:21:39 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=XlekCBZZ; dmarc=none; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.49 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=1697833300; 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=XP/w2rcRgohzEDCbF3zAswI8lw4+mMJo52iF5/bT45w=; b=6eTIQJhhU3XEn24lgi98TwQJLdA+KOabyLfqy5uLQ0sQ0QoM7bQ5kZLu+02v/d3bRNsDX0 7h/l31YwvpZ4KWflFmpBjyULyg7LhGd/SxwVpGY7Dv6pGvNApbVMGB/nxhxLpFJceeIvXP jqdHdWLBNPcEH8WVHRFpqoFOU8WducY= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=XlekCBZZ; dmarc=none; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.49 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697833300; a=rsa-sha256; cv=none; b=Ta1iX9DmyPj3umVeEeTFH54KnnsOjYBckiBVt8rmBWTFomY66WNboJEc8zmjktemtmJSAf VLrJN58VIh0I7KPuB5IPSOQpN2P1C0BlH8RbakOEmq/Uqe7gWsvuc7T9YfL1PDaAwAcKWf eHH7qE4uikx+/KrWV+JStlGajenhj2E= Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-99c1c66876aso189595566b.2 for ; Fri, 20 Oct 2023 13:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1697833298; x=1698438098; 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=XP/w2rcRgohzEDCbF3zAswI8lw4+mMJo52iF5/bT45w=; b=XlekCBZZOTSF3hIvcn3kPEtTdd96M53UUczXo/d4CMQcs7LtWhXqkxAoBkP9K8hx/V GYh92bnGRDVdqRhC378PrNj8v2m657eWmZq3EmLeiAI+sAeRiEKC36P+m3WXPFQ9DefS wixG1KVNQ2ifGGZaZjp0FaPLWBDln9X4MYzeY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697833298; x=1698438098; 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=XP/w2rcRgohzEDCbF3zAswI8lw4+mMJo52iF5/bT45w=; b=vlV2gJodKuul4okqv/ClF70ju/6Bquc9wC0wyRZ7aoOaZzwNELJL1CkoVA0jch1PBw T2xVkt9aR/aQL4eeOm5we7Mr9Z/9wwMRu3IO14aAHeTy44V4llXlL+58B8tEsU7suMaP CuNoFJ0BFDACCrp7OVjwYka36w7kVyeOHTim/c2ag/Y4NmdTLvEZ1eW8lA+WdZCptEBl 5WuPchXpVLqA9/eFRtiGcwD8a4WXbauldLj0gm6+5EQyJk1mzxWxajbaVIMYcfRYgTCT 91Zj8d1wcdVql+x2CE2Z62HMBnmFca1orEH3uZAQ/DX4cY5KeXebFmwsarzA7e9unzKf hKPA== X-Gm-Message-State: AOJu0YxmsRdk3QUqHySZlbiizEMVyit0HIWUqCorVkddKWdZYbFKjzR4 z6jypm8MTyj6hTjbTKLklcMWeOh3t8Ir3MdzogmSPQyt X-Google-Smtp-Source: AGHT+IFOkWHMxIUpBqDDrlfLsjjvGP9CR1G7FfAwmI8N31mAzwNL/azYPaaLxFtO5spnT4vhN7oYUw== X-Received: by 2002:a17:906:9c83:b0:9a1:bd33:4389 with SMTP id fj3-20020a1709069c8300b009a1bd334389mr1987014ejc.74.1697833298204; Fri, 20 Oct 2023 13:21:38 -0700 (PDT) Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com. [209.85.208.52]) by smtp.gmail.com with ESMTPSA id t15-20020a1709066bcf00b009a13fdc139fsm2100017ejs.183.2023.10.20.13.21.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Oct 2023 13:21:38 -0700 (PDT) Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-522bd411679so1837590a12.0 for ; Fri, 20 Oct 2023 13:21:37 -0700 (PDT) X-Received: by 2002:a17:907:7e9e:b0:9ae:50e3:7e40 with SMTP id qb30-20020a1709077e9e00b009ae50e37e40mr2195962ejc.52.1697833276793; Fri, 20 Oct 2023 13:21:16 -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:20:59 -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-Rspamd-Queue-Id: 11808C0024 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: bhbunw9y6seqsgahtiqfijchey37ssq8 X-HE-Tag: 1697833299-257708 X-HE-Meta: U2FsdGVkX1/1tITWVdGNyFiDRNWqKEtuZyfCxJL9cWYiwJFU7+xRTCKSO+lcOwJHtSGwICNOQe7zF3xP08fjTX/Ynpb9kRABpWS5flfyTw3LLEX9U7z2uTxwZDet3VL+a5HlYPTPYBi3ThI9qunqFEk1ZeAfg/cNhuOZpsOf5dCzpIC0lp2x3KMOYOE/e1/cmCM1QCLGFIvPx8Mpp/TbU2v0/WrEAsQt9xkOvFOjMzcdLrCZFwcMSe3HxfEwl5c3AUSdaMFXpl//GYDlgn/Mn5gViQDeStuSmnbsKvb+5PcrMQjk+S+RSOaycco1JNlegbzCrlUw/pDVUo+yREMgl+CHGWDUDJ3sMCLqHk0k2Z/v+Fc04W8pzpa14wY6d8WvA/9L/W4yo/faVLYkn9AowFK7x/TLSqZCucYZCC8+D93lDOz/rciziO00m6GmVNSMTLekQMUo/cDBR6ddSAb/o9pKlBpzH5YanWzJ8vfVOwG4DwIJaN+Ed3+qHr+YvoUNPlnyOM0+Tktj5jI55EVuXgo/wkbjUhxNqRbjfsHj/1g+YCFJHTn1ZTM9/wS9qIH3jPyXyfcihUh8+Vi7n+G79MD+Ti8591GtZCaneNhcY8gcwkIpbSS6VZQl/Gug1P9cq5tMOx42iHONZyZrU7/TEujXXwpeL0z6tb5Cxoo4qdy8F9bYweUtNLBjTp4qEN20+FnD1c2q2s5eR4g2YUPqSgc5KNHswCiWuqjMKQLtwWl2KN9vmVtain1gj/SEbXAyUhKrKAfe4A/n8b1xVRXnPzW+zQpblmW9UxNjIyaHoM3JsaWEIELUmCmbx86R4M8g9tBv/a3i094WTka7fuSv3iHsVtO6Ip1XzHAseOfYwBHnttQLDHsWXR/moatNfphEddN9G7aERJivaip4+UfF4D5sMZdumG+BSaILaCqeXFYrgfoVC0k7vpHvm3+aNoVMUSE3z0apO1TWgbTvgN2 7BubJ3Ld OFKsAyBTS7M46Z1XWxhDo2YdjcGoXiftnYaYlcBseZ2yFjyjBd0t3EdUIMNprgY0D3shafWRJ9uMIZCCxobhDnOZchPacClawbGiekENimzffoEfmLOeh9Dg384cHOg5eGAC3xmfL3LoQqOgJtX2x1pnTfKAKI2qzxWFz6D9Oqe8pppdD0qmEzHnatLJ4JpWSjKd6fl6xWPbL3cKq2ukLvCJFjZ8nOtqE2oK5hWX51Ko7qDXil0mkscPhCTh/ZFRX+yzQn2LsNQpxPPlvv3VblbZt2pBkonFc+aXbA1Spn4PwJEk5mfxNZeSMKmsOK9ZRJrfIviOFNBqK/gelTf8Ozb97R0zlTvek5bvg/tcdFqSOf1Ag/9Wz2k9wIjUgQkXy5wLeFKXuhQyL+76Fq7pNPXKpFa+rxI44ZuNgxDbg77pvmJGrBNgIO2xYH8wj7jIRCmvIRkRckGr/dajNJiGXloyQhYocEgWdioayVMzSRkjUpV4osiUMtsNUx9+TwugE9RX5aW+Z97SWjqX6Hw/ltjO9kzS1FC22gZI8S9DmwFCxs/KV5RNY2ncVbVUHrbm9AlamTtyOhKNYTP0= 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 13:06, Linus Torvalds wrote: > > So on reboot, the inode would count as "changed" as far any remote > user is concerned. [..] Obviously, not just reboot would do that. Any kind of "it's no longer cached on the server and gets read back from disk" would do the same thing. Again, that may not work for the intended purpose, but if the use-case is a "same version number means no changes", it might be acceptable? Even if you then could get spurious version changes when the file hasn't been accessed in a long time? Maybe all this together with with some ctime filtering ("old ctime clealy means that the version number is irrelevant"). After all, the whole point of fine-grained timestamps was to distinguish *frequent* changes. An in-memory counter certainly does that even without any on-disk representation.. Linus