 |
 |
Hi Andy, we just had a weird config issue, which now should be fixed. But we have the idea that there is a little more to do about the cache file system, just to be able to build clusters which serve more than one purpose (e.g. prod and skim for BaBar). Issue 1: suppose that you have a cache file system with 2 dirs, where you want to write: oss.cache public /kanga/prd1 oss.cache public /kanga/prd2 it seems that if one directory of the cache file system is not writable (e.g. prd1 by mistake) the data server can choose to use it anyway, causing problems. It should detect this and choose the other one. Issue 2: let's suppose that we want 2 cache file systems in a data server, to avoid the "flat" allocation made by the server. Here is an example: oss.cache skm /kanga/skm1 oss.cache skm /kanga/skm2 oss.cache prd /kanga/prd1 oss.cache prd /kanga/prd2 xrootd.export /prod xrootd.export /skim The config documentation says (or, at least I understand from it) that you can pass (through the open request) the oss.cgroup directive via opaque information specifying the cache group you want to write to. Well, we were unable to make it write /prod to the cache group "prd". It seems that the server always arbitrarily chooses the cache directory it wants between all the entries. Anyway, even if we make it work, or even if we understand why we were not able to, the best solution possible imho would be to associate a cache group to an exported directory, maybe in the xrootd.export directive. e.g. with directoves like: xrootd.export /prod prd xrootd.export /skim skm it could be possible to tell to the server to use the cache group "prd" to write /prod data, and the cache group "skm" to write /skim data, avoiding the fact that the files inside the cache fs are put all together. What do you think? Fabrizio