Martha,

I guess your FS is quite large. You can obtain some free space by reducing the 
percentage of reserved blocks.

Default is 5%, you can safely decrease this value to 2%, see m option of the 
tune2fs command.

-- 
Best regards / Cordialement / مع تحياتي
Erwann SIMON

----- Mail original -----
De: "Martha M McConaghy" <martha.mcconaghy AT MARIST DOT EDU>
À: ADSM-L AT VM.MARIST DOT EDU
Envoyé: Mercredi 22 Octobre 2014 20:22:31
Objet: Re: [ADSM-L] TSM 7.1 usage of volumes for dedupe

Interesting.  Seems very similar, except the status of these volumes is
"FULL", not "EMPTY".  However, the %reclaimable space is 0.0.

I think this is a bug.  I would expect the volume to leave the pool once
it is "reclaimed".  It would be OK with me if it did not. However, since
the status is "FULL", it will never be reused. That seems wrong.  If it
is going to remain attached to the dedupepool, the status should convert
to EMPTY so the file can be reused.  Or, go away altogether so the space
can be reclaimed and reused.

In looking at the filesystem on the Linux side (sorry I didn't mention
this is running on RHEL), the file exists on /data0, but with no size:

[urmm@tsmserver data0]$ ls -l *d57*
-rw------- 1 tsminst1 tsmsrvrs 0 Oct 10 20:22 00000d57.bfs

/data0 is 100% utilized, so this file can never grow.  Seems like it
should get cleaned up rather than continue to exist.

Martha

On 10/22/2014 1:58 PM, Erwann SIMON wrote:
> hi Martha,
>
> See if this can apply :
> www-01.ibm.com/support/docview.wss?uid=swg21685554
>
> Note that I had a situation where Q CONT returned that the volume was empty 
> but it wasn't in reality since it was impossible to delete it (without 
> discrading data). A select statement against the contents showed some files. 
> Unforunately, I don't know how this story finished...
>

--
Martha McConaghy
Marist: System Architect/Technical Lead
SHARE: Director of Operations
Marist College IT
Poughkeepsie, NY  12601