----------
> From: Shyh-Wei Luan <[EMAIL PROTECTED]>
> To: Mickey Beddingfield <[EMAIL PROTECTED]>; [EMAIL PROTECTED]
> Subject: Re: last volume access time / volume space management
> Date: Tuesday, October 29, 1996 2:33 PM
> 
> Mickey,
> 
> On Oct 29,  4:49am, Mickey Beddingfield wrote:
> > Subject: Re: last volume access time / volume space management
> > Shyh-Wei,
> >
> > Transarc has a set of scripts that was designed to ballance volumes
across
> > partitions based on use.  These scripts have the ability to determine
> > volumes that are not used at all.
> 
> Are these scripts in Transarc's AFS contribution directory?  What command
or
> API does the script use for getting the "last access date" info?
> 

I'm not sure about this.  I haven't had a chance to look through the
scripts, but I understand that they are straight forward & nothing special?

> > They could be modified to move volumes
> > to some low-cost storage device if they were not used, and if used
again
> > they could move them back to real disk.
> 
> How would the reloading of the volume be triggered?  I have been thinking
of
> modifying volume location server code to do this.  Wondering if you have
some
> different thoughts ...
> 

In our case we plan to use a near line storage device that will allow
access to the volume at a reasonable rate???  Anyway, the Load Bal. scripts
will detect a use of the volume & it will be moved back to real disk the
night after an access.

> > This would happen at night, so the
> > first use of an old/non-used volume would be from the low-cost storage
> > device. This may present a problem unless it has some reasonable access
rate!
> 
> > Why would you want to back these volumes up?  It would seem to me that
if
> > they weren't used for some time that the last backup would be just
fine.
> > Once they are used again they would be moved back to a partition that
was
> > being backed up?
> 
> I don't think "not being used" necessarily mean "not important".  The
automatic
> migration mechanism cannot determine "what's important" - only humans can
make
> this kind of decisions.  Backing up a migrated volume ensures that every
volume
> has at least two physical copies at any time.
> 

If a volume is dectected to be "not used" it must have been so for a period
of time that will allow us to go through at least one full backup cycle. 
Once its moved to nearline storage then we don't really need to keep
backing up the volume?  I don't think???  Or I can't see any reason why we
would need to do so.  Anyway, the next time it is "used" it will be
scheduled for a move & thus be back on the backup list.  We should always
have a good backup copy of this volume on tape even if we have a problem
with the near line storage device.

> > Hope this helps...Mic
> 
> Thanks for the response ... Shyh-Wei
> 
> >
> > ----------
> > > From: Shyh-Wei Luan <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: last volume access time / volume space management
> > > Date: Monday, October 28, 1996 5:19 PM
> > >
> > > Hi,
> > >
> > > I am looking into a volume-migration solution for AFS/DFS.  The idea
> > > is that volumes that are not accessed for a long time can be
> > > automatically migrated to on-line library, to alleviate on-line disk
> > > storage need to keep those dormant volumes (e.g., outdated tools,
dead
> > > projects, absent user volumes, ...).  These volumes shall be migrated
> > > back to disks automatically when they are referenced.  Backup shall
> > > also be done on migrated volumes.
> > >
> > > I'd like to evaluate the merits of this approach, especially I need
> > > to know how many volumes out there are not accessed. The
> > > "vos examine" command gives the last update time but not the last
> > > access time to account for reads.  I tried the volinfo command on
file
> > > servers and it always gives a zero "accessDate".  I guess it is not
> > really
> > > used.  It also gives a "dayUseDate".  Would it be an accurate
reference
> > > for the last access date???
> > >
> > > It is also a concern that some file backup, garbage collection, or
> > > virus checking programs might access these inactive volumes
periodically,
> > > and make them look accessed.  So, any volume access time reading may
not
> > > be accurate in these environments.
> > >
> > > Has this kind of measurement being done?  How did you do it?  What
> > > did you find?  Do you think space management based on volumes might
be
> > > useful to you?
> > >
> > > Any comments?
> > >
> > > Thanks,
> > >
> > > Shyh-Wei Luan
> >-- End of excerpt from Mickey Beddingfield
> 
> 
> 

Reply via email to