2 Replies Latest reply on Nov 25, 2014 10:12 AM by Yanick Girouard

    how to safely eliminate duplicate copies of patches on fileserver?

      Our fileserver has 132 GB largely dedicated to /data, but it's almost full. We are getting ready to add more disk, and I'm trying to determine how big it needs to be. In looking at it, there are multiple copies of each patch - /var/data/installables alone contains 16 unique copies of WindowsServer2003-KB941693.exe, and there seem to be 241 copies of that one patch on the system, in /data/blpackages and /data/installables.


      How can I target copies for deletion, and what can I do to avoid this kind of proliferation in the future? Thanks.

        • 1. Re: how to safely eliminate duplicate copies of patches on fileserver?
          Bill Robinson

          to remove unused files from the file server use the blcli Delete commands (cleanupFileServer or performFullCleanup). check w/ support about running cleanup because there were issues w/ cleanup in 7.3 and 7.4.1 I think.


          In the future, you should 'symlink' or 'softlink' when you create blpackages that deploy hotfixes, otherwise you will make copies of the binary for the new package.


          also, if multiple roles are uploading patches and they cannot see the other's patches, there will be duplicates, so you could look at restructuring RBAC such that there is some kind of sharing for downloading patches.

          • 2. Re: how to safely eliminate duplicate copies of patches on fileserver?
            Yanick Girouard

            Normally, you should point the payload repository location of all your patch catalogs (if you have more than one) to the same directory on your file server, precisely to avoid duplicating files. This where the actual physical payload (the .exe or .msu) will reside.


            When patches are created as depot objects, they always soft-link the file and reference it from that file server's payload location, so it's not possible to have actual duplicates.


            What you may see however, is duplicated metadata (the xml that defines the blpackage) that is created during a patch remediation job, becuase you can have multiple blpackages referencing the same patch, but that shouldn't include a hard copy of the payload file, only a reference of its location.


            What DOES happen however, is that even though depot objects (patches) are removed form the catalog when you run the Remove Irrelevant Patches action on the catalog, the associated payload file is NOT removed from the file server physically, only the database portion is removed. This means you may have several gigs worth of orphan files in your payload repository location. To resolve this, you'll need o run a custom NSH script job that BMC can provide you. Bill wrote a script for us to do this and we cleared over 30G with it.


            The blpackages and installables folders should be automatically cleaned by the cleanup scripts/jobs that are documented in docs.bmc.com (search for database cleanup). These folders are not where the patch payloads (from patch catalogs) are kept however. The installables folder contains files from packages that were uploaded from the console I believe, and the blpackages one contains references to other objects. If the blpackage is soft-linking a file, it won't be in the blpackage's metadata directory, but it it's hard-linking it then it will.