coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: [PATCH v1 0/8] VFS: In-kernel copy system call


From: Pádraig Brady
Subject: Fwd: [PATCH v1 0/8] VFS: In-kernel copy system call
Date: Tue, 08 Sep 2015 16:53:30 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

FYI


-------- Forwarded Message --------
Subject: Re: [PATCH v1 0/8] VFS: In-kernel copy system call
Date: Tue, 08 Sep 2015 16:21:18 +0100
From: Pádraig Brady <address@hidden>
To: Anna Schumaker <address@hidden>, address@hidden, address@hidden, 
address@hidden, address@hidden, address@hidden, address@hidden, address@hidden, 
address@hidden, address@hidden, address@hidden, address@hidden

On 04/09/15 21:16, Anna Schumaker wrote:
> Copy system calls came up during Plumbers a couple of weeks ago, because
> several filesystems (including NFS and XFS) are currently working on copy
> acceleration implementations.  We haven't heard from Zach Brown in a while,
> so I volunteered to push his patches upstream so individual filesystems
> don't need to keep writing their own ioctls.

Just mentioning that this is just pertaining to the data, not the metadata.
Providing metadata copying facilities would be _very_ useful, as
most file system specific details relate to the metadata, and having
VFS operations for that would avoid the plethora of details in each userspace 
tool,
and theoretically support translations between disparate metadata.

> The first three patches are a simple reposting of Zach's patches from several
> months ago, with one minor error code fix.  The remaining patches add in a
> fallback mechanism when filesystems don't provide a copy function.  This is
> especially useful when doing a server-side copy on NFS (using the new COPY
> operation in NFS v4.2).  This fallback can be disabled by passing the flag
> COPY_REFLINK to the system call.

I see copy_file_range() is a reflink() on BTRFS?
That's a bit surprising, as it avoids the copy completely.
cp(1) for example considered doing a BTRFS clone by default,
but didn't due to expectations that users actually wanted
the data duplicated on disk for resilience reasons,
and for performance reasons so that write latencies were
restricted to the copy operation, rather than being
introduced at usage time as the dest file is CoW'd.

If reflink() is a possibility for copy_file_range()
then could it be done optionally with a flag?

thanks,
Pádraig
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to address@hidden
More majordomo info at  http://vger.kernel.org/majordomo-info.html






reply via email to

[Prev in Thread] Current Thread [Next in Thread]