Flashes (Alerts)
Abstract
IBM has identified a problem with the IBM Spectrum Scale 5.1.2 and 5.1.3 code level (5.1.2.0 to 5.1.2.3; 5.1.3.0; ESS 6.1.2.0 to 6.1.2.2) where, when opening a file with the O_TRUNC flag (when the file is created by another node), that flag fails to take affect, and the file is not truncated as expected. That causes subsequent writes to overwrite the prior content instead of erasing it. The result is undetected data corruption, since the content of the file does not correspond to the latest data which was written into the file after truncation.
Content
Problem Summary
:
When a file is opened with O_TRUNC included in the flag passed as the second argument to the open(2) system call, the expectation is that the file content gets truncated. That is, any prior content in the file is erased and the file size should go back to zero. Because of an issue in Spectrum Scale, the O_TRUNC flag may not take effect when used in conjunction with the O_CREAT flag. As a result, a subsequent write only overwrites the content of the file. If the write operation produces fewer bytes than what were previously present in the file, the file contents will be the newly written data, followed by the remaining bytes which had been previously written. The problem happens if the initial write and the subsequent write (which is performed with open() using the O_TRUNC flag) are issued on different nodes.
Because of the missing truncation, the file may become larger than expected, which also means that any append to the file (which starts at the prior file size) may be done at an incorrect location.
Notes:
- The O_CREAT and O_TRUNC flags for open(2) are used by the shell when output is redirected to a file with the ">" construct .
- The problem may also happen with the creat() system call, since that is equivalent to open(O_CREAT | O_WRONLY | O_TRUNC).
- Linux system call openat2() is similarly impacted.
This is an example of how the presence of the problem is demonstrated:
- Initially, file test_file does not exist. Node 1 creates a file.
- # echo "12345678" > test_file
- Node 2 echo a new content to the file:
- # echo "ab" > test_file
- The file contains the new text and partial text from the previous write:
- #cat test_file
ab
45678
The size of the file doesn't shrink to 3 bytes: it remains 9 bytes, and parts of the previous data are still accessible.
Users Affected:
Users may be affected if all conditions below are true :
- Running Spectrum Scale on Linux
- The impacted Spectrum Scale levels are being used: Scale 5.1.2.0 to 5.1.2.3 and 5.1.3.0 (ESS 6.1.2.0 to 6.1.2.2)
- Applications open files with the O_CREAT and O_TRUNC flags, and write into the (initially non-existing) same file, from different nodes. The second write should be for fewer bytes than what has been initially written for the problem to be noticed.
Recommendations:
Customers running the affected version, please request an efix :
- For IBM Spectrum Scale V5.1.2.0 - V5.1.2.2, please refer APAR IJ37542 and IJ38578
- For IBM Spectrum Scale V5.1.2.3 - V5.1.3.0 - please refer APAR IJ38578
- Users running IBM ESS V6.1.2.0 to V 6.1.2.2 , request you to please request an efix APAR IJ37542 and IJ38578
[{"Type":"MASTER","Line of Business":{"code":"LOB26","label":"Storage"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"STXKQY","label":"IBM Spectrum Scale"},"ARM Category":[{"code":"a8m3p000000hAkYAAU","label":"GPFS"}],"ARM Case Number":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"5.1.2;5.1.3"}]
Was this topic helpful?
Document Information
Modified date:
31 March 2022
UID
ibm16558502