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.
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
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
/usr/etc/pnfsSetup points to the
trash directory within the local filesystem.