Jeffrey Altman wrote (Fri Jul 24 2009 17:39:44 GMT+0200 (CEST) ) > Hartmut Reuter wrote: > >> I can't use the vnode->lock for this kind of locking, anyway, because >> the End-of-I/O-rpc wouldn't run in the same thread. So I have planned a >> counter for ongoing reads (write can only start if that came down to 0) >> a counter for waiters (to know whether End-of-I/O-rpc has to wake >> someone or just can free the struct) and, of course a writer field which >> contains the ip-address of the writing client or 0 if there is no write >> in progress. >> >> But all these are implementation details which have nothing to do with >> the AFS3 protocol and can be changed later if it seems appropriate.
<snip> > The > RXAFS_OSD_StartFetchData/RXAFS_OSD_ExtendFetchData/RXAFS_OSD_EndFetchData > and > RXAFS_OSD_StartStoreData/RXAFS_OSD_ExtendStoreData/RXAFS_OSD_EndStoreData > rpcs are going to have exactly the same issue as > SetLock/ExtendLock/ReleaseLock rpcs. Jeff's point is that we must not > repeat the same mistakes from our past. Adding such additional RPCs is fine, and OSD-aware clients will be capable of using them. I believe that what Hartmut proposed is a means to also keep legacy clients from messing up data and dataversions. The fileserver's ability to do so is limited, and for that particular usecase, no additional tokens of identity can be introduced, anyway. Of course, given that the fileserver is responsible for data transfers to and from the OSDs in this case, it could just obtain an appropriate lock on the client's behalf. I'm not entirely sure about the semantic implications of such a scheme though. Maybe I'm also over-thinking this quite a bit... Regards - Felix _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
