Edit me on GitHub
UserGuide: 5.1, 5.2, 6.0, 6.1, 6.2, 7.0, 7.1, 7.2, 8.0, 8.1, 8.2, 9.0, 9.1, 9.2, 10.0, 10.1, 10.2, 11.0, 11.1, 11.2
Book: 5.0, 5.1, 5.2, 6.0, 6.1, 6.2, 7.0, 7.1, 7.2, 8.0, 8.1, 8.2, 9.0, 9.1, 9.2, 10.0, 10.1, 10.2, 11.0, 11.1, 11.2
Release Notes: 2.10, 2.11, 2.12, 2.13, 2.14, 2.15, 2.16, 3.0, 3.1, 3.2, 4.0, 4.1, 4.2, 5.0, 5.1, 5.2, 6.0, 6.1, 6.2, 7.0, 7.1, 7.2, 8.0, 8.1, 8.2, 9.0, 9.1, 9.2, 10.0, 10.1, 10.2, 11.0, 11.1, 11.2, 12.0
Upgrade Guide: 6.2, 7.2, 9.2, 11.2

The ultimate golden release upgrade guide

Community effort to write an upgrade guide for dCache 9.2

How to get from dCache 8.2 to dCache 9.2

Executive summary

The highlights in 9.2 compared with 8.2

Breaking changes

WARNING -- Incompatibility between 8.2 and 9.2

Consequences: - When upgrading from 8.2 to 9.2, you need to upgrade the entire instance - If you run srm-manager, you need to clean /var/lib/dcache/credentials, srmrequestcredentials and all entries in the *requests and *filerequests tables from the srm database. To do so, run the following on the SRM database:

truncate srmrequestcredentials;
truncate srmuser cascade;

General incompatibilities

Bulk

Cleaner

The cleaner service, originally a single cell, now consists of two parts: one cell for disk cleaning (cleaner-disk), one for hsm cleaning (cleaner-hsm). They can be deployed as desired, be assigned different resources and each run in HA mode. This will hopefully improve performance issues and help admins configure and understand cleaner behaviour.

Be aware that the property names have changed their prefixes from cleaner.<something> to cleaner-disk.<something> and cleaner-hsm.<something>, while some admin commands have lost the "hsm" String from their name. Note: As not all previously existing parameters were used to control the behaviour of both the disk and hsm parts of the old, combined cleaner cell, please check which parameters are carried over to cleaner-hsm and cleaner-disk, respectively.

Example setup:

[dCacheDomain]
[dCacheDomain/cleaner-disk]
cleaner-disk.cell.name=cleaner-disk1

[dCacheDomain/cleaner-disk]
cleaner-disk.cell.name=cleaner-disk2

[dCacheDomain/cleaner-hsm]

Also, an admin command was added to the hsm-cleaner cell that allows forgetting a tape-resident pnfsid, meaning removing any corresponding delete target entries from the cleaner’s trash table database.

Chimera

Starting dCache version 9.1 chimera allows controlling the behaviour of the parent directory attribute update policy with configuration property chimera.attr-consistency, which takes the following values:

policy behaviour
strong a creation of a filesystem object will right away update the parent directory's mtime, ctime, nlink and generation attributes
weak a creation of a filesystem object will eventually update (after 30 seconds) the parent directory's mtime, ctime, nlink and generation attributes. Multiple concurrent modifications to a directory are aggregated into a single attribute update.
soft same as weak, however, reading of directory attributes will take into account pending attribute updates.

Read-write exported NFS doors SHOULD run with strong consistency or soft consistency to maintain POSIX compliance. Read-only NFS doors might run with weak consistency if non-up-to-date directory attributes can be tolerated, for example, when accessing existing data, or soft consistency, if up-to-date information is desired, typically when seeking newly arrived files through other doors.

Frontend

GPlazma

With the addition of the RolePrincipal, the roles plugin may be considered deprecated. In 9.2, neither Frontend nor dCacheView make use of it any more. Instead, one must grant privileges by using the multimap plugin.

An example:

dn:"/DC=org/DC=cilogon/C=US/O=Fermi National Accelerator Laboratory/OU=People/CN=Al Rossi/CN=UID:arossi" username:arossi  uid:8773  gid:1530,true roles:admin

Currently there are three roles defined: admin, qos-user and qos-group. The second allows the user to transition files owned by the user's uid; the third allows the user to transition files whose group is the user's primary gid. The two qos roles can be combined. Admin grants full admin privileges.

PnfsManager

To remove unused directory tags chimera keeps the reference count (nlink) of tags. This approach creates a ‘hot’ record that serializes all updates to a given top-level tag. Starting 9.2 dCache doesn’t rely on ref count anymore and uses conditional DELETE, which should improve the concurrent directory creation/deletion rate.

NFS

Prior to version 9.2 dCache, to support RHEL6-based clients, if no export options are specified, the NFSv4.1 door was publishing only the nfs4_1_files layout. Now on the door publishes all available layout types. If for whatever reason RHEL6 clients are still used, the old behaviour can be enforced by the lt=nfsv4_1_files export option.

Pool

Typically, when dCache interacts with an HSM, there is a timeout on how long such requests can stay in the HSM queue. Despite the fact that those timeouts are HSM-specific, dCache comes with its own default values, which are usually incorrect, so admins usually end up explicitly setting them. Starting with version 9.0, the default timeout has been removed. This means that there is no timeout for HSM operations unless explicitly set by admins.

NOTE: this change is unlikely to break existing setups, as previous timeout values are already stored in the pool setup file.

In addition, a new command sh|rh|rm unset timeout has been added to drop defined timeouts.

QoS

Note that the singleton QoS service (where all four components are plugged into each other directly) is no longer available; the four services can, however, still be run together or in separate domains, as with any dCache cell.

Resilience

Resilience is still available in 9.2, but should be considered as superseded by the QoS services. We encourage you to switch to the latter as soon as is feasible. Remember not to run Resilience and QoS simultaneously.

XRootD

#
#   Proxy all transfers through the door.
#
xrootd.net.proxy-transfers=false

#   What IP address to use for connections from the xroot door to pools.
#
#   When the data transfer is proxied through the door, this property is
#   used as a hint for the pool to select an interface to listen to for
#   the internal connection created from the door to the pool.
#
xrootd.net.internal=

#
#   Port range for proxied connections.
#
xrootd.net.proxy.port.min=${dcache.net.wan.port.min}
xrootd.net.proxy.port.max=${dcache.net.wan.port.max}

#
#   How long to wait for a response from the pool.
#
xrootd.net.proxy.response-timeout-in-secs=30

We encourage you not to use xrootd.root if possible.

Runtime environment

New services