illumos gate

In testing #12940, I noticed that running the zfs tests on raw iron, the zpool_trim_verify_trimmed test would fail on raw iron while passing in a VM. Looking closer, the test does the following:

1. creates a file backed zpool
2. notes the space consumed by the file (using du -- the file will be sparse, so it wants the actual blocks used)
3. runs zpool initialize to write data to the file
4. notes the size of the backing file after writing data (again using du)
5. verifies the backing file's size has grown (via du)
6. runs zfs trim
7. compares the size of the file after trimming to the original file (via du).

On illumos, a file backed zpool will be TRIMmed using the F_FREESP fcntl command. Since practically every illumos distro's /var/tmp itself resides on ZFS, this means that the test pool's TRIM requests will generate F_FREESP requests which in turn call zfs_space on the backing file in /var/tmp. If the TXG where the F_FREESP request occurs has not yet synced when the final du is run, the change in size will not be visible, and can cause the test to fail.

It seems likely that the difference in scheduling latency between running the zfs tests on raw iron vs in a VM probably explain why the test fails on raw iron -- there's likely less scheduling latency, so du runs before the TXG has synced, while in a VM, it's likely that the TXG often gets synced before hand.

Adding a call to sync(1M) between the completion of the zpool trim command and checking the final size of the backing file with du allows the test to consistently succeed on the physical host.