NeilBrown wrote:
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
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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
