SRM file types

There are 3 different file types that can exist within an implementation of an SRM: permanent, durable and volatile. These arise as a consequence of the concept of pinning a file. The differences between them can be seen in the table below. The table is taken from here.

	Archive	Assign lifetime	Remove if space needed
Volatile	NO	YES	YES
Durable	NO	YES	NO
Permanent	YES	NO	NO

Permanent files

Permanent files do not have a lifetime associated with them and cannot be deleted by the SRM. A user has to explicitly call delete (srmAdvisoryDelete for SRM 1) to remove the file. Permanent does not imply that files are backed up: for some SRMs they might be, for others not. So for a disk SRM, if the SRM's disk fails, the file may be lost.

Durable files

Durable is not used by any of our implementations. A durable file is like a volatile file in that it has a lifetime associated with it, but like a permanent file in that when the lifetime expires, the file is not automatically eligible for removal. Instead, the SRM may notify the client or sysadmin that the lifetime has expired and sysadmin could remove the file if the space is required. Of course sysadmins should consult the owner first. A durable file type is necessary in order to provide temporary space for files (such as files generated by large simulations), which need to be eventually archived.

Volatile files

Volatile files have a lifetime, associated with each client accessing the file. If the lifetime expires (i.e. if it is not pinned, implicitly or explicitly) or there are no transfers on the file, then the SRM can delete the file. The concept of volatile files is very useful for dynamic space usage, automatic garbage collection, and sharing of files on a temporary basis.

It is important to note that the above file types are defined in the SRM specification. They do not refer to the level of backup, redundancy or resiliancy of the underlying filesystem and storage hardware upon which the SRM layer operates.

Many Tier-2 sites use multiple disks, configured in a RAID array, to provide storage to grid users.

There is also the concept of having different space types, corresponding to the 3 file types above. This allows for the reservation of space by an SRM when it knows that a file is about to be transferred to it. This functionality has not been implemented in v1.1 of the SRM protocol.