Limit mmapwrite file size

[aerusso]

Motivation and Context

mmapwrite spawns several threads, all of which perform writes on a file for the purpose of testing the behavior of mmap(2)-ed files. One thread performs an mmap and a write to the beginning of that region, while the others perform regular writes after lseek(2)-ing the end of the file.

Because these regular writes are set in a while (1) loop, they will write an unbounded amount of data to disk. The mmap_write_001_pos test script SIGKILLs them after 30 seconds, but on fast testbeds, this may be enough time to exhaust the available space in the filesystem, leading to spurious test failures (see #14277).

Description

Limit the total file size by checking that the lseek return value from the regular write threads is no greater than 250 MB, which is less than the default minimum vdev size defined in includes/default.cfg.

How Has This Been Tested?

Submitting this to the build servers for testing, presently. I will also run this locally on a machine that exhibited the problem before.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[ryao]

Coverity reports that this caused a file descriptor leak:

Hi,

Please find the latest report on new defect(s) introduced to openzfs/zfs found with Coverity Scan.

1 new defect(s) introduced to openzfs/zfs found with Coverity Scan.


New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)


** CID 1530383:  Resource leaks  (RESOURCE_LEAK)
/tests/zfs-tests/cmd/mmapwrite.c: 85 in normal_writer()


________________________________________________________________________________________________________
*** CID 1530383:  Resource leaks  (RESOURCE_LEAK)
/tests/zfs-tests/cmd/mmapwrite.c: 85 in normal_writer()
79              if ((bytes_written = lseek(fd, page_size, SEEK_CUR)) == -1) {
80                      err(1, "lseek failed on %s: %s", file_path,
81                          strerror(errno));
82                      break;
83              }
84      }
>>>     CID 1530383:  Resource leaks  (RESOURCE_LEAK)
>>>     Handle variable "fd" going out of scope leaks the handle.
85      return (NULL);
86     }
87     
88     static void *
89     map_writer(void *filename)
90     {

It is a minor issue, but we probably should fix it as we are trying to get to 0 outstanding coverity defect reports so that important issues are not hidden among a sea of minor issues. We just need close(fd); before return (NULL); to fix it.