Zlatko,
I do agree with what you are saying but my point was if you have moved node
data from one stgpool to another, but at the same time changed the domain
of the node, what would happen to the data in the old copypool??? Does it
maintain the same copy group/domain definitions for node which would now be
in a new domain??? If not then surely it would be feasible to tweak the old
copygroup params (subject to having no nodes being in the old domain using
the "to-be-tweaked" copygroup definitions) to reduce expire the data on the
storagepool. On the otherhand if updating the nodes domain, does also apply
to data in the old copypool, you are indeed correct and you would have to be
incredibly crazy to do such a thing.
After writing my response above I think I have may have blurred and
complicated what I was trying to say, for which I do apologise.
On a different note I wasn't aware that you could delete a filespace from a
specific storage/copy pool which is partly why this problem exists for me. I
am running TSM 5.1.6.2 has this capability been included in a later release?
Cheers
Andy Wilcox
Midrange Services
Aquila Networks Services Ltd
> -----Original Message-----
> From: Zlatko Krastev [SMTP:acit AT ATTGLOBAL DOT NET]
> Sent: 02 September 2003 18:07
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: move nodedata
>
> --> Has anyone tried eliminating the old copypool data by tweaking the
> copygroup parameters down to pretty much nothing ...
>
> Andy, you are suggesting something useless but VERY VERY dangerous!
> "Tweaking" copygroup parameters will force expiration of *primary* pool
> copies and only as a consequence expiration of copies in *both*
> copypools!!! There is no need to bother with "tweaking", `delete
> filespace` command will give you nearly the same results but I doubt you
> are willing to use it.
>
> --> ... although I could be wrong ...
>
> You are, indeed!
>
> Zlatko Krastev
> IT Consultant
>
>
>
>
>
>
> "Wilcox, Andy" <andy.wilcox AT AQUILA-NETWORKS.CO DOT UK>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 02.09.2003 14:21
> Please respond to "ADSM: Dist Stor Manager"
>
>
> To: ADSM-L AT VM.MARIST DOT EDU
> cc:
> Subject: Re: move nodedata
>
>
> Hiya Henrik,
>
> I have recently been doing pretty much what you are trying to achieve. The
> problem you have is the biggest issue with the move nodedata command. From
> reading across the many articles on here, it appears that the only way to
> get rid of the old copypool data is to delete the volumes containing the
> data.
>
> Luckily for me I am doing a massive tidyup and plan to remove our old
> copypools for this very reason.
>
> Food for thought though... Has anyone tried eliminating the old copypool
> data by tweaking the copygroup parameters down to pretty much nothing, and
> letting expiration clear most of it down? Would this even work, as I get
> the
> impression that the data in the old copypool maintains its original
> retention settings, although I could be wrong (I also assume that you
> would
> need to move the node into a new domain as well as tweaking the copygroup
> params would otherwise affect the live data)??? Any ideas?
>
> Cheers
>
> Andy Wilcox
> Midrange Services
> Aquila Networks Services Ltd
>
> > -----Original Message-----
> > From: Henrik Wahlstedt [SMTP:shwl AT STATOIL DOT COM]
> > Sent: 02 September 2003 09:51
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: move nodedata
> >
> > Hello,
> >
> > I wanted and tried to move a nodes data to a different storagepool,
> > non-collocated to collocated.
> > From dlt-standard with copypool to dlt-monthly with copypool-monthly.
> > (move nodedata xxx from=dlt-standard to=dlt-monthly)
> >
> > Move within primarypools went ok and I thought that admin schedules (ba
> > stg, expire inventory) would take care of my copypool. I was wrong.
> > Now I have my nodes data on both copypools but only on dlt-monthly
> > priamaypool. (q occ xxx)
> > I havn4t tried to move nodedata xxx from=copypool
> > to=copypool-monthly.......
> >
> > 1. What would I have done instead of move nodedata to get a better
> result?
> > 2. How do I get rid of the extra copy in copypool?
> > 3. Works as designed?
> >
> >
> >
> > tia
> > //Henrik
> >
> >
> >
> > tsm: STO-W03>h move nodedata
> > MOVE NODEDATA
> > ------------------------------------------------------------------------
> >
> > MOVE NODEDATA (Move Data by Node in a Sequential Access Storage Pool)
> >
> > Use this command to move data located in a sequential-access storage
> pool.
> > You can move data for one or more nodes, or a single node with selected
> > filespaces. The data can be located in either a primary or copy storage
> > pool.
> >
> > This command is helpful for reducing the number of volume mounts
> > during client restore or retrieve operations by consolidating data for a
> > specific node within a storage pool, or to move data to another storage
> > pool.
> >
> > For example, you can use this command for moving data to a
> > random-access storage pool in preparation for client restore processing.
> >
> > -------------------------------------------------------------------
> > The information contained in this message may be CONFIDENTIAL and is
> > intended for the addressee only. Any unauthorised use, dissemination of
> > the
> > information or copying of this message is prohibited. If you are not the
> > addressee, please notify the sender immediately by return e-mail and
> > delete
> > this message.
> > Thank you.
> >
> >
> >
> **************************************************************************
> > **************************
> > Confidentiality: This e-mail and any files transmitted with it are
> > confidential and intended solely for the use of the individual or entity
> > to whom they are addressed. If you have received this e-mail in error,
> > use of this information (including disclosure, copying or distribution)
> > may be unlawful. Please notify postmaster AT aquila-networks.co DOT uk. and
> > delete the message immediately.
> >
> > Security: Internet e-mail is not a 100% secure communications medium.
> >
> > Viruses: This e-mail (and any attachments) has been checked (using
> Sophos
> > Sweep 3.68 + patches) and found to be clean from any virus infection
> > before leaving.
> > Therefore neither Aquila Networks Services Ltd nor Midlands Electricity
> > plc or any of their group undertakings (as defined by the Companies
> Act
> > 1989) (together referred to as the "Companies") accept legal
> > responsibility for this message or liability for the consequences of any
> > computer viruses which may have been transmitted by this e-mail.
> >
> > Monitoring: All electronic communications with the Companies may be
> > monitored in accordance with the UK Regulation of Investigatory Powers
> > Act, Lawful Business Practice Regulations, 2000. If you do not consent
> to
> > such monitoring, you should contact the sender of this e-mail.
> >
> > Aquila Networks Services Limited,
> > Registered office: Whittington Hall, Whittington, Worcester, WR5 2RB
> > Registered in England and Wales number 3600545
> > This e-mail may be sent on behalf of any of the Companies.
> >
> **************************************************************************
> > **************************
|
