<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
<div dir="ltr">
<div style=""></div>
<div style="">
<div dir="ltr">Hello,</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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?</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Since windows disables page cache for larger files, on Linux we could also work with posix_fadvice(<b style="caret-color: rgb(24, 24, 24); font-family: monospace, courier; font-size: 16px; color: rgb(80, 32, 0);">POSIX_FADV_SEQUENTIAL|WIlLNEED(|DONTREUSE)</b><span style="caret-color: rgb(24, 24, 24); font-size: inherit;">)
or using readahead() to request multiple blocks (but we mentioned just using a larger read buffer usually does the trick portably).</span></div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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?)</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Gruss</div>
<div dir="ltr">Bernd</div>
<div dir="ltr"><span style="font-size: inherit;">--</span></div>
<div id="ms-outlook-mobile-signature">
<div style="direction:ltr">http://bernd.eckenfels.net</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> nio-dev <nio-dev-retn@mail.openjdk.org> im Auftrag von Alan Bateman <alanb@openjdk.java.net><br>
<b>Gesendet:</b> Wednesday, June 15, 2022 2:27:13 PM<br>
<b>An:</b> nio-dev@openjdk.java.net <nio-dev@openjdk.java.net><br>
<b>Betreff:</b> Re: RFR: 6980847: (fs) Files.copy needs to be tuned</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On Wed, 15 Jun 2022 00:20:58 GMT, Brian Burkhalter <bpb@openjdk.org> wrote:<br>
<br>
> 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.<br>
<br>
src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 276:<br>
<br>
> 274: long bss = Files.getFileStore(source).getBlockSize();<br>
> 275: long bst = Files.getFileStore(target).getBlockSize();<br>
> 276: if (bss > 0 && bst > 0) {<br>
<br>
This should be UnixFileStoreAttributes.get(source).blockSize() to avoid calling from the provider to the API or needing to create a FileStore.<br>
<br>
-------------<br>
<br>
PR: <a href="https://git.openjdk.org/jdk/pull/9161">https://git.openjdk.org/jdk/pull/9161</a><br>
</div>
</span></font></div>
</body>
</html>