In 1.3.8x the cache manager issues a length-zero read RPC to the
fileserver for each new chunk during write whenever the DataVersion of
the file is no longer zero, e.g when some cache clearing has taken place
since the creation of the file, most obvious when writing big files.
BTW, the 1.2.x client does not do this.
The problem is that the cache manager ignores that the write() is going
beyond the end of the existing data. It actually behaves the way the
comment in afs_dcache.c describes - guarding against writes from other
clients - only that
a) the comment is the same in the 1.2.x client, b) AFS never has claimed
better consistency than through close() and c) at best the zero-length
read would make the window smaller during which the actual size of the
file would be unknown, it does not close it.
The attached patch restores the behaviour of the 1.2.x client: writes
appending to a file do not trigger a 0-length read which at best updates
the current status. If another cache manager wrote to the same file in
the meantime, the file status is updated only after the StoreData RPC
(and for the changes the last one wins).
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rainer Toebbicke
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland
Phone: +41 22 767 8985 Fax: +41 22 767 7155
--- openafs/src/afs/afs_dcache.c.0rig Sat May 8 06:33:07 2004
+++ openafs/src/afs/afs_dcache.c Fri Sep 3 08:40:16 2004
@@ -1815,7 +1815,8 @@
ICL_HANDLE_OFFSET(Position));
if ((aflags & 4) && (hiszero(avc->m.DataVersion)))
doAdjustSize = 1;
- if ((aflags & 4) && (abyte == Position) && (tlen >= size))
+ if ( (AFS_CHUNKTOBASE(chunk) >= avc->m.Length) ||
+ ((aflags & 4) && (abyte == Position) && (tlen >= size)) )
overWriteWholeChunk = 1;
if (doAdjustSize || overWriteWholeChunk) {
#if defined(AFS_AIX32_ENV) || defined(AFS_SGI_ENV)
