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]
Message-ID: <19f848dd-aa94-70bc-73b2-4c1d8b352636@digidescorp.com>
Date:   Fri, 22 Dec 2017 08:43:40 -0600
From:   Steve Magnani <steve.magnani@...idescorp.com>
To:     Jan Kara <jack@...e.cz>
Cc:     Jeff Layton <jlayton@...nel.org>, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: (Lack of) i_version handling in udf

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>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ