Re: [ADSM-L] Re: How to exclude bad Linux mountpoint

Maybe you can identify characteristics of the bogus disks and create udev
rules so they won't be mounted at all?

Or for another TSM-only idea, since you can unmount them, maybe put the
umount commands in a script and add a PRESChedulecmd to run the script before
each backup?  (Not sure if that precedes the client's enumeration of the
filesystems, but I would hope so.)

=Dave


On 02/08/2017 07:52 AM, Zoltan Forray wrote:
> We have unmounted it but It keeps coming back and will until Dell fixes it.
>
> On Wed, Feb 8, 2017 at 8:36 AM, Rick Adamson <RickAdamson AT segrocers DOT 
> com>
> wrote:
>
>> Zoltan,
>>
>> Would it be acceptable to just force an unmount of the ghost FS ?
>>
>> I had a similar situation where a vendor was hired to perform some
>> analytics on our 150 Linux servers, his removal process failed, leaving the
>> mount points.
>>
>> For me that was easier......
>>
>>
>>
>> -Rick Adamson
>>
>>
>> -----Original Message-----
>>
>> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
>> Of
>> Zoltan Forray
>>
>> Sent: Tuesday, February 07, 2017 4:07 PM
>>
>> To: ADSM-L AT VM.MARIST DOT EDU
>>
>> Subject: Re: [ADSM-L] How to exclude bad Linux mountpoint
>>
>> Thanks for the suggestions.  I forgot about the EXCLUDE.FS which seems to
>> have done the trick since it is a filesystem (see df below).  Now to roll
>> this out to all of my Linux servers.
>>
>> [zforray@processor ~]$ df -m
>> Filesystem           1M-blocks    Used Available Use% Mounted on
>> /dev/mapper/vg_processr_sys-lv_root
>>                          20031    7123     11885  38% /
>> tmpfs                    48339       1     48339   1% /dev/shm
>> /dev/sdb2                  477     108       344  24% /boot
>> /dev/sdb1                  100       1       100   1% /boot/efi
>> /dev/mapper/vg_processr_sys-lv_home
>>                          50269   10818     36891  23% /home
>> /dev/mapper/vg_processr_sys-lv_tsmarchlog
>>                         302380     480    301901   1% /tsmdb2
>> /dev/mapper/vg_processr_sys-lv_tsmarchlog2
>>                         151190     348    150843   1% /tsmarchlog2
>> /dev/mapper/vg_processr_sys-lv_tsmdb
>>                         403174  364843     38331  91% /tsmdb
>> /dev/mapper/vg_processr_sys-lv_tsmlog
>>                         129016  120165      2298  99% /tsmlog
>> /dev/mapper/vg_processr_pool-lv_tsmpool
>>                       10133861 9618741       344 100% /tsmpool
>> /dev/mapper/vg_processr_sys-lv_var
>>                          14991     878     13346   7% /var
>> /dev/sdd                     2       0         2   0% /tmp/SECUPD
>> /dev/sde                     2       0         2   0% /tmp/SECUPD
>>
>>
>>
>> On Tue, Feb 7, 2017 at 3:05 PM, Andrew Raibeck <storman AT us.ibm DOT com> 
>> wrote:
>>
>>> Hi Zoltan,
>>>
>>> It could be the simple act of enumerating file systems or mount points
>>> that causes a problem. What kinds of problems, specifically, are you seeing?
>>>
>>> A couple of thoughts (not sure these will help):
>>>
>>> - Does this show up as a separate file system, such as when you do df -m?
>>> If yes, you could try exclude.fs /tmp/SECUPD
>>>
>>> - Another possibility is to define it as a virtual mount point using
>>> the VIRTUALMOUNTPOINT option, then using exclude.fs.
>>>
>>> Finally, a total "shot in the dark", but try searching the internet
>>> for this directory name. One discussion I found indicates that
>>> /tmp/SECUPD is causing other issues, too:
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__en.
>> community.dell.com_support-2Dforums_servers_f_956_t_19996605&d=DwIGaQ&c=
>> AzgFQeXLLKhxSQaoFCm29A&r=uJG3UnPaeoz9naeIzbwWFddVED8ETOYHxjoACoofi2Y&m=
>> dpyZFjUm5jdJEy7vIroIPKAZVkonlHvpInjN-PV6Njo&s=
>> emQBeN08TImOrf5CKuScl7Pu2yElvurRtxPTdEAeZps&e=
>>>
>>> Regards,
>>>
>>> Andy
>>>
>>> ____________________________________________________________
>>> ________________
>>>
>>> Andrew Raibeck | IBM Spectrum Protect Level 3 | storman AT us.ibm DOT com
>>>
>>> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2017-02-07
>>> 14:45:50:
>>>
>>>> From: Zoltan Forray <zforray AT VCU DOT EDU>
>>>> To: ADSM-L AT VM.MARIST DOT EDU
>>>> Date: 2017-02-07 14:46
>>>> Subject: How to exclude bad Linux mountpoint Sent by: "ADSM: Dist
>>>> Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>>>>
>>>> Ever since a certain Dell update, a ghost mountpoint of /tmp/SECUPD
>>>> is left hanging after iDRAC/OpenManage updates.  This is now causing
>>>> heartburn for TSM backups.
>>>>
>>>> I have tried pushing down via CLOPTSET to
>>>>
>>>> exclude.dir /tmp/SECUPD
>>>> exclude /tmp/SECUPD
>>>>
>>>> but neither work - TSM still tries to access/back it up.
>>>>
>>>> Any suggestions on how to get TSM to stop trying to access this mount?
>>
>

--
Hello World.                                David Bronder - Systems Architect
Segmentation Fault                                      ITS-EI, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm.   david-bronder AT uiowa 
DOT edu