There are two ways for an archival to be initiated. One is for a user to request a file be archived (and possibly made non-resident) using the forcearc(8) utility. Another would be for an archival scan process to determine that the file should be archived. After opening the file, the first step is for the archiving process to perform the DMFS_SETAIP fcntl(2) operation, which sets the internal DM_AIP (archive in progress) flag. This operation will succeed if the process has root privileges and if no other process is in the process of archiving the file. The process ID for the file is noted for reference.
The second step of the archival process is for the archiver to add the file to the dmfsd databases, and to copy the file to tape storage. Adding the file to the dmfsd databases might also involve initializing some of the metadata fields such as the bfid, the unique identifier for this file.
The third step is for the archiving process to set the file's DM_ARCH flag, which indicates that the file has been archived. The DMFS_SETARCH fcntl(2) operation sets this flag.
Finally, if the file is to be made non-resident, the archiver performs the DMFS_SETNONR fcntl(2), which takes the amount of initial data which are to remain on the underlying file system. The DMFS layer determines the size of the underlying file, and, assuming it is greater than the requested size, it notes the underlying file size in the archive size field, and truncates it to the desired length. The DM_NONR flag is set for the file which indicates that it is not totally resident. From this point, the file size reported will be that which was noted during this operation rather than the actual size of the remaining portion on disk.
NAStore 2 truncated all files to zero residency. In NAStore 3 we have added the ability to retain a portion of the file on disk. From our analysis of some new storage architectures, such as MCAT/SRB, files will actually be managed by storage agents rather than directly by the generating program. Often such systems will add a header of metadata to the beginning of the file which serves to describe the whole file. By leaving this portion on disk, we permit whatever agent is managing the storage of these data to examine the file's header without triggering a restore event. As the exact amount of storage to leave on disk is a dependent on site and storage broker configuration, we permit the archiving process to determine how much of the file should remain.