Dynamic Megatable

Further agreements

Summary of meeting on June 23rd, 2008


  • GlueSALocalID does not have any imposed format. The only restriction is that this identifier must be unique within a site.
  • GlueSA represents a Storage Area that does not overlap with any other Storage Area at a site.
  • A Storage Area can be shared among VOs. In this case only one GlueSA describes it. Such GlueSA has many GlueAccessControlBaseRules, one associated with each VO/FQAN that has access to the GlueSA.
  • A Storage Area can have one or more VOInfo objects associated to it. Such VOInfo objects may or may not publish an associated TAG (i.e. the VOInfoTag is optional). The VOInfo object can be used to only publish the path associated to a VO for the Storage Area associated to that VOInfo object.
  • A GlueSA can be published for space that is unreserved. In this case, the GlueSATotalOnlineSize will report the total space available (hmmm.... I am not sure here. I think that for consistency will still need to use the GlueSAReservedOnlineSize to publish the configured unreserved space. Could you please comment?)
  • It was agreed not to use summary GlueSAs which do not correspond to any physical instance of a space (GlueSACapability: usage=megatable).
  • It was agreed that GlueSAReservedOnlineSize must be equal to the space configured to create a given Storage Area. GlueSATotalOnlineSize must be equal to the total space for a given SA excluding broken or unavailable disk servers. GlueSAUsedOnlineSize is the space occupied by pinned files. GlueSAFreeOnlineSize=!GlueSATotalOnlineSize - GlueSAUsedOnlineSize
  • Flavia will update the Glue v1.3 example published on the GSSD pages to reflect the current proposal for publishing spaces.


  • Jens will make sure that the proposal makes sense for CASTOR and come back with an answer by June 24th.


  • Paul Millar will investigate with the dCache developers team to see if it is possible to provide the information about the space occupied by pinned files only.
  • Paul and Ron will come up with a proposal for a minimal set of Keys needed for the Capability field in GlueSA.
  • Paul will verify with the dCache developers team that the proposal makes sense for dCache and come back with an answer by June 24th.


  • M. Jouvin will check the current GIP and let us know of possible problems implementing the current proposal.
  • Unreserved space can be covered by GlueSA with GlueSA associated VOInfo objects with no tag and a path per VO/FQAN.


  • StoRM already implements this proposal. The StoRM team will verify that the path published by StoRM in the VOInfo object at the moment is conform with this proposal.

-- FlaviaDonno - 23 Jun 2008

Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r1 - 2008-06-23 - FlaviaDonno
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

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