In the pnfs
filesystem, each directory has a number of
tags. The existing tags may be listed with
[user] $
cat '
.(tag)(OSMTemplate) .(tag)(sGroup).(tags)()
'
and the content of a tag can be read with
[user] $
cat '
StoreName myStore.(tag)(OSMTemplate)
'
A nice trick to list all tags with their contents is
[user] $
grep "" $(cat ".(tags)()")
.(tag)(OSMTemplate):StoreName myStore .(tag)(sGroup):STRING
Directory tags may be used within dCache to control which pools are used for storing the files in the directory (see the section called “The Pool Selection Mechanism”). They might also be used by a tertiary storage system for similar purposes (e.g. controlling the set of tapes used for the files in the directory).
Even if the directory tags are not used to control the bahaviour
of dCache, some tags have to be set for the directories where
dCache files are stored. The installation procedure takes
care of this: In the directory /pnfs/<site.de>/data/
two tags are set to default values:
[user] $
cd /pnfs/<site.de>/data/
[user] $
grep "" $(cat ".(tags)()")
.(tag)(OSMTemplate):StoreName myStore .(tag)(sGroup):STRING
The following directory tags appear in the dCache context:
Directory Tags for dCache
- OSMTemplate
Contains one line of the form “
StoreName
<storeName>” and specifies the name of the store that is used by dCache to construct the storage class if the HSM type isosm
.- hsmType
The HSM type is normally determined from the other existing tags. E.g., if the tag
OSMTemplate
exists, HSM typeosm
is assumed. With this tag it can be set explicitly. An class implementing that HSM type has to exist. Currently the only implementations areosm
andenstore
.- sGroup
The storage group is also used to construct the storage Class if the HSM type is
osm
.- cacheClass
The cache class is only used to control on which pools the files in a directory may be stored, while the storage class (constructed from the two above tags) might also be used by the HSM. The cache class is only needed if the above two tags are already fixed by HSM usage and more flexibility is needed.
- hsmInstance
If not set, the HSM instance will be the same as the HSM type. Setting this tag will only change the name as used in the storage class and in the pool commands.
There are more tags used by dCache if the HSM type
enstore
is used.
When creating or changing directory tags by writing to the command-file as in
[user] $
echo '<content>' > '
.(tag)(<tagName>)
'
one has to take care not to treat the command-files in the same way as regular files, because tags are different from files in the following aspects:
The <tagName> is limited to 62 characters and the <content> to 512 bytes. Writing more to the command-file, will be silently ignored.
If a tag which does not exist in a directory is created by writing to it, it is called a primary tag.
Removing a primary tag invalidates this tag. An invalidated tag behaves as if it does not exist. All filesystem IO operations on that tag produce an “File not found” error. However, a lookup operation ( e.g. ls) will show this tag with a 0 byte size. An invalidated tag can be revalidated with the help of the tool repairTag.sh in the
tools/
directory of thepnfs
distribution. It has to be called in the directory where the primary tag was with the tag name as argument.Tags are inherited from the parent directory by a newly created directory. Changing a primary tag in one directory will change the tags inherited from it in the same way, even if it is invalidated or revalidated. Creating a new primary tag in a directory will not create a inherited tag in its subdirectories.
Moving a directory within the
pnfs
filesystem will not change the inheritance. Therefore, a directory does not necessarily inherit tags from its parent directory. Removing an inherited tag does not have any effect.Writing to an inherited tag in the subdirectory will break the inheritance-link. A pseudo-primary tag will be created. The directories which inherited the old (inherited) tag will inherit the pseudo-primary tag. A pseudo-primary tag behaves exactly like a primary tag, except that the original inherited tag will be restored if the pseude-primary tag is removed.
If directory tags are used to control the behaviour of dCache and/or a tertiary storage system, it is a good idea to plan the directory structure in advance, thereby considering the necessary tags and how they should be set up. Moving directories should be done with great care or even not at all. Inherited tags can only be created by creating a new directory.