[EMAIL PROTECTED] writes:
> We've added a little feature in afs3.4 that may help alleviate this
> slow response time. The client can be made to return immediately on
> "close" of a file using "fs storebehind", so the copying back is done
> asynchronously. Note however that now you cannot be sure that the file
> did make it back safely (eg, if your quota on the volume was exceeded,
> the async write-back will fail and the client is forced to drop the
> file on the floor).
Actually, it's not *quite* as bad as that.
The file server does check quotas and permissions and breaks callbacks
before proceeding. Since you can get nailed by outages or race
conditions, you wouldn't want to enable this for files whose contents
couldn't be recreated, and a lot depends on how reliable your networks
and servers are.
peter honeyman <[EMAIL PROTECTED]> writes:
> i was under the impression that afs has always let the storedata complete
> asynchronously if the file is one chunk. (maybe this is why you wanted to
> know his chunk size ...) afs3.4 puts this under user control, i gather.
Now the adjacent chunks get coelesced into a single RPC, and the final
RPC can complete asynchronously to close() if so desired. The default
is for all files to be stored _synchronously_.
