Re: [ADSM-L] Move data to another storage pool
2013-10-10 17:28:08
Does Q CONTENT show filenames for you?
Mine shows nothing.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Erwann Simon
Sent: Thursday, October 10, 2013 4:25 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Move data to another storage pool
Hi all,
I'm also seeing quite the same : moving data (move nodedata) from a
deduplication enabled file pool to an LTO pool completes as successfull but
some files are still present for the node in the source pool (q content, q
nodedata...). And nothing appears in the actlog.
--
Best regards / Cordialement / مع تحياتي
Erwann SIMON
----- Mail original -----
De: "Tristan Kelkermans" <tkelkermans AT ATOOSYS DOT COM>
À: ADSM-L AT VM.MARIST DOT EDU
Envoyé: Jeudi 10 Octobre 2013 22:18:48
Objet: Re: [ADSM-L] Move data to another storage pool
Yes, nothing in the actlog and the move data completes with Success state...
Tristan
> Le 10 oct. 2013 à 20:45, Andrew Raibeck <storman AT us.ibm DOT com> a écrit :
>
> Have you reviewed the TSM server activity log for the time period of
> the MOVE DATA command to see if any warning or error messages were
> issued for that process?
>
> - Andy
>
> ______________________________________________________________________
> ______
>
> Andrew Raibeck | Tivoli Storage Manager Level 3 Technical Lead |
> storman AT us.ibm DOT com
>
> IBM Tivoli Storage Manager links:
> Product support:
> http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivol
> i_Storage_Manager
>
> Online documentation:
> https://www.ibm.com/developerworks/mydeveloperworks/wikis/home/wiki/Ti
> voli
> +Documentation+Central/page/Tivoli+Storage+Manager
> Product Wiki:
> https://www.ibm.com/developerworks/mydeveloperworks/wikis/home/wiki/Ti
> voli
> +Storage+Manager/page/Home
>
> "ADSM: Dist Stor Manager" <ADSM-L AT vm.marist DOT edu> wrote on 2013-10-10
> 10:45:42:
>
>> From: Tristan Kelkermans <tkelkermans AT ATOOSYS DOT COM>
>> To: ADSM-L AT vm.marist DOT edu,
>> Date: 2013-10-10 10:46
>> Subject: Re: Move data to another storage pool Sent by: "ADSM: Dist
>> Stor Manager" <ADSM-L AT vm.marist DOT edu>
>>
>> Hi,
>>
>> Absolutely both are storage pools with dedup enabled. Maybe it has to
>> do with tails of big files written in these volumes as Grigori said
>> but i'm not sure about it.
>>
>> Query content doesn't show any files in those volumes but when you do
>> an audit volume it finds more than one file in it..
>>
>> Tristan
>>
>>
>> 2013/10/10 Prather, Wanda <Wanda.Prather AT icfi DOT com>
>>
>>> I am having a similar problem.
>>> Is this a deduplicated storage pool?
>>> In my case I'm suspecting that has something to do with it.
>>>
>>>
>>> -----Original Message-----
>>> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
>>> Behalf
> Of
>>> Tristan Kelkermans
>>> Sent: Wednesday, October 09, 2013 12:19 PM
>>> To: ADSM-L AT VM.MARIST DOT EDU
>>> Subject: [ADSM-L] Move data to another storage pool
>>>
>>> Hello all,
>>>
>>> I'm moving content from one storage pool to another one using
>>> command
> move
>>> data *volume_name *stg=*other_stg*
>>> *
>>> *
>>> Unfortunately, some volumes stay in 'Filling' status whereas the
>>> move
> data
>>> process completed successfully.
>>> When I try to move data from this volume again, nothing changes.
>>>
>>> Also, this volume can be move to another volume in the same storage
> pool
>>> but it takes a completely new scratch volume to do it.
>>>
>>> When I run an audit volume I can see there are some files in it, but
> none
>>> of these are damaged. A query content doesn't show anything...
>>>
>>> VOLUME_NAME: N:\TSM_SATA\000E1EF0.BFS
>>>
>>> STGPOOL_NAME: DISK_VM
>>>
>>> DEVCLASS_NAME: FILECLASS_SATA
>>>
>>> EST_CAPACITY_MB: 51200.0
>>>
>>> SCALEDCAP_APPLIED:
>>>
>>> PCT_UTILIZED: 0.0
>>>
>>> STATUS: FILLING
>>>
>>> ACCESS: READWRITE
>>>
>>> PCT_RECLAIM: 0.0
>>>
>>> SCRATCH: YES
>>>
>>> ERROR_STATE: NO
>>>
>>> NUM_SIDES: 1
>>>
>>> TIMES_MOUNTED: 4
>>>
>>> WRITE_PASS: 1
>>>
>>> LAST_WRITE_DATE: 2013-09-17 02:09:51.000000
>>>
>>> LAST_READ_DATE: 2013-10-09 18:10:45.000000
>>>
>>> PENDING_DATE:
>>>
>>> WRITE_ERRORS: 0
>>>
>>> READ_ERRORS: 0
>>>
>>> LOCATION:
>>>
>>> MVSLF_CAPABLE: No
>>>
>>> CHG_TIME: 2013-10-09 12:08:18.000000
>>>
>>> CHG_ADMIN: TRISTAN
>>>
>>> BEGIN_RCLM_DATE:
>>>
>>> END_RCLM_DATE:
>>>
>>> VOL_ENCR_KEYMGR:
>>>
>>> BLOCK_PROTECT: No
>>>
>>> Any idea with this issue ?
>>>
>>> Thanks for you help
>>>
>>> Regards,
>>> *Tristan *
|
|
|