D17737: [CopyJob] Create clones in btrf/xfs mount

Chinmoy Ranjan Pradhan noreply at phabricator.kde.org
Sun Dec 23 15:41:46 GMT 2018


chinmoyr added a comment.


  In D17737#381029 <https://phabricator.kde.org/D17737#381029>, @bruns wrote:
  
  > I think it would be much simpler if you just tried to do the the FICLONE iotctl in the job, without any prior checking:
  >
  > - no possibility for races
  > - less syscals
  > - less code
  
  
  I am not sure I followed you here. To me ioctl seems to naturally fit in FileProtocol::copy(). Can I ask you to elaborate a bit?

INLINE COMMENTS

> bruns wrote in copyjob.cpp:742
> it is *much* cheaper to compare the st_dev fields from stat for the source file and the destination directory.

I agree but in case of KIO::copy() the destination can be a non-existent file resulting in lstat to fail. However, I did considered using st_dev for source but couldn't find a way to map it to a block device. Maybe we can use st_dev by default and fallback to KMountPoint upon encountering this particular case?

> bruns wrote in kmountpoint.cpp:471
> This is not correct, xfs **may** support reflinks, but it is a feature only recently added, and has to be enabled at file system creation time.

Here by 'support' I meant support in its implementation. Meaning aside, unlike btrfs' "nodatacow" option which we can get using KMountPoint I couldn't find any API to get the "reflink" option set during file system creation time. How do you suggest I proceed from here?

> bruns wrote in kmountpoint.h:145
> The correct term here is "reflink", not CoW.

Some documents I read on btrfs and xfs described copy-on-write as a 'feature'. So I felt the enum should contain 'Supports' followed by the feature name.
But reflink or clone fits here better. I will make the change in next update.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D17737

To: chinmoyr, dfaure, davidedmundson
Cc: bruns, kde-frameworks-devel, michaelh, ngraham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20181223/61685d86/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list