Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use fs.copyFile with UV_FS_COPYFILE_FICLONE flag when ready #5456

Closed
2 tasks done
langpavel opened this issue Mar 5, 2018 · 4 comments
Closed
2 tasks done

Use fs.copyFile with UV_FS_COPYFILE_FICLONE flag when ready #5456

langpavel opened this issue Mar 5, 2018 · 4 comments

Comments

@langpavel
Copy link

langpavel commented Mar 5, 2018

Do you want to request a feature or report a bug?

Feature

Prerequisites

Summary

There is new awesome upcoming feature which can dramatically improve copying files on Copy on Write file systems: UV_FS_COPYFILE_FICLONE
File copied (cloned) this way will not occupy additional disk space until first modification, but it also have all the properties that standalone file has.

Cloning from Btrfs at Wikipedia.org (+)

Btrfs provides a clone operation that atomically creates a copy-on-write snapshot of a file. Such cloned files are sometimes referred to as reflinks, in light of the associated Linux kernel system calls.

By cloning, the file system does not create a new link pointing to an existing inode; instead, it creates a new inode that initially shares the same disk blocks with the original file. As a result, cloning works only within the boundaries of the same Btrfs file system, but since version 3.6 of the Linux kernel it may cross the boundaries of subvolumes under certain circumstances. The actual data blocks are not duplicated; at the same time, due to the copy-on-write (CoW) nature of Btrfs, modifications to any of the cloned files are not visible in the original file and vice versa.

Cloning should not be confused with hard links, which are directory entries that associate multiple file names with actual files on a file system. While hard links can be taken as different names for the same file, cloning in Btrfs provides independent files that share their disk blocks.

Support for this Btrfs feature was added in version 7.5 of the GNU coreutils, via the --reflink option to the cp command.


Relevant paragraph from libuv docs (+)

.. c:function:: int uv_fs_copyfile(uv_loop_t* loop, uv_fs_t* req, const char* path, const char* new_path, int flags, uv_fs_cb cb)
Copies a file from path to new_path. Supported flags are described below.
—————————————————————————————
- UV_FS_COPYFILE_FICLONE: If present, uv_fs_copyfile() will attempt to
create a copy-on-write reflink. If the underlying platform does not
support copy-on-write, then a fallback copy mechanism is used.
—————————————————————————————
.. versionchanged:: 1.20.0 UV_FS_COPYFILE_FICLONE is supported.

@BYK
Copy link
Member

BYK commented Mar 6, 2018

@langpavel this sounds like a fairly straightforward patch. Are you interested in submitting that?

@raphamorim
Copy link

Hi @BYK, can I work on it?

@BYK
Copy link
Member

BYK commented Mar 9, 2018

@raphamorim someone else reached out to me via Discord expressing intent to work on this. If that person can respond here maybe, you can work together?

@langpavel
Copy link
Author

langpavel commented Sep 6, 2018

Resolved by in #6302 by @as-com and @arcanis Thank you! — commit 3c34587
I didn't expect that solution will be so simple, really nice :-)
I hope there aren't cases which can save duplicated content on disk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants