 |
 |
Hi Pete, > So how else do I find the file and replicate it from server X to server Y? > xrootd can send the client to server Y, but who tells server Y that it should > copy the file from server X? Is that some "opaque" information that the client > would bring with it? Well, yes, you can't. But then again, if the machine goes down, it doesn't matter how many servers were running on it. At some point, I think that's going to be more likely than any xrootd falling over. So, as we all suspected, either you need a proxy mechanism (i.e., tre alternate sources) or some oracle to pro-actively replicate files. > But IMO much better than the stupid turd files that get left behind when the > server crashes or is shutdown in some non-clean way. Ah, but you see the turd file at least gives you what the real config was when the server crashed, which is lost when you just keep it in memory. > Now there are two possibilities: > > o the manager olbd _immediately_ tells the server X olbd to check that > files M, N, O and P are still on server X The above is what really happens. I'm not enamoured with this scheme because it potentially creates a bottleneck if servers come and go often (like at CNAF). But when things are running smoothly, it's more effecient. > o the manager olbd notes that the server X olbd went AWOL for a bit and > just marks them as needing to be refreshed in its own cache. The next > time a client comes in to Open the file, it is as if they had done > Open + kXR_Refresh. The above is a technically better solution but it requires 8 more bytes for each cache entry. The logic is relatively complicated because the file may be replicated and you don't really want to force a refresh if you have an alternative source for the file. So, you need to keep track of who should be asked when the time comes to ask. That costs you every time you do a lookup whether or not you refresh. I'll think about this some more and may change the logic to do a phantom on-demand refresh (I may see the light :-) Andy