After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 659480 - Use reflink for copy for local files
Use reflink for copy for local files
Status: RESOLVED DUPLICATE of bug 626497
Product: glib
Classification: Platform
Component: gio
2.29.x
Other Linux
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-09-19 14:50 UTC by Maciej (Matthew) Piechotka
Modified: 2012-08-17 05:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Maciej (Matthew) Piechotka 2011-09-19 14:50:44 UTC 
reflink is an operation similat to hardlink but sharing the data blocks instead of inode. In effect it creates an COW copy instead of copying the file byte-by-byte.

Currently the OCFS2 and BTRFS filesystem supports it but I believe that it is sufficient for most users when they issue copy operation in file manager.
Comment 1 Matthias Clasen 2011-09-19 19:44:09 UTC 
Any downsides to this ? Any pointers to documentation about this operation ?
Comment 2 Maciej (Matthew) Piechotka 2011-09-19 20:03:53 UTC 
(In reply to comment #1)
> Any downsides to this ?

The similar downsize as any deduplication technique - if user wants to have 2 copies in case 1 become corrupted (in this case - corrupted on hdd, not above vfs level).

> Any pointers to documentation about this operation ?

There is surprisingly small amount of information about this. For example GNU Coreutils cp can use reflink if specified as CLI parameter.

After inspection of source code (http://repo.or.cz/w/coreutils.git/blob/HEAD:/src/copy.c#l239) it seems it simply tries to perform (btrfs-specific?) ioctl on Linux and mark as not supported otherwise.
Comment 3 Matthias Clasen 2012-08-17 05:53:30 UTC 

*** This bug has been marked as a duplicate of bug 626497 ***