Message-ID: <82157aa3-ec0b-25e6-517b-704a3f81ec61@auristor.com>
Date:   Sat, 16 Dec 2017 11:18:41 -0500
From:   Jeffrey Altman <jaltman@...istor.com>
To:     Jeff Layton <jlayton@...nel.org>, linux-fsdevel@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
        linux-nfs@...r.kernel.org, bfields@...ldses.org, neilb@...e.de,
        jack@...e.de, linux-ext4@...r.kernel.org, tytso@....edu,
        adilger.kernel@...ger.ca, linux-xfs@...r.kernel.org,
        darrick.wong@...cle.com, david@...morbit.com,
        linux-btrfs@...r.kernel.org, clm@...com, jbacik@...com,
        dsterba@...e.com, linux-integrity@...r.kernel.org,
        zohar@...ux.vnet.ibm.com, dmitry.kasatkin@...il.com,
        linux-afs@...ts.infradead.org, dhowells@...hat.com
Subject: Re: [PATCH v2 05/19] afs: convert to new i_version API

Hi Jeff,

A few thoughts on AFS usage below which might impact a future revision
of the API.  I hope they are useful.

On 12/16/2017 8:49 AM, Jeff Layton wrote:
> On Sat, 2017-12-16 at 08:46 -0500, Jeff Layton wrote:
>> From: Jeff Layton <jlayton@...hat.com>
>>
>> For AFS, it's generally treated as an opaque value, so we use the
>> *_raw variants of the API here.
>>
>> Note that AFS has quite a different definition for this counter. AFS
>> only increments it on changes to the data, not for the metadata. We'll
>> need to reconcile that somehow if we ever want to present this to
>> userspace via statx.
>>

From the patch series notes:

"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. [1]"


The AFS/AuriStorFS data version is an unsigned 64-bit value that is
incremented by the file server as part of a data changing operation. For
files, a StoreData and for directories entry manipulations such as
create, rename, delete.  This data version is used to tag the version of
any subset of the data stream for caching and replication purposes.

As Jeff notes, the AFS data version is not incremented for metadata
changes.  Metadata cannot be trusted by clients without acquiring a
callback promise from a fileserver.  The callback promise will either be
satisfied by the issuing fileserver sending a CallBack notification that
the metadata is no longer valid OR the callback promise will expire.

Something else that is important to note that it is assumed that local
data changes that occur under a valid callback promise is newer than the
data on the fileserver.  It might be useful if the new i_version API
supported major and minor version numbers.  AFS implementations would
store the fileserver provided data version number as the major version
and would increment the minor version when local changes have been made
which have yet to be stored back to the fileserver.  This functionality
would be especially useful if disconnected operations were implemented
for the AFS implementation.

It might also be useful to separate metadata version and data version
although some filesystems would set the same value to both.  For AFS,
the metadata major version would the timestamp at which the callback was
issued.

Jeffrey Altman

View attachment "jaltman.vcf" of type "text/x-vcard" (396 bytes)

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4056 bytes)

Powered by blists - more mailing lists