> Op 30 okt. 2014, om 22:04 heeft Colwell, William F. <bcolwell AT DRAPER DOT
> 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 AT VM.MARIST DOT EDU] On Behalf
> Of Martha M McConaghy
> Sent: Thursday, October 30, 2014 10:09 AM
> To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On Behalf
>> Of Martha M McConaghy
>> Sent: Wednesday, October 22, 2014 2:23 PM
>> To: ADSM-L AT VM.MARIST DOT 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.post AT plcs DOT nl
+31 6 248 21 622
|
