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