Endevor B4G disk space error

Products

• Endevor

Issue/Introduction

Installed Endevor B4G application on mainframe. ran 2 smaller maps without any issue, then tried to run 6900 file map and it is giving disk space error.  

            Caused by: ERROR XSDG1: Page Page(177,Container(0, 5168)) could not be written to disk, please check if the disk is full, or if a file system limit, such as a quota or a maximum file size, has been reached.

|               at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)

|               at org.apache.derby.impl.jdbc.SQLExceptionFactory.wrapArgsForTransportAcrossDRDA(Unknown Source)

|               ... 101 more

| Caused by: java.io.IOException: EDC5133I No space left on device.

 

B4G work directory is allocated at cyls - OMVS.NPR1.BFG.WORK.ZFS 2000 pri 1500 sec 

Environment

Release : 18.1

B4G 2.13.0

Cause

Bridge is retrieving elements from Endevor and has not enough space on disk to store them temporarily and new mapping initialization fails. As a result of not having a disk space, Bridge is not even able to update the embedded database. 

Resolution

Bridge was not primarily designed for z/OS and disk space requirements may seem relatively high (relative to other z/OS products), mostly it serves as a cache to save memory and CPU processing.

Make sure there is always enough disk space for B4G application:

• If disk space is not that big concern,  to start with, use 20GB primary and 10GB secondary allocation (20000 cyls primary and 10000 cyls secondary) for all B4G data, watch over the time and extend if needed.
• If disk space utilization is a concern, separate B4G application into multiple different ZFS clusters, for example one cluster for the Bridge installation, one for database, one for logs and one for stage and temp.  

 

Following list can be used as a baseline for tuning it in case disk space is a concern.

Overview of data stored by Bridge on disk:

• Embedded database (<workdir>/EVCS_root/db) 
• this is the most critical and irreplaceable resource
• this folder should always be backed up
• it must never run out of space since that corrupts integrity of the application
• database is not huge, but usually takes space in 100s of MBs or single digit GBs
• it can be placed to a different location (ZFS cluster) with separate allocation, backup policy etc.
• default location is part of JDBC URL and can be changed:

app:

  database:

    url: jdbc:derby:${app.workdir}/EVCS_root/db;create=true

 

• Staging directory (<workdir>/EVCS_root/stage)
• this location contains Bridge local clones of all synchronized repositories
• it works as a cache and Bridge can recreate when deleted (it has performance and resource cost, so don't delete often)
• it must accommodate clones (git clone) of all synchronized Git repositories (.git + worktree of the largest branch) at the same time
• The safe estimate would be double the size of all Endevor elements being synchronized

 

• Temporary files  (<workdir>/EVCS_root/temp)
• stores files retrieved from Endevor and not yet synchronized to Git
• it is temporary, when all synchronization are completed and none is running, it should be empty
• when running initialization size is sum of all elements in the respective mapping (technically those files will be moved to stage as a part of the processing, so it is counted within the previous stage size estimate)
• has orphan files removal policy:

app:

  rules:

    temporary-file-collector:

      enabled: true

      file-retention-hours: 72

      run-every-hours: 2

 

• Logs (<workdir>/logs)
• stores logs from the Bridge application
• size based on the log rotation policy, default is:

app:

  logging:

    max-history: 90

    max-file-size: 300MB

    total-size-cap: 1GB

• it can be placed to a different location, default is:

(root location, not under 'app')

logging:

  file:

    path: ${app.workdir}/logs