Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp2410436rwe; Sun, 28 Aug 2022 10:39:40 -0700 (PDT) X-Google-Smtp-Source: AA6agR4HC4VoacjO0SVFW5LMuE7FLnnVOWuTINZXnyG+o2o5wB2zkwWN7zUiDVlDxlvlh7N9QNIg X-Received: by 2002:a17:907:3f1f:b0:73d:90ae:f800 with SMTP id hq31-20020a1709073f1f00b0073d90aef800mr11283036ejc.466.1661708379732; Sun, 28 Aug 2022 10:39:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661708379; cv=none; d=google.com; s=arc-20160816; b=EDY27VYMMCvIEQkIQBmdRjwX8AwYG6OBnbkLoFCTnRYJuLJpwFN8hPYdSCBI2I0d/8 R0NkWzJPcW1CWdfCs8H3yVSttS7RjsGdi9NX8RKN5LCFeena9zVE7gPgDNzx+r8D6Hso AgSNmIz+J215BhG0e4ppuzaQH1OYPsL3wqBjKdvkAZXkohHE+BV4ccmm/xEcbgsa+wEU rCQ/eZ+jpj3FAVEgYGgnrMM+BjHK52CTJGGVAP9A1WVvuBL/PGwQjRGaAcp+LusZZyct YWhIPa6KU4URiDWfpFvhM+MwNkeTzEYmjx8J1eJ1NWVx45TWqX5xZcDEsUDMx+e6RzaP bX+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=rC/kcvyTRMZn63lmOJ8Yw6MSQcVtIHue9Gs8f5KhzxI=; b=aPt4kgjtYFslYLv3wYb2Ssa7y6KtH9Ug70jJLKSzZYWRf3ToS7mVmW5xp5cty7auwB mPfLL60VhP4Ui65DsDoio8XUFJ1GuJiT6ITdz0Hp+xn7/SYxzyf2lW9W3c8ChbH8CeLw f/dT4utUL1+FetQgxeYzEmqQJCepcv0MAeAu9bLa4bY4huYkgDY9T3vl8uaqRGUQe5aO sgwwo0r31jV0N0GksqkXCO6q57nGaKlwewTeCGdpuPp9Sq/eUXaQhlsJUTVZ5sLz+4vm rFYHlV8afffdn3ycOejrLSzwGgh5I/8yKP1G2jzh98v5LZwUwvfDl//kyjkto7yOC8I0 Zt7w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=QiXycj2F; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dt22-20020a170907729600b0073dc0a15a6asi5036154ejc.8.2022.08.28.10.39.05; Sun, 28 Aug 2022 10:39:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-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=@gmail.com header.s=20210112 header.b=QiXycj2F; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229921AbiH1RaV (ORCPT + 99 others); Sun, 28 Aug 2022 13:30:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51204 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229522AbiH1RaV (ORCPT ); Sun, 28 Aug 2022 13:30:21 -0400 Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9A4E7641; Sun, 28 Aug 2022 10:30:19 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id c3so6322879vsc.6; Sun, 28 Aug 2022 10:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=rC/kcvyTRMZn63lmOJ8Yw6MSQcVtIHue9Gs8f5KhzxI=; b=QiXycj2Fdgnnrcm4Yd55Jnz3ZDDRPTXPBhcd/BxbbSyT3Zj+SXca6TuWA3S9oQYIpK +DiNwzR4IFUcCb7F93FMJvDvLeKJE1idtoAe7Z7+HxoCXOYDxacZA86EHf0KbFyIF/Uy BPoEEGpBZ0ykd4SmaC1S+kWWUyPoeA8Za81JF+uKMOeoHbf7wjWIyYIrDxuESx6uaiD0 nuAqZ9Dd5iytqXuVa+Yl6Obc9b6h6cEANAN4FCVBoi81wp93z2O3BTXvqwFgQrENj2GK ODpG5xkdP+LrQLZXOK7+xcWTXmwoQc4EIhtXhI4QTJsmbChg+T/6xKH9jzGdBoprGUPi qa/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=rC/kcvyTRMZn63lmOJ8Yw6MSQcVtIHue9Gs8f5KhzxI=; b=G41h19QUFyVaeevEK2nMq07L+sjWbqN9qcGoL5fAO6gO5QjSkEX7mMDH5cinaNwllS 8/vAHfKrJDL6BvmRjGAhSfAElIJnvuRZ3r/+UBGIEA4Ddd+0B2LWFoeCqes2SoS8H93V JbPNZGvoZZIpnPsiQIfabe0wIkUIoZ0aDm7CESNAa4XjDFZ8kXMfJ9eE66ktHgugmXba /4Axqp43nPwZZw1Ri3KQZNtxJA9JAk2fXm24hBta+wOnGwlv0p4bSNPWmepeULW47EF8 Ufc4F+GxsvGHYRdTfbZyX8swmZt7zb+CAM6KEz81iY4hFG8kigD89qwRGlh+PpccYDi0 y3bg== X-Gm-Message-State: ACgBeo1Rm9TfTRcApnlj4MkOX1HlgUsYG4smilvYqBg/yInzHGfuBsPA FjaAtL/ASUMApGzpC9HBJOQ3mqYhkVu4/F0Z6r4= X-Received: by 2002:a67:a649:0:b0:390:88c5:6a91 with SMTP id r9-20020a67a649000000b0039088c56a91mr2450540vsh.3.1661707819049; Sun, 28 Aug 2022 10:30:19 -0700 (PDT) MIME-Version: 1.0 References: <20220826214703.134870-1-jlayton@kernel.org> <20220826214703.134870-5-jlayton@kernel.org> <35d31d0a5c6c9a20c58f55ef62355ff39a3f18c6.camel@kernel.org> In-Reply-To: From: Amir Goldstein Date: Sun, 28 Aug 2022 20:30:07 +0300 Message-ID: Subject: Re: [PATCH v3 4/7] xfs: don't bump the i_version on an atime update in xfs_vn_update_time To: "Darrick J. Wong" Cc: Jeff Layton , Theodore Tso , Andreas Dilger , Dave Chinner , Trond Myklebust , Neil Brown , Al Viro , Mimi Zohar , xiubli@redhat.com, Chuck Lever , Lukas Czerner , Jan Kara , Christian Brauner , Linux API , Linux Btrfs , linux-fsdevel , linux-kernel , Ext4 , Linux NFS Mailing List , linux-xfs , David Wysochanski , ceph-devel Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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: X-Mailing-List: linux-ext4@vger.kernel.org > > > > > > > > Forensics and other applications that care about atime updates can and > > > > should check atime and don't need i_version to know that it was changed. > > > > The reliability of atime as an audit tool has dropped considerably since > > > > the default in relatime. > > I've been waiting for Amir to appear in this discussion -- ISTR that a > few years ago you were wanting the ability to scan a filesystem to look > for files that have changed since a given point. If XFS exported its > di_changecount file attribute (as it currently behaves) via BULKSTAT, > you'd have the ability to do that, so long as your application could > persist bulkstat data and compare. > It's true that exporting i_version via BULKSTAT could be useful to some backup/sync applications. For my case, I was interested in something a bit different - finding all the changes in a very large fs tree - or IOW finding if anything has changed inside a large tree since a point in time. So not sure if i_version would help for that use case. Thanks, Amir.