Bug 326880 - Dolphin is unable to utilize CoW feature of btrfs
Summary: Dolphin is unable to utilize CoW feature of btrfs
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
: 329860 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-10-30 13:41 UTC by Zetok
Modified: 2020-06-20 14:46 UTC (History)
15 users (show)

See Also:
Latest Commit: https://invent.kde.org/frameworks/kio/commit/c2faaae697f11ee600989b67b4406981838ae628
Version Fixed In: 5.72
Sentry Crash Report:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Zetok 2013-10-30 13:41:51 UTC 
When I tried to copy directory along with it content to some other directory (form /foo/bar/ to /foo/baz/ ) Dolphin (or whatever underlying that is supposed to take care of copying files) was unable to _instantly_ 'copy' those files, like it should be done. Files are pretty big (several GB together). I simply aborted copying, since I didn't need to physically duplicate data. I know that this behaviour isn't something that should occur, since another file manager (Thunar) was able to _instantly_ 'copy' files using CoW feature of btrfs.

Checked few times with different directories containing different files. Every time Dolphin failed to use CoW.





Reproducible: Always

Steps to Reproduce:
1. Have/Get a directory containing in it  big files and in other directories containing files. Supposed location is /foo/bar/directory .
2. Open /foo/bar with Dolphin, copy 'directory' and using Dolphin paste it in /foo/baz .
3. Dolphin should start copying files (they have to be big enough to notice that this process isn't instant), instead of using CoW feature of btrfs.
Actual Results:  
Dolphin starts copying files (they have to be big enough to notice that this process isn't instant, data is being duplicated).

Expected Results:  
Dolphin should use CoW feature of btrfs, thus data should not be duplicated, only metadata would change.

My setup: btrfs partition on encrypted external hard drive connected by USB, mounted using self-made 'script' (there are better ways to do it but…)

I'm not sure whether my setup could matter, so I briefly described it.
I haven't tested it on plain btrfs partition (without encryption), since I don't have one.
I assume that plain btrfs partition would be enough. If not…
Comment 1 Frank Reininghaus 2013-10-30 14:10:37 UTC 
Thanks for the bug report. This is not a Dolphin issue - the KIO library and the 'file' kioslave are responsible for the actual copying process.
Comment 2 Dawit Alemayehu 2013-12-21 13:38:53 UTC 
Supporting a specific file system's feature is a wish list item and not a bug.
Comment 3 Christoph Feck 2014-01-12 02:00:56 UTC 
*** Bug 329860 has been marked as a duplicate of this bug. ***
Comment 4 Soukyuu 2015-06-11 00:13:34 UTC 
> Supporting a specific file system's feature is a wish list item and not a bug.
Comment 5 Soukyuu 2015-06-11 00:33:28 UTC 
Yeah, that quote wasn't supposed to be there.

Has there been any progress on implementing this? I don't know if pcmanfm-qt has a special implementation for that, but using that instead of dolphin (kio) works as expected. Since both file managers are in Qt, I can imagine you could look at how they did it.

Whether a bug or a feature request, not having this implemented makes one of the nicer btrfs features completely useless.
Comment 6 Edward O'Callaghan 2015-11-30 15:24:53 UTC 
kio could additionally support BTRFS's snapshot facilities too. aka. Apple^tm Timemachine^{H. G. Wells} (sorry Jobs..)
Comment 7 gabe 2017-12-05 05:32:55 UTC 
I'd like to also voice support for this. It seems like a relatively minor thing to do that would have a very large impact on performance for my systems.
Comment 8 gabe 2017-12-05 05:33:35 UTC 
*** This bug has been confirmed by popular vote. ***
Comment 9 Nate Graham 2018-05-08 18:35:46 UTC 
Is anyone who's subscribed to this bug familiar with the kind of changes that would necessary to implement this feature?
Comment 10 Stefan Brüns 2018-05-08 18:46:47 UTC 
I think one should read the implementation of the "cp" command, which supports this using the "--reflink" option.
Comment 11 Méven Car 2020-06-16 19:11:46 UTC 
From https://github.com/coreutils/coreutils/blob/439741053256618eb651e6d43919df29625b8714/src/copy.c#L334 :

/* Perform the O(1) btrfs clone operation, if possible.
   Upon success, return 0.  Otherwise, return -1 and set errno.  */
static inline int
clone_file (int dest_fd, int src_fd)
{
#ifdef FICLONE
  return ioctl (dest_fd, FICLONE, src_fd);
#else
  (void) dest_fd;
  (void) src_fd;
  errno = ENOTSUP;
  return -1;
#endif
}

Relevant ref: https://man7.org/linux/man-pages/man2/ioctl_ficlonerange.2.html
Comment 12 Bug Janitor Service 2020-06-16 19:31:04 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/53
Comment 13 Méven Car 2020-06-20 14:46:21 UTC 
Git commit c2faaae697f11ee600989b67b4406981838ae628 by Méven Car.
Committed on 20/06/2020 at 07:18.
Pushed by dfaure into branch 'master'.

File ioslave: Add support for reflink copying
FIXED-IN: 5.72

M  +86   -70   src/ioslaves/file/file_unix.cpp

https://invent.kde.org/frameworks/kio/commit/c2faaae697f11ee600989b67b4406981838ae628