NeilBrown wrote:
quoted text
> On Thu, February 14, 2008 7:26 am, J. Bruce Fields wrote:
>
>   
>> It's not OK to update it only sometimes.  If updates are made while nfsd
>> isn't running, those needed to be reflected in the change attribute, so
>> the changes aren't missed when nfsd comes back up.
>>     
>
> For NFSD's needs, it is only necessary that changes in i_version that are
> potentially visible over NFS actually be stored on disk.
>
> You could come up with an interface where NFSD sets a flag when it reads
> i_version, and changes to the file only change i_version if the flag is
> set (at which point the flag is cleared).
>
> This would give fully correct NFS semantics, and no overhead when NFS access
> is not in use
>
>   

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.

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?

    Thanx...

       ps

quoted text
> This flag would need to be stored in stable storage too, so probably easiest
> to make it the least significant bit of i_version.
>
> Of course then the semantics of the new i_version are very different to
> the old i_version, so maybe we need two fields in the inode....
>
> NeilBrown
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html