LHCb Space tokens migration happened in April 2011

New space tokens schema

LHCb wanted a simplification in Storage Element Space Token definition, from the old configuration:
LHCb-RAW T1D0
LHCb-RDST T1D0
LHCb-M-DST T1D1
LHCb-MC-M-DST T1D1
LHCb-DST T0D1
LHCb-MC_DST T0D1
LHCb-FAILOVER T0D1
LHCb-USER T0D1
To a simpler:
LHCb-Tape T1D0
LHCb-Disk T0D1
LHCb-USER T0D1
put in place at all sites during April - May 2011.

The migration has been done in different ways, according to the different storage technology at the sites:

For Castor and StoRM: the files have been migrated from old space tokens to new ones with this mapping:

  • LHCb-RAW , LHCb-RDST to LHCb-Tape
  • LHCb-M-DST, LHCb-MC-M-DST, LHCb-DST, LHCb-MC_DST, LHCb-FAILOVER to LHCb-Disk
  • LHCb_USER has stayed the same.

in dCache the procedure was different. It was coordinated by Ricardo together with PIC people and it served as example to other dCache sites. See this document: spaceTokenMigrationProcedure enclosed to this page.

Some operation issues in data management at dCache sites after the migration

In dCache sites the data has not been migrated to the new space tokens. It is still in the old ones, which have been 'released' (meaning that the space reservation does not exist any more, though the files are physically there). So, the files in old space tokens can be accessed for reading (like before), but there is not writing activity on them. The problems in this configuration are:

Not possible to get information about the space usage through SRM interface

This is because for SRM the space token is not active. This problem has been mitigated by asking to sites to produce a dump of the space tokens, that currently (Oct 2011) almost all sites provide on a weekly basis.

Most serious problem: how to recover the space freed up in the old space tokens after removal of old data

LHCb is slowly removing old data, from the old space tokens. The removals are done depending on the agreement of the physics groups, so it is not possible to know in advance when, where and how much will be removed.

The problem is: The space freed up in old tokens is not automatically allocated to new tokens (LHCb-Disk), but it requires an operation from the site. So it was agreed (Sept 2011) that every time some data are removed, LHCb will open a GGUS ticket to ask for the reallocation. Ok. But here an additional complication comes: after discussions with Gridka site admin we learned that there is a clear separation between the pools assigned to the T1D* space tokens, and the pools assigned to the T0D1 spaces. So, if you have to re-assign some free space from T1D* pools to the T0D1 pools, it can be a complex operation. In our particular case, after removal campaigns, some space is freed up in the old T0D1 tokens ( LHCb-DST and LHCb-MC-DST) and this can be easily re-assigned to LHCb-Disk. And on the other hand, some space is freed in the old LHCb-M-DST and LHCb-M-MC-DST (which were T1D1 spaces), and this free space requires more complicated operation to be reallocated. See GGUS with Gridka where this is discussed.

Some question from sites administrators

  • How often should space be re-allocated from old space tokens to new ones? Answer: it has been agreed with sites that LHCb will notify the site via GGUS ticket when it will necessary to do it (typically after a removal campaign)
  • When will the old space token be completely cleared? Answer: the LHCb_RAW and LHCb_RDST never. The LHCb-M-DST, LHCb-MC-M-DST, LHCb-DST, LHCb-MC_DST will be gradually cleared. But for the LHCb computing team it is impossible to say when all data will be removed, because data removal is an operation to be agreed with the physics groups
  • When some space is re-allocated, to which space token should it be allocated? Answer: to LHCb-Disk. Unless LHCb explicitly asks to add it to other space tokens.
  • How much space should be left in the old T1D1 space tokens? Answer: only the space actually occupied by the files residing there. All the remaining free space should be removed from there. LHCb will never write there, only read.

-- ElisaLanciotti - 07-Oct-2011

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatodt spaceTokensMigrationProcedure.odt r1 manage 14.7 K 2011-10-07 - 12:40 UnknownUser document describing the procedure for the space token migration for dCache
Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 2011-10-12 - unknown
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback