Gary: A volume can either be read/write or readonly. Only one file server can maintain a copy of the read/write volume but multiple file servers can maintain a copy of the readonly volume.
Callback state is not shared between servers. The callback registrations are promises by the file server to notify the client if a change in state occurs on the referenced object. A file server will send a callback to a client with a valid registration if the metadata changes, the data changes, a lock on the object is dropped, the ACLs on the object change, an availability change, or if the file server is abandoning its promise due to lack of resources. You can find the callback interface in source files src/viced/callback.[ch] 32 bytes per callback and 32 bytes per file object referenced by a callback. Jeffrey Altman gary mazzaferro wrote: > Thanks Derrick, > > So basically, its one callback state per file and one per RO volume. I'm > assuming that the server with the RO volume will not be maintaining the > state of the server with open files and likewise the server with open > files will not be mainataining the state of the RO volumes. > > So, the question is... what is the resource consumption for each > callback state ? > > cheers > > > > On Sat, Jan 10, 2009 at 7:58 AM, Derrick Brashear <[email protected] > <mailto:[email protected]>> wrote: > > > Can anyone tell me how to calculate the memory requirement for > each client > > on a server ? > > Not without more information. The state information is stored per > callback, which is one per file/directory in a writable volume, and > one per entire readonly volume, so without knowing what the client's > utilization will be, I can't say. > > > > Are the file ACLs the underlying native ux ACLs or are AFS's file ACLs > > layered on top ? > > AFS acls are by directory. Unix mode bits are there but not enforced > by AFS. > > > > The question is really for eval'ing AFS over ZFS and direct > support for > > WIndows/Samba ACLs. > > > > Is there a time table for the file ACL support ? > > Some work was done last summer but to the moment there has been no > further progress, and the work from last summer at this point is > effectively only design work. > _______________________________________________ > OpenAFS-info mailing list > [email protected] <mailto:[email protected]> > https://lists.openafs.org/mailman/listinfo/openafs-info > >
smime.p7s
Description: S/MIME Cryptographic Signature
