1. Focus 28 March 20021 Tape Service and CASTOR Issues Focus 28 March 2002 H.Renshall IT/DS

2. Focus 28 March 20022 TMS (1 of 2) Managed storage implies end users no longer own or manipulate tapes (though we are in a transition phase as regards efficient co-location) CASTOR includes its own volume manager already containing much of the functionality of TMS. The CERN Tape Management System will not be used by the LHC experiments TMS (and its companion SYSREQ server) run on three very old SUN servers. It would be a non-negligible cost (hardware and software) to migrate them. We propose to shut down TMS at the end of 2002 providing restricted functionality alternatives for experiments still using it.

3. Focus 28 March 20023 TMS (2 of 2) To stop TMS we believe we need to enhance support in CASTOR for : –tape location in libraries. Only library names –supported and query is privileged. –write-locking volumes. Currently a privileged operation. –tag (comment) field per volume. Needs to be added. CASTOR command line interfaces to the above exist but we could simulate ‘sysreq tms …’ calls if really required. Which experiments would need this ? Largest non-CASTOR user is probably NA48. Already using CASTOR for reconstruction and analysis - could they switch for raw data this year ? NA49 Sony tapes would be entered into the CASTOR volume manager. We would keep a frozen flat file extract of the final TMS database After 2002 Opal will be the only production user of FATMEN and will provide the effort (via S.Oneale) to make it TMS independent

4. Focus 28 March 20024 Redwoods (1 of 2) We have 8 Redwood drives in operation today and the end of our 5 year STK Redwood support contract is April 2002. Maintenance price then goes up from CHF 720/drive/month to 1425 so cost for 8 drives for rest of 2002 will be 91 KCHF. At end of 2002 drives are no longer supported by STK USA. STK Suisse propose after 2002 a flat fee of 61 KCHF plus CHF 720/month/drive using 12 drives held in reserve for spares until all have been used up then the service would stop (unclear end point !) Redwoods have been copied to 9940 except for 7500 of NA48 which have a low frequency of access. Current redwood mounts are about 4500 per week (out of a total mounts of 40-50000) with the top 3 groups (av. Over last 4 weeks): –NA49=45% of redwood mounts, OPAL= 24%, NA48=11%

5. Focus 28 March 20025 Redwoods (2 of 2) We propose to stop all Redwood usage by end 2002 with a contingency up to end April 2003. We propose to copy remaining NA48 Redwoods to the new higher density STK drive when available (we would have to borrow drives from LCG until we get our own). We have 150 KCHF for this - about 50 KCHF short so will recuperate later (by CASTOR repack). We propose to reduce to 4 maintained drives from now and reactivate 4 drives to help in the NA48 Redwood copying. We will prepare a costed plan to upgrade existing drives to the higher density model including reusing existing media at higher density through the planned CASTOR repack functionality. We propose to block access to Redwoods already copied to CASTOR when experiments agree but as soon as possible.

6. Focus 28 March 20026 High Speed Tape Drives In 2001 STK gave us advance notice of a new range of drives, the 9940B. This increases data rate from 10 MB/sec to 30 and capacity on the existing 9940 cartridge from 60 GB to 200 GB. The media cost will drop from CHF 2 per Gigabyte (uncompressed) with final value depending on hardware compression obtained. CERN will field test pre-production drives in May/June. Production availability will be ‘after’ field tests. We have FC approval to buy up to 20 drives for the LCG project if field tests are successful. Delivery date of production quality drives would be earliest July but cannot be guaranteed. We are not considering them for this year’s new raw data. We do plan to use them for the Alice MDC4 in weeks 40-42. If all goes well we will copy remaining NA48 Redwoods during 2002 and plan to upgrade existing 9940 drives to 9940B in 2003 or earlier if possible. We will then get cheaper media for 2003 raw data and, as resources permit, repack low to high density and reuse existing media.

7. Focus 28 March 20027 CASTOR (1 of 2) A CASTOR Users meeting with experiment representatives was held on 22 March. The intended program of work for 2002 was presented with items divided into mandatory with high and lower priority and optional where we were seeking user advice on priorities. The main conclusions that emerged were that priority should go to improving performance and reliability (e.g. by improving operational and end-user monitoring and documentation - a recent data loss incident was traced to the combination of a failing disk and an inadequate operational note) especially as required for data challenges and production running. These areas should be addressed before that of adding new functionality (e.g. the Castor file system).

8. Focus 28 March 20028 CASTOR (2 of 2) Of the options presented those deemed most interesting were –fair shares allocation of tape drives and space in the public disk pools –wide area data movement both with and without using grid tools –directory level migrate and recall –repacking of data to higher density media and from fragmented media New (or re-emphasised) requirements presented were: –priority to continuity for running experiments –the continued importance of command line interfaces –clearly signalled (by email if needed for asynchronous cases) error codes –double copies to be on little used tape –ability to give tape co-location clustering hints We are now reviewing the program of work in the light of this feedback. We have to balance these short/medium term requirements with known longer term ones. There are developments, such as the Castor file system, that we think will have a large future payback. In addition we would welcome a mass storage rtag looking at long term requirements.

9. Focus 28 March 20029 Proposal for charging algorithm (1 of 2) At the November Focus we proposed to charge for tape usage: –Proposal for charging algorithm in 2002 –Take into account: Amount of data on tape –Only non-deleted data is billed –Drive compression factor is taken into account Tape I/O activity: number of Gbytes transferred to and from tape Tape device time (to favor fast or lightly loaded disk servers) Gigabyte cost in 2002: 2 CHF uncompressed (i.e. on disk occupancy) We want to modify this to rather charge for the number of mounts and the number of Gbytes transferred where the normalisation is that a mount/demount cycle has the same cost as transferring 1GB since both take about 2 minutes of real time. We suggest (this is a political decision) to set the costs to recuperate the media cost of user tapes data - about 60 KCHF/year (currently single copy only). In practise this is spread among about 15 experiments to pay from 1 to 5 KCHF/year.

10. Focus 28 March 200210 Proposal for charging algorithm (2 of 2) New algorithm is hence(all in CHF): –cost =GB stored increase*2 + 0.02*(Gbytes moved + No mounts) The.02 is based on an annual total of 1500 TB moved and 1500000 tape mounts For example last week top 6 groups were: –Opal 13500 mounts for 7.5TB moved = CHF 420 cf 2001=13.5KF –Aleph 6500 mounts for 2.1 TB moved = CHF 172 cf 2001=21.5KF –Delphi 6500 mounts for 1.35 TB moved=CHF 157 cf 2001=18KF –LHCB 5200 mounts for 4.2 TB moved=CHF 188 cf 2001=20.4KF –NA48 4500 mounts for 2.5 TB moved=CHF 140 cf 2001=360KCHF –NA49 4000 mounts for 1.2 TB moved=CHF 104 cf 2001=? –next highest group was CHF 50 Group weekly mounts per tape type are at –http://http://it-div-ds.web.cern.ch/it-div-ds/HO/tpusage.index.2002.html