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

[Stefan Brüns]

bruns added a comment.


  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

INLINE COMMENTS

> copyjob.cpp:742
> +        if (!isDir && info.linkDest.isEmpty() && m_mode == CopyJob::Copy && m_bDestSupportsCoW) {
> +            const QString srcDevice = KMountPoint::currentMountPoints().findByPath(info.uSource.toLocalFile())->mountedFrom();
> +            info.bCreateClone = (srcDevice == m_destDevice);

it is *much* cheaper to compare the st_dev fields from stat for the source file and the destination directory.

> kmountpoint.cpp:471
>                      || d->mountType == QLatin1String("smb-share");
> +    const bool isCoWSupported = d->mountType == QLatin1String("btrfs") || d->mountType == QLatin1String("xfs");
>  

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.

> kmountpoint.h:145
>       * "foo" and "FOO" as being the same file (true for msdos systems)
> +     * @li SupportsCoW: returns true if the filesystem supports Copy-on-Write
> +     * (true for btrfs, xfs, etc.)

The correct term here is "reflink", not CoW.

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/3919af3b/attachment.html>