release notes | Book: 1.9.5, 1.9.12 (opt, FHS), 2.11 (FHS), 2.12 (FHS), 2.13 (FHS), 2.14 (FHS), | Wiki | Q&A black_bg
Web: Multi-page, Single page | PDF: A4-size, Letter-size | eBook: epub black_bg

Directory Tags

In the pnfs filesystem, each directory has a number of tags. The existing tags may be listed with

[user] $ cat '.(tags)()'
.(tag)(OSMTemplate)
.(tag)(sGroup)

and the content of a tag can be read with

[user] $ cat '.(tag)(OSMTemplate)'
StoreName myStore

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 is osm.

hsmType

The HSM type is normally determined from the other existing tags. E.g., if the tag OSMTemplate exists, HSM type osm is assumed. With this tag it can be set explicitly. An class implementing that HSM type has to exist. Currently the only implementations are osm and enstore.

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:

  1. The <tagName> is limited to 62 characters and the <content> to 512 bytes. Writing more to the command-file, will be silently ignored.

  2. 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 the pnfs distribution. It has to be called in the directory where the primary tag was with the tag name as argument.

  3. 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.

  4. 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.