RFR: .: (fs) Files.copy needs to be tuned

[Bernd Eckenfels]

Hello,

Normally using static bigger buffers like 16k or 64k reduce the syscall and pagefault overhead (and it’s a pretty sure multiple of all important block sizes without any math or without much loss). It also helps the IO scheduler to asume a streaming read for read ahead detecting if the read req quests are multiple of the blocksize. By limiting it to a single block that might actually be a disadvantage on some combinations.

Lcm, For 12k and 16k it turns out to be 48k, but for 8k->4k it would still read with 8k. Maybe add a step of the result is < 16 then trippel it?

Since windows disables page cache for larger files, on Linux we could also work with posix_fadvice(POSIX_FADV_SEQUENTIAL|WIlLNEED(|DONTREUSE)) or using readahead() to request multiple blocks (but we mentioned just using a larger read buffer usually does the trick portably).

The bug talks about NFS in particular, what will the unix attribute return for nfs servers, is it the buffer size? Can you share numbers? (And does the benchmark compare it about blocking io?)

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: nio-dev <nio-dev-retn at mail.openjdk.org> im Auftrag von Alan Bateman <alanb at openjdk.java.net>
Gesendet: Wednesday, June 15, 2022 2:27:13 PM
An: nio-dev at openjdk.java.net <nio-dev at openjdk.java.net>
Betreff: Re: RFR: 6980847: (fs) Files.copy needs to be tuned

On Wed, 15 Jun 2022 00:20:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.

src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 276:

> 274:                     long bss = Files.getFileStore(source).getBlockSize();
> 275:                     long bst = Files.getFileStore(target).getBlockSize();
> 276:                     if (bss > 0 && bst > 0) {

This should be UnixFileStoreAttributes.get(source).blockSize() to avoid calling from the provider to the API or needing to create a FileStore.

-------------

PR: https://git.openjdk.org/jdk/pull/9161
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20220615/b67563e4/attachment.htm>