Re: [PATCH] vfs: report an inode version in statx for IS_I_VERSION inodes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bigger picture, I think eventually I'm going to rework stuff related to my use case to be more similar to the container stack, specifically using overlayfs; so it's quite possible by the time iversion is exposed to userspace, I won't have any strong want/need of it myself.

On Thu, Aug 25, 2022, at 3:48 PM, Jeff Layton wrote:

> IOW, should this value mean that something _did_ change in the inode or
> that something _may_ have changed in it?

In my case it's basically the same as IMA - we want to only compute the sha256 digest of files that actually changed.  Some false positives are hence OK - but that also means the usefulness of the feature degrades in proportion to that number.

A bit more detail:

I didn't deep dive into the XFS mention about internal/background iversion changes, but AIUI at a high level it sounds like those iversion changes happen mainly (only?) when the file is recently created and pending writeback, which doesn't seem like a problem in practice.  I do agree with Ingo's old quote about atime though in https://lwn.net/Articles/244829/ and this thread reminded me to use `noatime` on my main workstation (again; I'd recently changed how I provision it).







[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux