std: Make file copy ops use zero-copy mechanisms #6516

LemonBoy · 2020-10-03T10:33:56Z

Use copy_file_range on Linux (if available), fcopyfile on Darwin,
sendfile on *BSDs (and on Linux kernels without copy_file_range).

Use copy_file_range on Linux (if available), fcopyfile on Darwin, sendfile on *BSDs (and on Linux kernels without copy_file_range).

This is an optimization as it avoids an extra syscall, but it's also a workaround for fstat being not available on Windows.

andrewrk

Nice improvement, needs a bit more work before merging. lmk if you want a handoff

andrewrk · 2020-10-04T01:40:25Z

lib/std/os.zig

+    if (std.Target.current.os.tag == .linux) {
+        // Try copy_file_range first as that works at the FS level and is the
+        // most efficient method (if available).
+        if (has_copy_file_range_syscall.get() != 0) {


This should use the target version range to determine which state we are in:

the target OS version range guarantees kernel will have copy_file_range. Skip the runtime check.

the target OS version range guarantees kernel will not have copy_file_range. Skip the runtime check.

the target OS version range spans a kernel version that has the syscall and a version that does not have the syscall. Do the runtime check.

Sure thing, it's enough to preload has_copy_file_range_syscall with 0 if the version check fails.

andrewrk · 2020-10-04T01:41:36Z

lib/std/os.zig

+
+/// Transfer all the data between two file descriptors in the most efficient way.
+/// No metadata is transferred over.
+pub fn copy_file(fd_in: fd_t, fd_out: fd_t, options: CopyFileOptions) CopyFileError!void {


What is the "posix layer" API function that this represents? It looks like the only one that has such a function is Darwin, in which case this should be called fcopyfile and not have an options parameter.

There's no POSIX equivalent, we can just move this into fs as a private helper and call it a day.

Sounds good 👍

btw if you haven't seen it: #5019

btw if you haven't seen it: #5019

IMO we don't need a posix layer, we only need a std.os that does things (eg. copyFile, writeData) rather than trying to paper over all the differences between different OSs. If one wants a specific posix-specific/Windows-specific function they're more than welcome to do so by explicitly writing it out, but a full-blown Posix compatibility layer is not something that belongs into a stdlib.

I agree that creating a full blown posix compatibility layer is not a goal in and of itself. But it's an implementation detail of providing a std that does things (e.g. std.fs). It's code that we would end up writing - in fact did end up writing - as an implementation detail of the higher level cross platform abstractions. "posix layer" is just a way to think about how it is organized.

andrewrk · 2020-10-04T01:48:33Z

lib/std/fs.zig

@@ -1823,7 +1823,7 @@ pub const Dir = struct {
        var atomic_file = try dest_dir.atomicFile(dest_path, .{ .mode = mode });
        defer atomic_file.deinit();

-        try atomic_file.file.writeFileAll(in_file, .{ .in_len = size });
+        try os.copy_file(in_file.handle, atomic_file.file.handle, .{});


The docs for in_len mention:

/// If the size of the source file is known, passing the size here will save one syscall. in_len: ?u64 = null,

Did we gain a redundant fstat syscall in the case that sendfile has to be used? I know we've had this discussion before, and your position is that it doesn't matter in practice, but this is fundamental to zig's premise as a language and standard library, that it does the "optimal" interaction with the OS. I think it's an important sign of implementation quality for an strace / ProcMon session to contain only necessary syscalls.

Did we gain a redundant fstat syscall in the case that sendfile has to be used?

No, both copy_file_range and sendfile are asked to read/write as many bytes as possible at each iteration. This saves a stat() (that's done anyway if when the file mode is copied over, I'd expect copyFile to copy the timestamps too but that's a different topic)

codehz · 2020-10-05T02:07:23Z

What's about CopyFileW for windows?

LemonBoy · 2020-10-05T10:02:36Z

What's about CopyFileW for windows?

It doesn't work on file handles so we're SOL. Is it any faster than a read/write loop?

Now it is a private API. Also handle short writes in copy_file_range fallback implementation.

lib/std/fs.zig

daurnimator · 2020-10-06T07:57:28Z

lib/std/os.zig

@@ -4978,6 +4979,11 @@ pub const CopyFileRangeError = error{
 /// Other systems fall back to calling `pread` / `pwrite`.
 ///
 /// Maximum offsets on Linux are `math.maxInt(i64)`.
+var has_copy_file_range_syscall = init: {
+    const kernel_has_syscall = comptime std.Target.current.os.isAtLeast(.linux, .{ .major = 4, .minor = 5 }) orelse true;
+    break :init std.atomic.Int(u1).init(@boolToInt(kernel_has_syscall));


Would a bool and accesing via @atomicLoad(bool, &has_copy_file_range_syscall) be simpler?

Yes, but I hate builtins and their @ so I'm using the posh abstraction layer.

I was originally going to write that we should create std.atomic.Bool, but I revised my comment after I wrote an implementation, and realised it was no more than a wrapper around the builtins; do you think that would be preferable?

That was my plan (I had std.atomic.Flag) in mind, but I discovered Int(bool) works just fine so... shrug

daurnimator · 2020-10-06T07:59:41Z

lib/std/os.zig

@@ -4978,25 +4979,26 @@ pub const CopyFileRangeError = error{
 /// Other systems fall back to calling `pread` / `pwrite`.
 ///
 /// Maximum offsets on Linux are `math.maxInt(i64)`.
+var has_copy_file_range_syscall = init: {


Better name could be may_have_copy_file_range_syscall?

It has false positives: it can be set to true even if the kernel doesn't have the syscall.

The initial guess may be wrong, but once we execute copy_file_range the result reflects the kernel characteristics.

lib/std/os.zig

daurnimator · 2020-10-07T03:02:09Z

Closes #2563

tadeokondrak · 2020-10-07T03:11:49Z

lib/std/c/darwin.zig

+pub const copyfile_state_t = *@Type(.Opaque);
+pub extern "c" fn copyfile_state_alloc() copyfile_state_t;
+pub extern "c" fn copyfile_state_free(state: copyfile_state_t) c_int;


It seems this can be null: https://opensource.apple.com/source/copyfile/copyfile-166/copyfile.c.auto.html

Yeah, but the alloc/free are now unused and can get the boot before/after merging.

andrewrk

Thanks for the updated patch. It all looks quite clean. I only have a few nitpicks left.

lib/std/fs.zig

lib/std/os.zig

LemonBoy · 2020-10-07T09:17:04Z

The more I work on os.zig the more my hate towards it grows, I don't care about this PR anymore so I'm handing it off.

andrewrk · 2020-10-07T09:22:25Z

OK no problem. Thanks!

Everybody respects your opinion around here, I'm sure if you open a proposal and explain how you want things to be different in a clear way it will be taken seriously.

std: Make file copy ops use zero-copy mechanisms

0f248e0

Use copy_file_range on Linux (if available), fcopyfile on Darwin, sendfile on *BSDs (and on Linux kernels without copy_file_range).

alexnask added enhancement Solving this issue will likely involve adding new logic or components to the codebase. standard library This issue involves writing Zig code for the standard library. labels Oct 3, 2020

Alternative strategy to avoid calling stat()

8b4f5f0

This is an optimization as it avoids an extra syscall, but it's also a workaround for fstat being not available on Windows.

andrewrk requested changes Oct 4, 2020

View reviewed changes

Move copy_file to fs namespace

a419a1a

Now it is a private API. Also handle short writes in copy_file_range fallback implementation.

daurnimator suggested changes Oct 6, 2020

View reviewed changes

Address review comments & fix compilation errors

1f7ec0d

tadeokondrak reviewed Oct 7, 2020

View reviewed changes

andrewrk requested changes Oct 7, 2020

View reviewed changes

lib/std/fs.zig Outdated Show resolved Hide resolved

lib/std/os.zig Outdated Show resolved Hide resolved

lib/std/os.zig Outdated Show resolved Hide resolved

lib/std/os.zig Outdated Show resolved Hide resolved

New review round

03762da

LemonBoy mentioned this pull request Oct 7, 2020

Eliminate the POSIX API layer #6600

Open

andrewrk merged commit 76a1954 into ziglang:master Oct 9, 2020

andrewrk mentioned this pull request Oct 17, 2020

copy_file_range syscall support on Linux #2563

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

std: Make file copy ops use zero-copy mechanisms #6516

std: Make file copy ops use zero-copy mechanisms #6516

LemonBoy commented Oct 3, 2020

andrewrk left a comment

andrewrk Oct 4, 2020

LemonBoy Oct 4, 2020

andrewrk Oct 4, 2020

LemonBoy Oct 4, 2020

andrewrk Oct 5, 2020

andrewrk Oct 5, 2020

LemonBoy Oct 5, 2020

andrewrk Oct 6, 2020

andrewrk Oct 4, 2020

LemonBoy Oct 4, 2020

codehz commented Oct 5, 2020

LemonBoy commented Oct 5, 2020

daurnimator Oct 6, 2020

LemonBoy Oct 6, 2020

daurnimator Oct 6, 2020

LemonBoy Oct 6, 2020

daurnimator Oct 6, 2020

LemonBoy Oct 6, 2020

daurnimator Oct 6, 2020

LemonBoy Oct 6, 2020

daurnimator commented Oct 7, 2020

tadeokondrak Oct 7, 2020

LemonBoy Oct 7, 2020

andrewrk left a comment

LemonBoy commented Oct 7, 2020

andrewrk commented Oct 7, 2020

std: Make file copy ops use zero-copy mechanisms #6516

std: Make file copy ops use zero-copy mechanisms #6516

Conversation

LemonBoy commented Oct 3, 2020

andrewrk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codehz commented Oct 5, 2020

LemonBoy commented Oct 5, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daurnimator commented Oct 7, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andrewrk left a comment

Choose a reason for hiding this comment

LemonBoy commented Oct 7, 2020

andrewrk commented Oct 7, 2020