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 *
>