lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 28 Aug 2022 20:30:07 +0300
From:   Amir Goldstein <>
To:     "Darrick J. Wong" <>
Cc:     Jeff Layton <>, Theodore Tso <>,
        Andreas Dilger <>,
        Dave Chinner <>,
        Trond Myklebust <>,
        Neil Brown <>, Al Viro <>,
        Mimi Zohar <>,,
        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 <>
Subject: Re: [PATCH v3 4/7] xfs: don't bump the i_version on an atime update
 in xfs_vn_update_time

> > > >
> > > > 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.


Powered by blists - more mailing lists