Bug 326880

Summary:	Dolphin is unable to utilize CoW feature of btrfs
Product:	[Frameworks and Libraries] frameworks-kio	Reporter:	Zetok <zexavexxe>
Component:	general	Assignee:	David Faure <faure>
Status:	RESOLVED FIXED
Severity:	wishlist	CC:	adawit, chrno-sphered, eocallaghan, frank78ac, gabe, johannespfrang+kde, kdelibs-bugs, mabo, mariusz.libera, meven29, mp107+bugs.kde.org, nate, nefelim4ag, niklas, stefan.bruens
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:	https://invent.kde.org/frameworks/kio/commit/c2faaae697f11ee600989b67b4406981838ae628	Version Fixed In:	5.72
Sentry Crash Report:

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