Brief notes from CCRC08 Storage Solutions Working Group of 11 Feb 32008 Agenda with attached material at : http://indico.cern.ch/conferenceDisplay.py?confId=28791 Present: J.Shiers (chair), H.Renshall (notes), F.Donno, J-P.Baud, M.Branco, A.Pace Phone: P.Fuhrmann, G.Oleynik, M.Ernst, D.Petravic, T.Perelmutov Addendum to WLCG SRM v2.2 MoU: JS explained his intention that this be a lightweight addendum that would detail what has to be changed, with this being based on operational experience, and that this would then be checked by the technical people. Implementation of the agreed changes would then start. GO pointed out that Mat Crawford suggests a written report on how the eventual proposals in the MoU addendum are arrived at and JS agreed with this, especially given the recent budget issues at FNAL. SRM v2.2 key concepts, methods and behaviour: FD presented her slides (attached to the agenda). The idea is to establish short, medium and long term goals with associated dates. The immediate short term goal is to select tape sets by means of tokens or directory paths. She thought dcache was in good shape for this after patch level 5 which allows to pass tokens to the migrator. For Castor she did not know the status. PF said that starting now he could not say what is short or long-term and would prefer a list of goals which could then be sorted and prioritised. GO agreed with this adding that FNAL budget problems made any other approach difficult. PF asked, on slide 4, what was the issue with srmGetSpaceMetaData. FD replied that it was important for srmGetSpaceMetaData to return correct sizes. GO then said he would like to understand the process of getting experiment input on the extensions to the key concepts, methods and behaviour and their priorities (slides 3 and 4 of the Flavia presentation). JS reminded that the experiments are on the mailing list of this series of meetings but said he was going to expose this to the MB. PF said he had been hoping that more experiment technical people would be at this and the next meeting. Since M.Branco was there it was agreed to start with comments from ATLAS which he (MB) agreed to have ready in a weeks time. JS thought we must bear in mind what can realistically delivered before May. PF said that for dcache he thought the crucial things were security and to honour space tokens given in srmPrepareToGet and srmBringOnline. He would like to have the experiment positions for the next meeting. There was then a more technical discussion triggered by PF saying that we must have a consistent interpretation of any extensions across the different mass storage systems. TM said that instead of honouring space tokens for a recall dcache could use other means to characterise the pool to be used for the recall. FD reminded that today dcache can not distinguish between generic and production users. MB said that there will be restores of files that need to go to alternative pools e.g. one time for reprocessing, another for export, and this can only be done by the restore accepting a space token. MB reminded that he had sent a short email outlining the ATLAS use case to the list of this meeting (the subject was 'tokens on "more-than-write"' and for completeness I have added the text after these minutes. HR). JS thought the only major long term issue is the behaviour of file restore from tape and PF could not predict how long changes to dcache in this area might take. MB said that for Atlas the most urgent goal is that of protecting spaces. FD said that in her list of proposed short term goals the first 2 (selecting tape sets and making the space token orthogonal to the path) are low priority or done while the second two (protecting spaces from generic users and making implementations fully voms aware) are more important to the experiments and not yet done, the voms requirement being really a part of the implementation of space protection. In summary JS said we now need replies from the experiments on the work list and their priorities and we want them in time for discussion in the week of 25 Feb by when we will have had a little more production experience. It is possible we end up with more than one MoU addendum. He will send a short email to the list of this meeting before the MB asking for experiment feedback by 22nd Feb. We will decide the date of the next meeting later. ======================================================================== email from M.Branco to the SSWG list on 11 Feb Hi, on the discussion of use cases for tokens on "more-than-write" I mentioned during the meeting... small excerpt but I believe addresses the point Timur was referring to.. cheers Our understanding of dCache LAN and WAN areas and staging Data to be re-processed is initially written to the Tier-1 using a space token. The space token name is e.g. _ATLASDATATAPE (T1D0)_. The relevant space tokens that involve staging are of course those of type T1D0. The space token itself is also appended to the physical path by ATLAS: srm://example.site/atlasdatatape/. It appears this has to be done for dCache sites - see below - but will also be done for CASTOR and DPM for the sake of consistency of naming conventions. When reprocessing starts, ATLAS will request sets of files called datasets. These datasets will be staged automatically by dCache to a default pool, which should be of type LAN. ATLAS will specify the pool the files were initially written to, but this is ignored by dCache. However CASTOR will make use of the attribute though, so ATLAS will pass it always. As there is the risk of staging files into the default pool at the same time, dCache sites themselves may make use of the path (e.g. /atlasdatatape/ ) to create different LAN pools where staged files go to_._ The output of a reprocessing job must be stored at the same site, as well as be sent to other Tier-1s. The job will use the space token _ATLASDATADISKTAPE (T1D1)_ to write the file to the correct area. As our space tokens are of type WAN, the other Tier-1s will be able to fetch the file. Future reprocessing jobs proceed as before (staging from what had been written to a WAN area back to the LAN default pool, optionally making use of the file path). We assume jobs at the site should be able to read data written to the WAN area directly. That is, a file written to a space token of type T1D0 should be copied over directly to the WN if it is still resident on the disk buffer of the tape area. While the workflow above fulfills our reprocessing requirements, it may cause problems to transfers between Tier-1s. It is always possible that a dataset is required by another Tier-1 and is currently residing on tape. Therefore, using only SRM commands, how can the dCache be configured so that, in this case, files are not staged to the default pool (which is LAN and not accessible from the outside) but instead to a WAN accessible area? Manual configurations or limiting the deployment model of our data management system (e.g. specific machines with sets of IPs making requests) has consequences in our system, as our data management infrastructure is designed to serve many sites from the same machines in parallel. _For FDR1 we survive by accepting an extra disk copy from a LAN to a WAN disk but for performance reasons this is not prefered as the final solution._ -- Miguel Branco, CERN - ATLAS Computing Group MSN: msbranco@hotmail.com +41 22 76 71268 - http://cern.ch/mbranco/