DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 50664K9d4004062
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 825DF3858D21
MIME-Version: 1.0
References: <CALXu0Uee16dR-X812UpKNiE0CAVfBjQY_z1OBbyPdQgm_4zsZQ AT mail DOT gmail DOT com>
 <0ddeea07-0b3d-442d-be13-cf9b2379311d AT gmail DOT com>
 <CALWcw=EHwpQJqHjAa06JCsHwn6FzrSQgo2zihOYSM_=VSD0mvQ AT mail DOT gmail DOT com>
In-Reply-To: <CALWcw=EHwpQJqHjAa06JCsHwn6FzrSQgo2zihOYSM_=VSD0mvQ@mail.gmail.com>
Date: Mon, 6 Jan 2025 07:03:00 +0100
Message-ID: <CALXu0UcLg8mszVvbyJmv9+DQ-uGkwowPb3Di1y38=wdSOG_p9w@mail.gmail.com>
Subject: Re: Cygwin copy_file_range() support with sparse
 file+FSCTL_DUPLICATE_EXTENTS_TO_FILE?
To: cygwin AT cygwin DOT com
From: Cedric Blancher via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Cedric Blancher <cedric DOT blancher AT gmail DOT com>
Content-Type: text/plain; charset="utf-8"
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

On Sun, 5 Jan 2025 at 14:53, Takeshi Nishimura via Cygwin
<cygwin AT cygwin DOT com> wrote:
>
> On Sun, Jan 5, 2025 at 1:06 PM Václav Haisman via Cygwin
> <cygwin AT cygwin DOT com> wrote:
> >
> > On 05. 01. 25 7:31, Cedric Blancher via Cygwin wrote:
> > > Good morning!
> > >
> > > Could Cygwin implement copy_file_range() support, including sparse
> > > file support so holes are preserved, and
> > > FSCTL_DUPLICATE_EXTENTS_TO_FILE support?
> >
> > In theory, this could be used to implement that function. In practice,
> > the block cloning is only supported by ReFS. See
> > <https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioctl-fsctl_duplicate_extents_to_file>
>
> All Windows Server (2019, 2022) installations we have. and those which
> I know about, use ReFS (except in cases where Alternate Streams are
> required).
> AFAIK SMB3 also support FSCTL_DUPLICATE_EXTENTS_TO_FILE, so this would
> be a HUGE win for Cygwin

I agree.

Cygwin has notoriously bad filename lookup performance (because each
open("foo.bar") also looks up "foo.bar.lnk", "foo.bar.exe",
"foo.bar.exe.lnk" and so on *SERIALLY*), and I hope that implementing
copy_file_range() via FSCTL_DUPLICATE_EXTENTS_TO_FILE will win back a
bit of performance for copying large files. Even more so for SMB,
where the filename lookup dominates the total file copying time. But
if IO happens on the server side, that might compensate for it.

Ced
-- 
Cedric Blancher <cedric DOT blancher AT gmail DOT com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple