>I wasn’t sure if afmDirLookupRefreshInterval and afmFileLookupRefreshInterval would be the right thing if it’s a file/directory that doesn’t exist?
These refresh intervals applies to all the lookups and not just for negative lookups. For working around in AFM itself, you could try setting these refresh intervals to higher value if cache does not need to validate with home often. ~Venkat (vpuvv...@in.ibm.com) From: david_john...@brown.edu To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org> Date: 05/30/2018 06:14 PM Subject: Re: [gpfsug-discuss] AFM negative file caching Sent by: gpfsug-discuss-boun...@spectrumscale.org Another possible workaround would be to add wrappers for these apps and only add the AFM based gpfs directory to the LD_LIBARY_PATH when about to launch the app. -- ddj Dave Johnson > On May 30, 2018, at 8:26 AM, Peter Serocka <pesero...@gmail.com> wrote: > > As a quick means, why not adding /usr/lib64 at the beginning of LD_LIBRARY_PATH? > > (Not to get started on using LD_LIBRARY_PATH in the first place…) > > > — Peter > >> On 2018 May 30 Wed, at 13:52, Simon Thompson (IT Research Support) <s.j.thomp...@bham.ac.uk> wrote: >> >> Hi All, >> >> We have a file-set which is an AFM fileset and contains installed software. >> >> We’ve been experiencing some performance issues with workloads when this is running and think this is down to LD_LIBRARY_PATH being set to the software installed in the AFM cache, e.g. >> >> /gpfs/apps/somesoftware/v1.2/lib >> >> Subsequently when you run (e.g.) “who” on the system, LD_LIBRARY_PATH is being searched for e.g. libnss_ldap, which is in /usr/lib64. We’re assuming that AFM is checking with home each time the directory is processed (and other sub directories like lib/tls) and that each time AFM is checking for the file’s existence at home. Is there a way to change the negative cache at all on AFM for this one file-set? (e.g as you might with NFS). The file-set only has applications so changes are pretty rare and so a 10 min or so check would be fine with me. >> >> Thanks >> >> Simon >> >> _______________________________________________ >> gpfsug-discuss mailing list >> gpfsug-discuss at spectrumscale.org >> http://gpfsug.org/mailman/listinfo/gpfsug-discuss > > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at spectrumscale.org > http://gpfsug.org/mailman/listinfo/gpfsug-discuss _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss