Hi Martha, I see this situation occur when a filesystem gets almost completely full.
Do 'q dirsp <dev-class-name>' to check for nearly full filesystems. The server doesn't fence off a filesystem like this, instead it keeps hammering on it, allocating new volumes. When it tries to write to a volume and gets an immediate out-of-space error, it marks the volume full so it won't try to use it again. I run this sql to find such volumes and delete them - select 'del v '||cast(volume_name as char(40)), cast(stgpool_name as char(30)), last_write_date - from volumes where upper(status) = 'FULL' and pct_utilized = 0 and pct_reclaim = 0 order by 2, 3 You should remove such filesystems from the devclass directory list until reclaim has emptied them a little bit. Hope his helps, Bill Colwell Draper Lab -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Martha M McConaghy Sent: Wednesday, October 22, 2014 2:23 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: 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 ________________________________ Notice: This email and any attachments may contain proprietary (Draper non-public) and/or export-controlled information of Draper Laboratory. If you are not the intended recipient of this email, please immediately notify the sender by replying to this email and immediately destroy all copies of this email. ________________________________
