Last modified 13 years ago Last modified on 10/04/07 12:42:14

Optional new Hsm Interface between dCache and the HSM backends

Scope of this page

This is NOT a detailed technical description of the optional changes of the dCache HSM interface but should be seen as a hint for users if and when to move to this interface.

What is this about

With 1.8, dCache provides the possibility to interact with an attached HSM in a slightly different way. The main reasons for the introducation of this interface is :

  • This allows dCache to support different HSM systems at physically different locations. (The NDGF approach).
  • Pnfs/Chimera? doesn't need to be mounted on the pools nodes, not even on HSM write pools.

How does this work

With 1.7, the HSM connection scripts have been writing private HSM information into level 1 (resp 4) of pnfs directly. On 'restore' those scripts could either us the information in pnfs or get the same kind of information from the command line of the called script. With 1.8, the HSM script may return a special formatted, so called URI, to dCache which is stored internally. The information provided to the 'restore' script should be compatible to the already know plus holding the URI information. So that in the latter case, pnfs doesn't need to be mounted anymore.

What do I need to change with 1.8

With 1.8 the site may decide to stay with the old mechanism or move to the new one.

I don't want to use the new HSM connectivity mechanism

Nothing, except please make sure that your HSM script doesn't return anything to standard out. This would be interpreted as the URI and the new mechnism would be automatically enabled. You are still free to use stderr at your convenience.

I would like to use the new mechanism

Make yourself familiar with the URI syntax and return the URI from the HSM script when writing files to the HSM.

Last Modified by patrick @ Wed Mar 3 07:12:20 2021