> Op 30 okt. 2014, om 22:04 heeft Colwell, William F. <bcolw...@draper.com> het > volgende geschreven: > > Hi Martha, > > I am glad this was useful to you. > > I have not reported this as a bug; I expect they would say > working-as-designed, try > submitting an rfe.
I never understood that working as designed is a reason to close a call. If the design is bodged, then it should be fixed. I’ve been told that even TSM is designed by people, and I’m sure sometimes those do make mistakes. > > - bill > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Martha M McConaghy > Sent: Thursday, October 30, 2014 10:09 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: TSM 7.1 usage of volumes for dedupe > > Bill, > > I just wanted to let you know how much this information helped. I was > able to clear out all the problem volumes and have removed the full LUNs > from the devclass until there is enough space on them to be used again. > > This situation really seems strange to me. Why has TSM not been updated > to handle the out of space condition better? If it has a command that > shows how much space is left on the LUN, why can't TSM understand it is > time to stop allocating volumes on it? Forcing admins to do manual > clean up like this just to keep things healthy seems inconsistent with > how the rest of TSM functions. > > Has anyone ever reported this as a bug? > > Martha > > On 10/22/2014 2:38 PM, Colwell, William F. wrote: >> 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. >> ________________________________ > > -- > 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. > ________________________________ -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622