Re: i_version changes

[Peter Staubach <staubach@redhat.com>]

NeilBrown wrote:
> On Thu, February 14, 2008 8:32 am, Peter Staubach wrote:
>   
>> I don't think that this is quite true.  If the file is changed
>> when the NFS server is not running, then the value of i_version
>> which is used when the NFS server starts up again must be
>> different than the value which was previously used when the NFS
>> server was previously running.
>>     
>
> As I said, the "NFS has seen this i_version" flag needs to be on
> stable storage, e.g. the lsb of the i_version.  This will ensure that
> any change after NFSD saw the i_version will cause the i_version to
> be updated.
> So I think it can provide correct semantics.
> Precise details:
>   NFSD: when reading i_version
>       take lock
>       tmp = i_version
>       i_version |= 1
>       drop lock
>       return tmp & ~1;
>
>   VFS when making any change:
>       take lock
>       if (i_version & 1) {
>            i_version++;
>            changed=1
>       }
>       drop lock
>       if changed, sync inode
>
>   

Yes, this does seem like it would do the job.  It could perhaps
be optimized somewhat to avoid lock contention, but I do think
that this would suffice.

>   
>> Is the perceived performance hit really going to be as large
>> as suspected?  We already update the time fields fairly often
>> and we don't pay a huge penalty for those, or at least not a
>> penalty that we aren't willing to pay.  Has anyone measured
>> the cost?
>>     
>
> Correct NFS semantics require that the i_version be written to disk
> before (or when) the change is committed.  That means lots more inodes
> in the journal.
> If you are already doing data=journal, it the hit probably isn't too
> high.(?)
>
>   

Correct NFS semantics also require that any modified metadata,
including file times and file size, also be written to stable
storage.  Isn't this just another piece of modified metadata
that would go hand-in-hand with updated file times?

We should also require that the file mtime change when the
contents of the file are modified.  This should happen whether
or not the clock has ticked.  Unfortunately, to implement this,
we would need file time resolutions which are smaller granularity
than the system clock.  We could probably get away with nano-
second resolutions in the file system.

    Thanx...

       ps

> You are right:  measuring the cost is important.  However as we are
> designing a generic filesystem interface, we need to understand the
> cost on multiple filesystems in a variety of configuration .... or
> give the filesystem complete information and let it decide the optimal
> implementation.
>
> Giving the filesystem full information means having an inode_operation
> "nfsd_reads_version" which returns the number to be used as change_id.
>
>
> NeilBrown
>
>