4.3 Archiver daemons

4.3.1 archd common code

archd is the common code shared by all the archiver daemons. Of course, each archiver has a different working directory in which archd is running, and has a different parfile. To make things clearer, each archive daemon executable has a different name (tarexad, tarexa2d...) but these files are just a symbolic link to archd.

When the number or the size of the files in the working directory exceeds a certain limit set in each parfile, archd moves these files to the .current subdirectory, and invokes a specific handler, able to write the files on the given medium. archd then analyses the exit status of the handler to determine whether an error has occur or not. If no error (status 0), then archd just removes the files from the .current subdirectory and goes to sleep. Otherwise, two types of errors may occur: a "normal" error (status 2) is when the end of the medium was reached; an "abnormal" error (status 1) is when the medium or the handler failed for some reasons (should normally never happen). In any case, only the files correctly saved are removed from the .current subdirectory. The others (incorrectly saved) are moved back to the working directory and an attempt to save them again will be done next time the archiver daemon is started. archd eventually warns the archive manager(s) and exits.

archd can communicate with the distributor daemon through two control files in the archiver working directory: .broadcast to receive messages from the distributor and .report to send messages to it. When its media is full, archd writes EOM in its .report file to warn the distributor daemon. Then the distributor forces the other archivers to save their files by writing SAVE_NOW in their .broadcast file (see previous section). When this happens, archd overrides the limit tests and save every file in the working directory. When all the files have been successfully saved archd warns the distributor daemon by writing SAVE_OK in its .report file and exits.

The two other control files that can be found in an archiver working directory are .label and .current_set which contain respectively the current label of the media and, if applicable, the current save set (set number one is reserved for the label).

archd gets the list of the correctly saved files from the media handler through the .ok_files control file. archd then just appends this file to its listfile, given in the parfile. A typical parfile for archd is listed in figure 4.3. The general algorithm used by archd is shown in figure 4.4.

The list of all archived files and their corresponding set numbers on the tape can be found in the /archive/sw/list/tarexa_list and tarexa2_list files. If you need to retrieve files from old tapes just check the list files in /archive/sw/list/old to find the right tape to read and the corresponding set number to skip to.

[IMAGE (figure)]

[IMAGE (figure)]

4.3.2 Media handlers

To perform the media dependant I/Os, archd invokes a media specific program called media handler. Each archive daemon shares the same main code has we said before but of course each of them invokes a different handler. The path to the valid handler is given in the parfile. All the media handlers are currently located in /archive/sw/handler. The current available handlers are:

• tarexah: to write on tape in TAR format (for tarexad);
• dumpexah: to write on tape in DUMP format (for dumpexad);

N.B.: As dumpexad is not currently used, neither is dumpexah.

The syntax to invoke a handler is:

handler_namearch_dirdevice label

When invoked, a handler first checks if the label given on the command line matches the one of the media identified as device. Then it tries to write onto the media all the files located in arch_dir/.current. For writting to tape, the current set number is taken from the .current_set file in the arch_dir directory and increased by one. The names of the files correctly saved are written in the .ok_files in arch_dir as explained in the above section. The possible values of the exit status of a media handler are also explained in the above section.

The detection of the end of the media is not a problem when the Unix command used by the handler to write to the media gives an informative status. For the Exabyte tape, the indication of the end of tape from both the tar and the dump command is not easy to detect. Moreover, reaching the end of the tape may confuse the driver and disable the device. So it is recommended to define at the beginning of the handler a maximum number of sets allowed on the device, small enough to make sure that the physical end of media is never reached (compute the size of one set by adding the size_limit given in the daemon parfile, 2 megabytes for the end of file on an exabyte tape, and say some 20%to be safe). At the moment, we do not use this feature because we are sure that the optical disk (capacity 3Gb) will fill up before the Exabyte tape (capacity 5Gb). This of course may change in the future.

4.3.3 Media initializers

In addition to writing to the media, it is necessary to perform an initialization when the media is used for the first time. The physical initialization may vary. The logical initialization involves at least writing the new label on each media. Like there is one handler per device, there is one initializer per device. The current available initializers are:

• tarexa_init: to write on tape in TAR format;
• dumpexa_init: to write on tape in DUMP format;

They are currently located in /archive/sw/handler. tarexa_init and dumpexa_init both label the tape by writing the new label as a TAR file on the first saving set (note that even in DUMP format, we use TAR for labelling).

N.B.: As dumpexad is not currently used, neither is dumpexa_init.