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
