Whenever a file entry is removed from pnfs (the dCache namespace), dCache takes care that all copies of this file are removed from the various pools. In case, dCache is attached to one or more tertiary storage systems, it provides an interface to allow removing the file from those external systems as well.

As soon as a file entry is removed from pnfs, a new file is created within a special, so called, trash directory. (For details, see next paragraph) The name of this newly created file is identical to its inode, resp. pnfsId. A pnfsId is an internal unique identifier for each file within the dCache. PnfsIds don’t change if files are renamed and pnfsIds are never reused. The content of the this (new) file is exactly the information written into level 1 during the HSM store prodecure, discussed in the sections above. This information is usually sufficient to get the file removed from the backend HSM storage system.

The trash directory is a local directory residing on the head node, or to be more precise, on the server node where pnfs/chimera is running. In regular dCache installations, the directory is /opt/pnfsdb/pnfs/trash/1. After the installation of pnfs, only the path section /opt/pnfsdb/pnfs/trash exists. In order to activate the signaling on pnfs file removes, a subdirectory named 1 has to be created within /opt/pnfsdb/pnfs/trash. From that point in time, this directory is populated with file entries for each file removed from pnfs/chimera. The mechanism, taking this file information and doing the appropriate HSM specific actions, is resposible for removing those entries if no longer needed, resp. if the file has been removed from the backend HSM.

For exotic dCache installations, the entry trash= in /usr/etc/pnfsSetup points to the trash directory within the local filesystem.