OnDemand User Group
Support Forums => MP Server => Topic started by: rmazurki on November 28, 2019, 07:07:47 AM
-
Hi,
Our env: Linux Redhat v6.10, CMOD v9.5, DB2 v11.1, TSM, we have separate servers for library and object server.
We have problem with free space on cache filesystem on object servers - it is virtual server and we have no more slots for memory (vmware limit, most of filesystems are used by TSM) - so, we cannot easily add more space to cache filesystem.
We want to make some free space in cache by running arsmaint and it seems it is not working properly.
When I run arsmaint with "-v" option then I have a lots of messages 198 type - "Invalid ownership and/or permissions on cache file/directory >/arscache/cache1/P3AE21/18224/OEA/DOC/45807WCAA< Srvr->ap-tulse1p.oneadr.net x.x.x.x non-SSL<-".
But when I check /arscache folder then it seems it is fine. Owner of these folder and instance is root, so - no problem.
There is a difference in instance owner between library and object server.
For library server instance owner is "db2inst1" user which can also run db2, and on object server instance owner is root.
So, maybe this is problem reason?
And if run arsmaint tool on library server it is clearing cache only on library server cache even if we run it for application group which has storage node defined only on object server.
So, currently we are close to physically delete some data from cache filesystem. It should be no problem because we have setup with loading file into TSM the same time as into cache.
Regards
Rafal
-
Well, it means what it says...
There's a permissions issue with the directories or folders... Check Alessandro's presentation on Cache Filesystems from the 2019 ODUG Technical Webinar: http://www.odusergroup.org/forums/index.php?topic=2640.0
One more thing... You shouldn't be running as root anymore. This is a security issue - if CMOD were to be compromised, an attacker would get root privileges.
-JD.
-
I have an additional question: are data in cache compressed?
-
All data loaded into CMOD if the Application definition has a compression method selected.
It's one of the major selling points for CMOD - AFP and PDFs* are 'de-duplicated', then compressed. Only formats that are already compressed (JPEG, GIF, TIFF) should have compression set to 'Disable', since trying to compress these already-compressed format usually wastes CPU and results in larger files.
* PDF files processed by the new-and-improved PDF indexer are de-duplicated and compressed, PDFs loaded with the old PDF indexer are stored whole, like a JPEG, GIF, or TIFF.
-JD.
-
Well, it means what it says...
Yes, it was issue with permissions - after fixing this arsmaint for cache works well :)
Thanks for help :)
-
I did some experiments with running ARSMAINT on library server and then on object server (servers are separated - LS is one host and OS is another) and I have following conclusion:
- ARSMAINT is maintaining cache on server on which script is run
So, If You run ARSMAINT on library server then it will maintenance cache on library server and cache on object server will not be maintained
Is that correct?
-
I did some experiments with running ARSMAINT on library server and then on object server (servers are separated - LS is one host and OS is another) and I have following conclusion:
- ARSMAINT is maintaining cache on server on which script is run
So, If You run ARSMAINT on library server then it will maintenance cache on library server and cache on object server will not be maintained
Is that correct?
I had a PMR like this years ago. If I remember correctly, Starting in 8.5, you have to run arsmaint on your library server.
We had a one libserver, 2 object server environment, I was running arsmaint on my object server and nothing was happening. This came directly from IBM support. Unfortunately I don't have a tech document or anything like that. However, I am sure if you open up a PMR with IBM they can guide you in the right direction.