Harald Barth wrote:
When I write (copy) a file to AFS, it's like (from the userland)

     open()
     write() # to cache
     write() # to cache
     write() # to cache
     close() # write to server

As we know, the data is first cached and then sent to the server on
close(). If now the networks fails half way during the close, the
close returns an error (which is OK), _but_ the file in the cache is
considered valid on this client but may be in a different state on all
the other clients. Would it not be better to flag the file as
"callback expired" when aborting a close due to unfinished transfer to
the server? This would for example not trick a subsequent md5sum into
believing that everyting was OK with the file in the cache. Same
thoughts apply to mmap().

If it does matter: Client version is 1.4.5 on Linux 2.6.23.

Harald.

In my opinion, the data should either be flushed to be
server in the background or it should be invalidated.

The Windows client will flush the data in the background
until such time as the data version on the server was changed
by another client.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to