This document describes the authorized program analysis reports (APARs) resolved in IBM Storage Scale 5.2.1.x releases.
This document was last updated on 26th September, 2024.
Tips:
| APAR | Severity | Description | Resolved in | Feature Tags | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| IJ52205 | High Importance | mmapplypolicy performs an inode scan in parallel and the number of iscanBuckets can be specified via -A option. If the -A option is not specified, tsapolicy calculates it based on total used inodes between 7 to 4096. In a large file system, the value calculated is often larger than the open file limit, and tsapolicy could fail with "'Too many open files".
(show details)
|
5.2.1.1 | mmapplypolicy | ||||||||
| IJ52208 | High Importance | When a message is sending to multiple destinations, if reconnect happens while the sender thread is still doing sending, do the resend in another thread could cause this assert.
(show details)
|
5.2.1.1 | All Scale Users | ||||||||
| IJ52221 | High Importance | Dangling entry in RO mode after re-uploading data to cos
(show details)
|
5.2.1.1 | AFM | ||||||||
| IJ52271 | High Importance | tsapolicy gets current cipherList setting from mmfs.cfg but it gets empty string if cipherList configuration variable is set to the default value (EMPTY). tsapolicy incorrectly determines the value as real cipher if the value is not "EMPTY", "DEFAULT", or "AUTHONLY".
(show details)
|
5.2.1.1 | mmapplypolicy | ||||||||
| IJ52265 | High Importance | Unable to handle kernel paging request crash in kxGanesha. The problem happens because thevalue of fdp->fd has changed after it was copied it.
(show details)
|
5.2.1.1 | NFS Ganesha | ||||||||
| IJ52272 | High Importance | 2024-08-26_04:00:08.796+0100: [X] *** Assert exp(context != unknownOp) in line 6125 of file /project/sprelgpfs519/build/rgpfs519s005i/src/avs/fs/mmfs/ts/fs/openfile.C 2024-08-26_04:00:08.796+0100: [E] *** Traceback: 2024-08-26_04:00:08.796+0100: [E] 2:0x55AE8B58E84A logAssertFailed + 0x3AA at ??:0 2024-08-26_04:00:08.796+0100: [E] 3:0x55AE8B2E093D LockFile(OpenFile**, StripeGroup*, FileUID, OperationLockMode, LkObj::LockModeEnum, LkObj::LockModeEnum*, LkObj::LockModeEnum*, int, int) + 0x69D at ??:0 2024-08-26_04:00:08.796+0100: [E] 4:0x55AE8B22CB2B FSOperation::createLockedFile(StripeGroup*, FileUID, OperationLockMode, LkObj::LockModeEnum, OpenFile**, unsigned int*, int, int) + 0x9B at ??:0 2024-08-26_04:00:08.796+0100: [E] 5:0x55AE8B8D4F4C markAuditLogInactive(StripeGroup*, FileUID) + 0x5C at ??:0 2024-08-26_04:00:08.796+0100: [E] 6:0x55AE8B8DE14C AuditWriter::processRequest(WriteRequest) + 0x3FC at ??:0 2024-08-26_04:00:08.796+0100: [E] 7:0x55AE8B8C5DFE serveWriteRequests(WriteRequest const&, void*) + 0xBE at ??:0 2024-08-26_04:00:08.796+0100: [E] 8:0x55AE8B8C61A0 AuditWriter::callback() + 0x1A0 at ??:0 2024-08-26_04:00:08.796+0100: [E] 9:0x55AE8B036C42 RunQueue::threadBody(RunQueueWorker*) + 0x392 at ??:0 2024-08-26_04:00:08.796+0100: [E] 10:0x55AE8B038EC2 Thread::callBody(Thread*) + 0x42 at ??:0 2024-08-26_04:00:08.796+0100: [E] 11:0x55AE8B025EC0 Thread::callBodyWrapper(Thread*) + 0xA0 at ??:0 2024-08-26_04:00:08.796+0100: [E] 12:0x7FA83AF9A1CA start_thread + 0xEA at ??:0 2024-08-26_04:00:08.796+0100: [E] 13:0x7FA839C9F8D3 __GI___clone + 0x43 at ??:0 mmfsd: /project/sprelgpfs519/build/rgpfs519s005i/src/avs/fs/mmfs/ts/fs/openfile.C:6125: void logAssertFailed(UInt32, const char*, UInt32, Int32, Int32, UInt32, const char*, const char*): Assertion `context != unknownOp' failed. (show details)
|
5.2.1.1 | File Audit Logging | ||||||||
| IJ52321 | High Importance | Daemon assert logAssertFailed: isNotCached() while disabling the AFM online with afmFastLookup enabled. This happens due to accessing the invalid fileset pointer.
(show details)
|
5.2.1.1 | AFM | ||||||||
| IJ52324 | High Importance | ACLs are not fetched to AFM cache from the home when the opened AFM control file becomes stale. AFM control file is used to fetch ACLs and EAs from the home.
(show details)
|
5.2.1.1 | AFM | ||||||||
| IJ52362 | Suggested | "mmperfmon delete" returns with rc=0 even when user is passing the wrong arguments. For eg. the "mmperfmon delete --expiredkeys --wait 0" exit with a error but returns "0" as its exit code rather than "1".
(show details)
|
5.2.1.1 | perfmon (ZIMON) | ||||||||
| IJ52322 | Suggested | When a previous snapshot is created with the expiration time set, the next snapshot created can get the expiration time of the previous snap when the expiration time is not explicitly provided for this next snapshot.
(show details)
|
5.2.1.1 | Snapshots | ||||||||
| IJ52511 | Suggested | Issuing the undocumented "tsdbfs test patch desc format" command results in mmfsd failures on other nodes.
(show details)
|
5.2.1.1 | All Scale Users | ||||||||
| IJ52512 | High Importance | During some delete snapshot operations, the parallel inode traversal (PIT) operation may unexpectedly fail with an assertion when trying to send the interesting inodes file back to the client command.
(show details)
|
5.2.1.1 | GPFS Core | ||||||||
| IJ52514 | Suggested | Currently if any request to mmsysmon.py times out, the customers get this error message, which is hard to understand and also does not state the fact, that we have reached the timeout.
(show details)
|
5.2.1.1 | perfmon (ZIMON) | ||||||||
| IJ51901 | Critical | Undetected data and directory corruption may be left on disk
(show details)
|
5.2.1.0 | All Scale Users | ||||||||
| IJ51902 | Critical | When writing an exising large file (indirect block level is at least 2) while one or more disks are down and if metanode failes immediately after writing the data,the "mmchdisk start" command may not repair the down disk which has stale data, then results in stale data left on the disk.
(show details)
|
5.2.1.0 | All Scale Users |