linux-kernel - Re: (Lack of) i_version handling in udf

lists.openwall.net		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 linux-cve-announce 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:   Fri, 22 Dec 2017 10:54:19 -0500
From:   Jeff Layton <jlayton@...nel.org>
To:     Steve Magnani <steve.magnani@...idescorp.com>,
        Jan Kara <jack@...e.cz>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: (Lack of) i_version handling in udf

On Fri, 2017-12-22 at 08:43 -0600, Steve Magnani wrote:
> Jan,
> 
> Re: [PATCH v4 00/19] fs: rework and optimize i_version handling in filesystems
> 
> On 12/22/2017 06:05 AM, Jeff Layton wrote:
> 
> > The inode->i_version field is supposed to be a value that changes
> > whenever there is any data or metadata change to the inode. Some
> > filesystems use it internally to detect directory changes during
> > readdir. knfsd will use it if the filesystem has MS_I_VERSION set. IMA
> > will also use it to optimize away some remeasurement if it's available.
> > NFS and AFS just use it to store an opaque change attribute from the
> > server.
> > 
> > Only btrfs, ext4, and xfs increment it for data changes. Because of
> > this, these filesystems must log the inode to disk whenever the
> > i_version counter changes. That has a non-zero performance impact,
> > especially on write-heavy workloads, because we end up dirtying the
> > inode metadata on every write, not just when the times change.
> > 
> > It turns out though that none of these users of i_version require that
> > it change on every change to the file. The only real requirement is that
> > it be different if something changed since the last time we queried for
> > it.
> > 
> > If we keep track of when something queries the value, we can avoid
> > bumping the counter and an on-disk update when nothing else has changed
> > if no one has queried it since it was last incremented.
> 
> This happened to cross my radar, which made me think...is it a problem
> that the UDF driver does not have any references to i_version at all?
> I suppose R/W UDF is a small subset of the normal use cases, but the driver
> does try to support it.
> 

I don't think it's really a problem. Mostly we need this for filesystems
that are exported by knfsd to deal with files that change frequently. If
it's not available we just fall back to using the ctime.

-- 
Jeff Layton <jlayton@...nel.org>