Jim Rees wrote: > Jeffrey Altman wrote: > > For each vnode in the cache, you keep track of the > connected/disconnected state. While you are in the transition from > connected -> disconnected you sync files into the cache and mark them > disconnected. When a request comes in for a file marked disconnected, > you treat it as if disconnected mode was active. > > But that wouldn't guarantee the consistency that Simon wants. If you have > two files in your cache A and B, A is disconnected and B is not, then some > other client writes both files, you will have the old copy of A and the new > copy of B. How is that any different from an implementation that does not > obtain a callback on all files before disconnecting?
What are the use models for disconnected mode? (1) Organization A that wants to deploy applications to desktops via AFS. The applications are deployed using .readonly volumes. One callback for the entire volume. In this situation when the user switches to disconnected mode, the entire contents of the volume will be marked disconnected at once. Everything will be in the cache and it will all be consistent. (2) User wants access to specific files or directories from r/w volumes. Whether or not the client obtains perfect consistency is dependent upon how many files/directories there are, how many file servers are involved, and how many files are in each directory. However, it is easy enough to guarantee consistency of all the files in a given directory with a bulk stat before and after the synchronization. Is it absolutely perfect synchronization across the entire AFS file system name space? No. It is localized synchronization. Is there a chance that a user can still end up with a useless file? Absolutely. For example, what if a user synchronizes a file that is currently in use by another user where the file has had partial writes applied to the file. I think the perfect example is a Microsoft Office document. The file was opened, modified, and then most of the data was placed into a temp file until the application closes the file and stops working on it. Given the lack of proper lock semantics there is little that can be done to protect against this. Once we have mandatory locks available the cache manager won't need 1000 callbacks, it will simply need the ability to obtain read locks on all the files it wants to synchronize in a given set. Part of the responsibility of the disconnected UI is to provide the user with the ability to specify what subsets of the AFS name space are required for synchronization. Selected items that are grouped together can be obtained together as a set. Those that are not grouped together can be obtained separately. The primary problem with the existing disconnected mode is that the entire contents of the cache is offered for disconnected use whether or not the cache manager has any idea how old the data is and whether or not there is any chance that the data might still be valid. Its simply a question of what happens to be in the cache at any given time. Jeffrey Altman _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
