Messages in this thread | | | Subject | (Lack of) i_version handling in udf | From | Steve Magnani <> | Date | Fri, 22 Dec 2017 08:43:40 -0600 |
| |
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.
Regards, ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!"
#include <standard.disclaimer>
| |