 |
 |
Actually, this reminds me. The GridPP UB page should have UK contacts for each experiment. Durham should contact them too for the data they want moving in case the central contacts do not respond. John -----Original Message----- From: LHC Computer Grid - Rollout [mailto:[log in to unmask]] On Behalf Of Rod Walker Sent: 20 September 2005 20:10 To: [log in to unmask] Subject: Re: [LCG-ROLLOUT] Removal of Files from Durham SE (gallows.dur.scotgrid.ac.uk) Hi, I`m talking about Atlas Tier 1's, and these will have someone in the atlas VO. Anyone in the Atlas VO can replicate and delete Atlas files - tragic but true. There are tools to do this and I`m afraid people need to get their hands dirty. I`m thinking the Atlas T1's must have some responsibility to service the sites in their area who accept the Atlas VO, bearing in mind that some of those sites will not have local Atlas people. This cannot be done centrally, and the Tiered system must be something more thatn a funding construct. Changing a site name, or root path, shouldn't difficult in either the distributed or cental calalog model. It is made more awkward when the host and root path are buried in the sfn. I think this is still the case with LFC and from a (laymans) Db design perspective is perverse. Traditionally you would have a table, SITE HOSTNAME ROOTPATH, and only reference the SITE in the sfn. Cheers, Rod. Ps. The Atlas dataset location catalog will contain references to the local LFC's presuamably by hostname. We should certainly have table similar to the above so that host changes can be made in 1 place. The full sfn is only stored in the site LFC and every entry would need to be changed if the host or path changes. Pps. We certainly must use available disk space at T2's. I was refering to opportunistically used non-atlas sites with small disk allocations. On Tue, 20 Sep 2005, Burke, S (Stephen) wrote: > LHC Computer Grid - Rollout > > [mailto:[log in to unmask]] On Behalf Of Rod Walker > said: > > This is certainly an argument for having the > > sfns stored in a local catalog, which is the new Atlas DH model. > > It's the model everyone has had since EDG 2.0, unfortunately no-one ever > seems to get around to deploying it :) > > Incidentally, what is your location model - will you have a central > catalogue storing the SE name? If so that would still seem vulnerable to > an SE move. Or do you have some indirection? > > > addition the future system will treat local storage more like > > a temporary > > scratch area, so we shouldn`t be in this situation again. > > That might be true for atlas but it won't be for every VO. And some T2 > sites will have pretty big SEs, it would be a shame if it doesn't get > used ... > > > I`m happy to share my dodgy scripts, but the work must be > > done at least at the T1 level in order to scale. > > If you mean that migration should be done by the T1s alone I don't think > I agree, the T1s generally have no right to modify your catalogues or > move your files around (or indeed deal with your mistakes, e.g. if there > are catalogue entries with no file or vice versa). > > Stephen > -- Rod Walker +1 6042913051