ADSM-L

Re: stgpool migration question

1996-12-02 15:15:11
Subject: Re: stgpool migration question
From: Francis Dequenne <syf AT ECMWF DOT INT>
Date: Mon, 2 Dec 1996 20:15:11 +0000
On Dec 2,  1:25pm, Wayne T. Smith wrote:
<=> Subject: Re: stgpool migration question
<=>Dirk wrote, in part..
<=>>...                                        This makes no sense
<=>> for me, because we have one server with a 7GB file space that
<=>> is backed up and several small worstation. Now the whole server
<=>> files space has been moved to the tape storage pool and that's
<=>> NOT what I want.
<=>
<=>Why not?  To do anything else will increase the number of tapes
<=>mounted and/or the scattering of data among tapes.

It really depends what you are using your ADSM for. We are sharing the point of
view of Dirk, here. Indeed, we want to use ADSM not only for storing data, but
also to retrieve it (all in all, the volume of data archived in our Data
handling Systems is roughly similar to the ammount of data retrieved from it.
In this environment, we would like to be able to use an alternative disk
caching algorithm that would send to tape the files that have not been accessed
for a while, but keep on disk the "hot" files, wherever they come from. We
would also like to be able to perform intelligent file restaging (e.g. it
should be possible for a file that was migrated to tape, but is being retrieved
and is likely to be retrieved several times, to be migrated back to disk
storage pool) The fact that this would generate more tape mount activity is a
lesser evil, for us. It is not even obvious that it would have a significant
impact, as our tape drives are all under robot control.

BTW, regarding restaging, the already suggested solution of a move data from a
tape to a disk stg pool is totally impractical, for us. We need something that
works automatically, and only restage a few files out of a 10Gb tape.

To some extend, HSM offers a solution to some of these problems, and we use it
for some of our applications. But there are some considerations, as well as
practical limitations that we are already hitting now, and that force us to
consider alternative strategies, like the use of the API. But for these to
really be efficient, we would need alternative storage pools migration policies
and the possibility to restage files.


<=>
<=>> How can I undo the migration process? The cached copies of the
<=>> workstation files are still on the disk.
<=>
<=>Why undo the migration?  Since you have enabled caching, many files are
<=>still available for immediate restore from disk.

This does not work if the ammount of data that you move in ADSM forces you to
migrate several times a day. Buy more disks? Well, we have already a disk farm
of several hundreds of Gb on site, expect more, and will still have to migrate
several times a day in the not to distant future.

<=>
<=>If you really want to treat your larger server and smaller workstations
<=>differently, then maybe its time to consider separate pools?
<=>
<=>regards,
<=>
<=>Wayne T. Smith               mailto:wts AT maine.maine DOT edu
<=>Systems Group -- CAPS        University of Maine System
<=> End of excerpt from Wayne T. Smith



--
Regards
Regards

+-------------------+----------------------------------+---------------------+
| Francis Dequenne  | Systems Section                  |      /~~\  /~~\     |
| ECMWF             | e-mail: fdequenne AT ecmwf DOT int      |     /    \/    
\    |
| Shinfield Park    | Tel:    (+44 1734) 499361        |   ECMWF             |
| Reading           | Fax:    (+44 1734) 869450        |   ECMWF             |
| Berkshire RG2 9AX | Telex:  (+44 1734) 847908        |     \    /\    /    |
| United Kingdom    |                                  |      \__/  \__/     |
+-------------------+----------------------------------+---------------------+
<Prev in Thread] Current Thread [Next in Thread>