From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <1513958059.3426.12.camel@kernel.org> Subject: Re: (Lack of) i_version handling in udf From: Jeff Layton To: Steve Magnani , Jan Kara Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Date: Fri, 22 Dec 2017 10:54:19 -0500 In-Reply-To: <19f848dd-aa94-70bc-73b2-4c1d8b352636@digidescorp.com> References: <20171222120556.7435-1-jlayton@kernel.org> <19f848dd-aa94-70bc-73b2-4c1d8b352636@digidescorp.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: 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