IBM Support

IBM Spectrum Scale (GPFS): Undetected corruption of archived sparse files (Linux)

Flashes (Alerts)


Abstract

IBM has identified an issue with IBM GPFS and IBM Spectrum Scale for Linux environments, in which a sparse file may be silently corrupted during archival, resulting in the file being restored incorrectly.

Content

Problem Summary:

A problem has been identified with how the SEEK_DATA parameter to the lseek(2) system call is handled in Spectrum Scale. An incorrect value is returned when lseek(2) is invoked with the option on a sparse file, that is, a file with "holes" which are created by seeking beyond the end of the file.

When the option is used by an archiving application, such as tar, a sparse file may be incorrectly archived, resulting in the file being incorrectly restored later.

For example, create a sparsely allocated GPFS file, as follows:
# truncate test_file --size 100M
# dd if=/dev/urandom of=test_file bs=4M count=1 oflag=seek_bytes,direct seek=16M conv=notrunc


The real file size of the sparse file is 4MB:
# ll -sh
4.0M -rw-r--r-- 1 root root 100M Jan 24 02:06 test_file


From offset 0 to offset 16777215 there is a hole in the file, and no data blocks are allocated for that region of the file.
From offset 16777216 to offset 20971519 (4MB), the file contains data.

In the presence of the problem, the lseek(2) system call with argument offset pointing to the start of the file, and the directive whence equal to SEEK_DATA, will return offset -1, with errno set to 6. That is incorrect, with the correct behavior being a return value offset of either 16777216 or offset 0. The first value is the expected location of the next region of the file with data, while the second is still allowed in the Linux specification for the SEEK_DATA parameter support.

When creating a tar archive from the sparse file as shown below:
~/tar.1.29/usr/bin/tar --sparse --hole-detection=seek -cf test_file.tar test_file
or
~/tar.1.29/usr/bin/tar --sparse -cf test_file.tar test_file


The archive file size is smaller than 4MB:
16K -rw-r--r-- 1 root root 10K Jan 24 02:48 test_file.tar

When untar'ing the archive file, the sparse file is empty:
0 -rw-r--r-- 1 root root 100M Jan 24 02:06 test_file

The od command below shows that there is no longer any data in the sparse file, which reads as a sequence of 0s.
# od -A d test_file
0000000 000000 000000 000000 000000 000000 000000 000000 000000
*
104857600


While the problem may surface in any archiving applications which use the SEEK_DATA parameter to the lseek(2) system call, the first version of the tar program that experiences the problem is 1.29.

Users affected:

Linux users of IBM Spectrum Scale having applications which depend on the SEEK_DATA option of lseek(2) for sparse file handling (such as archiving applications) are potentially affected, including tar version 1.29 or later.

Recommendations:

1. Affected users should contact IBM Service to apply an efix:

- For IBM Spectrum Scale V5.0.0.0, reference APAR IJ03365

- For IBM Spectrum Scale V4.2.0.0 through V4.2.3.6, reference APAR IJ03353

- For IBM GPFS V4.1.0.0 through V4.1.0.8, or IBM Spectrum Scale V4.1.1.0 through V4.1.1.18, reference APAR IJ03312

2. Use older versions of the applications, which do not use the SEEK_DATA option of lseek(2).

3. Do not use any options in applications that rely on the SEEK_DATA option of lseek(2). For example, for versions 1.29 or newer of tar, use option --hole-detection=raw.

4. If you believe that your Spectrum Scale (GPFS) file system may be affected by this issue, you should contact IBM Service as soon as possible for further guidance and assistance.

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"STXKQY","label":"IBM Spectrum Scale"},"Component":"--","Platform":[{"code":"PF016","label":"Linux"}],"Version":"4.1.1;4.2.0;4.2.1;4.2.2;4.2.3;5.0.0","Edition":"","Line of Business":{"code":"LOB26","label":"Storage"}}]

Document Information

Modified date:
25 September 2022

UID

ssg1S1012054