In reply to Margaret Crevar.

Took a peak at XFS out of interest. The XFS throughput was quite a bit higher on the system I'm experimenting on. For those who are interested this system I'm using for my tinkering is a DELL Latitude 7480 with an Intel i7-7600U @ 2.8 Ghz running Ubuntu 18.10 with the generic 4.18.0-15-generic kernel.

XFS 3.3 GB/s
ext4 2.4 GB/s

I'd take these measurements with a grain of salt though I did zero tuning for either configuration. The behavior I described with regards to the filemap_flush() blocking the close occurred in XFS also. In the case where the IO got blocked behind writing pages from the page cache the throughput was basically the same for XFS and ext4. There wasn't much in it.

The line in XFS where filemap_flush() is triggered is here https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/cosmic/tree/fs/xfs/xfs_inode.c#n1669 This causes the close syscall to block and it takes ages. There is commentary in the source that explains why this occurs.

This code path in the kernel where the close syscall gets blocked by close wasn't something I could triggered from any SAS application. It only occurs in the case where a process calls open with the O_TRUNC flag. SAS opens a new file with the .lck extension writes then replaces the file with an unlink and rename so this slow code path I found where pages are flushed synchronously doesn't get called.