This website is no longer maintained. Its content may be obsolete. Please visit http://home.cern/ for current CERN information.
Charles Curran CN/PDP
The invitation to tender for the tape automation project, IT-2390/CN, is complete. Adjudication of the bids showed that Storage Tek (STK) had made the best offer, and their proposal will be submitted to the 18th December meeting of the CERN Finance Committee (FC) for approval. The STK bid was based upon the helical scan Redwood D3 drive, and the Powderhorn silo.
Assuming FC approval, the current installation plan is as follows:
1. January 15th, 1997: first Powderhorn, 4 Redwoods.
2. March 1st, 1997: second Powderhorn, 12 more Redwoods.
3. April 2nd, 1997: start of public access.
4. January 15th 1998: third Powderhorn, 16 more Redwoods.
The Redwood can deliver up to 12 MByte/s and offers 10, 25 and 50 GByte capacity cartridges. The Powderhorn offers 190 cartridge exchanges per hour per silo, about 6000 cartridges per silo, and a silo interconnection using the STK pass-through mechanism. Each silo has a capability to import or export cartridges, using an exchange device which can handle 1-21 cartridges at a time. The total number of drives installed can be increased, as can the number of interconnected silos. The major characteristics of the final configuration that the present proposal will provide are:
Economies necessary to finance this project
This is, in the current budgetary circumstances, a fairly costly project. Its financing is partly dependent on economies to be made elsewhere. Already, almost 1 MCHF/year has been cut from the manual tape operations support contract. Other cuts already made include the removal of the SMCF (3480 robot) and 16 3480 drives, at the end of 1995. More 3480s have been removed during this year.
Further cuts will be made at the end of this year. The SMCG (3490 robot) and all remaining IBM 3480s will be removed. Eight IBM 3490s will be retained from SMCG and revert to manual use. These 3490s will support READ of 3480s and READ/WRITE of the 3490s removed from SMCG. Two STK 4280s will support the remaining WRITE requests for 3480 volumes.
It is anticipated that on or before 1st January 98 further restrictions on manual support will be introduced. These will probably involve the removal of periods of overnight and weekend support, which are the most costly to provide.
These services will remain:
The TL820 robot (15 DEC TZ87/DLT2000 drives)
The TZ87/DLT2000 drive is in widespread use, and reasonably reliable. However, it is already obsolete. It is probable that the DLT7000 (TZ89) drive or its successor will progressively replace the current TZ87 drive in the TL820, once it is supported by DEC in this system. The TZ89 drive can read and write cartridges in TZ87 mode. Further investment in DLT2000 (TZ87) or DLT4000 (TZ88) is not planned.
The 3494 robot (8 IBM 3590 drives)
The existing 8-frame system will have one of its storage frames replaced by a drive frame at the end of this year. Two new 3590s will be installed in this drive frame, joining the pair of drives already used to support ADSM.
It is probable that the two existing manual 3590s will be installed in this new drive frame, as there is now expected to be no need to support a ‘manual overflow’ of 3590s from this system. This could add some flexibility to use of the system, which is presently rather limited due to the presence of only 6 drives for physics applications.
Migration of data to the new STK system:
1. Default 3480/3490 migration to Redwood providing READ ONLY access
There are still ~200K manual 3480 volumes in the Tape Vault, and there will be ~15K 3490 manual volumes once SMCG is removed. To make the best use of the new STK system, and to reduce the need to support such old and obsolete media, it is planned to migrate as much as possible of the unarchivable 3480/3490 data in the Tape Vault to the new media. Users are encouraged to continue with any plans they may have to archive 3480/3490s. They can also continue to move their 3480/3490 data themselves to high density media (DLT, 3590) and archive the 3480/3490 media. These actions will reduce the scale of the migration that we will eventually need to perform on their behalf.
The default migration will provide READ ONLY access to all migrated data in a transparent manner, and the necessary media and manpower will be provided by CN. The simplest plan will be to start the migration with all volumes `AAnnnn' found physically present in the Tape Vault, then with volumes `ABnnnn', advancing finally to `ZZnnnn'. The owner or owners of such tapes would be contacted (if this is possible) some weeks before the proposed start of migration of the data to reduce as far as possible any problems or inconveniences (see also below). Any information users can provide during such contacts about which sets of their volumes they expect to be active will be helpful in planning the migration.
Of course, some users and groups will need to retain 3480/3490 volumes for import/export purposes, or to support applications that they cannot easily modify that are designed to WRITE to 3480. They will be given the opportunity to retain specified 3480/3490 volumes for manual use. We hope, however, that the numbers of such volumes specified will be as small as they can make it, and that they will be aware that the manual service they can expect to receive will be progressively restricted.
How is default 3480/3490 migration supposed to work?
Take as an example the present manual 3480s with VIDS like `ABnnnn'. There are many of these present in the Tape Vault. The owner or owners would first be informed of the proposed start date for the default migration, and asked for comments. Any of their volumes not explicitly handled by users copying themselves the data to high density media, by explicitly requesting archival, or by being specifically requested for retention in the Tape Vault as `manual 3480s' would be scheduled for copy to Redwood media. Up to 125 3480s can be copied onto a single 25 GB volume. A slightly modified ‘copytape’ will be used to do this:
a) One rack, containing up to 960 ‘ABnnvolumes, will be processed at a time.
b) The volumes found there will be grouped for individual ‘copytape’ jobs, each to run on a nominated server equipped with an STK stacker drive. The volumes will be packed sequentially into STK containers (10 at a time) during the day, for subsequent reading. Should users prefer a different order for copying, which reflects their anticipated access pattern, this order will be used. There are 8 such servers available (‘copystations’). Up to 1,000 3480s per day could be processed without excessive manual effort, so we might expect to process on average one `rack' per day.
c) As the input volumes are processed, the data they contain will be ‘re mapped’ by TMS to point to a series of files on a target Redwood volume. The original VIDs will be flagged in TMS as ‘READ ONLY’, once processed, as far as the user is concerned, and archived during the following day shift. TMS information about the now `‘READ ONLY' VID will be locked, apart from `TAG' information fields. The volumes will still exist physically, however, and be removable on request from the archive.
d) All subsequent READ tasks for the original 3480 volume VID will be redirected automatically to the copied files (with their appropriate labels) on the Redwood target. This will be transparent to the user.
This may not be entirely without pain, however...
Problem 1: WRITEs! Small collections of individual volumes, or small common pools of 3480s may be retained for writing as above if requested. What happens, however, if users later discover they need a few such volumes, and haven't reserved any? All is not lost: the ‘CZnnnn’ temporary 3480 series will remain and may be suitable for some data exchange applications. New 3480 VIDs (new or recycled volumes) could still be allocated on request. Typically, we only see about 30 requests per day now to write to 3480, so we do not anticipate that this will be a major problem.
Problem 2: conflicting requests during the ‘copy’. It is of course possible that a user job could request a manual VID which had been put in a container for a scheduled ‘copytape’ during the scheduled migration of a rack of tapes. This would cause the user job to fail, as it is probably not reasonable that the (sole) operator could remove the VID from the STK container, mount it, and replace it in the container. Hopefully the discussions which it is expected will take place with the owner or owners of the tapes before the migration begins will remove such difficulties, or reduce them to an acceptable level.
Problem 3: Errors detected on the source volumes during the copying. For relatively frequent cases such as blank tape found, or only a prelabel’ found, TMS could record as zero the number of data files found on the input volume. No mount would be provoked by subsequent read attempts; the original VID would be archived anyway. Unrecovered read errors could be handled by retaining the original VID in the tape vault, and not writing any corresponding data onto the scheduled target Redwood volume. TMS data corresponding to the source VID would remain, unmodified. It is expected that the number of such volumes discovered will be small, due to the high reliability of the 3480 drive. Justification for anticipating a low level of such problems comes from our experience in the previous mass copy of BASF volumes to replacement media, a similar `hidden migration', although a simpler one-to-one move.
2. No default 8mm or DAT migration
There is no proposal to perform a default migration of the less frequently accessed 8mm and DAT 4mm volumes. Users will be able to submit similar jobs themselves to do this if they wish, of course, but they will have to purchase the necessary media. Use of these media types is no longer high enough to make a significant demand on manual support.
3. User driven DLT data migration during 1997
There is no proposal to perform a default migration of DLT2000 data. Users are strongly encouraged to consider migrating frequently accessed data from 10 GByte manual DLT to Redwood during 1997, although they will have to submit the necessary jobs and purchase the necessary media. Support for manual access to DLTs will become restricted during 1998.
Questions?
Questions and comments should be sent by e-mail to tape.support@cern.ch