From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 30 02:03:36 2022 Received: (at submit) by debbugs.gnu.org; 30 Dec 2022 07:03:36 +0000 Received: from localhost ([127.0.0.1]:33431 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pB9QV-0006B5-Kq for submit@debbugs.gnu.org; Fri, 30 Dec 2022 02:03:36 -0500 Received: from lists.gnu.org ([209.51.188.17]:57944) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pAvOp-0001TL-BX for submit@debbugs.gnu.org; Thu, 29 Dec 2022 11:04:56 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pAvOo-00049j-Bg for bug-coreutils@gnu.org; Thu, 29 Dec 2022 11:04:54 -0500 Received: from mail-qk1-x735.google.com ([2607:f8b0:4864:20::735]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pAvOm-00063H-Na for bug-coreutils@gnu.org; Thu, 29 Dec 2022 11:04:54 -0500 Received: by mail-qk1-x735.google.com with SMTP id k3so9136398qki.13 for ; Thu, 29 Dec 2022 08:04:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=s0HwMKxk5007xc5rZRm31HgnwwdEZq8qw6TD2ZCP6zI=; b=NPdxvcU4WCmpYUOx2oJqX+jw3nzyyw47XKJBZ3QR1K1ftesNwZZ5H5QRN6eCbQjfhR CcgK5DY9r1uVQI5KFK4S/dX1Vi7Z3JdTn1jJDQB0rSGp1l8VWFva4W7cOeNigqTPNsY7 cz4B3sBcD0/1Zkh2w2oVNw59nhYD3NYJeN/Vm4v5sA2o7GlKAR7IYy2s6ux+V6ymwKYU fidxSFEX6D4lsRoaBlXBFH7TVUMrpi9+y0sAgzvf2JszlQDd9LSYrjEL9jOUjTxSFp/X 9aH2uYzjEs3wMPMOWTtuOI+aBHwn0iKeiqGO8HDMgA+EyIslGX6t/uqxA7B87Jdb+8J/ 53dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=s0HwMKxk5007xc5rZRm31HgnwwdEZq8qw6TD2ZCP6zI=; b=4mBSgSOZJmD2eBargheZ1nbrBZtgO4LAHE1AtQosMX4/KHpJ/dLr4iVNwQKp5labFD t1wFzuekjc0XqWfd1gi/E/Qk/97Voyw4exKAIrIo8ko3Yf8+/yuv0plVJqXBpLdH+kbr nTshBahdBXtSE4eOYORuNh7dRA4e6hvJtH89sHsv+JmW7YRZKqvteEXOgyG9xuPLt8zm 3FBXmbiGlH4srMya9tnOgVDVHmPThMqR6Iohzi12nas5lMcxSbuXP6/bJro1x1jljY7P ZrJzVhZ7iZKLeno7HKbqv6tbqlch/oZgORQ3kMy7D763FiPihHHbC/MAXBGW4SKsBscH H9Jw== X-Gm-Message-State: AFqh2kp4DFfbeefh9aWS1Y9IjqjtTELFMfEDXMrPiU/nCThQK2avtnYu VKGxX6pHfb3LyNl7cm2Mvx0PLLLGx4OnZXeKrtSBgL5xbVQ= X-Google-Smtp-Source: AMrXdXu/NBXHoSNUaip2/b74HlmtxMHkG296YTFs2Tj6M7uFPnpujaAdjYaYSwvb1agFuRy8uJYEM0D0W+flGpOJEF0= X-Received: by 2002:a05:620a:6006:b0:6eb:12c2:15ad with SMTP id dw6-20020a05620a600600b006eb12c215admr1416419qkb.654.1672329889186; Thu, 29 Dec 2022 08:04:49 -0800 (PST) MIME-Version: 1.0 From: Braiam Date: Thu, 29 Dec 2022 12:04:38 -0400 Message-ID: Subject: Be more liberal using copy_file_range() with NFS mounted filesystems To: bug-coreutils@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::735; envelope-from=braiamp@gmail.com; helo=mail-qk1-x735.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 30 Dec 2022 02:03:35 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) When using a nfs export, cp seems to not try hard enough using copy_file_range(). This was the conclusion we arrived in this forum thread[1] at Truenas forums. It was found a way to force cp to use it, but it should not be necessary, since there are supposed to be fallbacks. I'm unsure if we found something that triggered the undesired behavior. [1]: https://www.truenas.com/community/threads/nfs-does-not-support-server-side-copy-with-zfs.103309/post-712071 -- Braiam From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 30 10:33:22 2022 Received: (at 60416) by debbugs.gnu.org; 30 Dec 2022 15:33:22 +0000 Received: from localhost ([127.0.0.1]:35934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBHNq-0008Fy-AT for submit@debbugs.gnu.org; Fri, 30 Dec 2022 10:33:22 -0500 Received: from mail-wr1-f43.google.com ([209.85.221.43]:36390) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBHNo-0008Fi-B9 for 60416@debbugs.gnu.org; Fri, 30 Dec 2022 10:33:20 -0500 Received: by mail-wr1-f43.google.com with SMTP id bs20so18057827wrb.3 for <60416@debbugs.gnu.org>; Fri, 30 Dec 2022 07:33:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=hIhcDUxdnyIarhlLlSPyOhgyVbUB3JNdJLLvnSkD1EM=; b=olBlLvCa0XFton5T+OpnOeif7lbDXnWVhi4GyIwR+Oo6UU1KifhgNjuXuDG13SxLP7 5CoRHrP9g5rHHt90fvH8TR1drfDWmMRlvtw+yabZoBwfTzaxHzSD/0+7iHC8NvVacyG3 IrRtpzuHTBy/WkEjmEUo19kLVSvgcE1LcW+XTiNMERIbFDhfKSjMGSkWsIy8e6sB82OV 5kvbKwnwsyRIZhIKUTsw9gSudgWOVLBHv4AUY9dHoI6ps1h44OaM+UAqHI2dlXCi6Ra3 E+eu8AnyN/Vmrf1RGFTMNlJQPQPZ26YPHgobzHkwN8nn4D6uNguRBQJngj2OJAvR08E0 bI5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hIhcDUxdnyIarhlLlSPyOhgyVbUB3JNdJLLvnSkD1EM=; b=472UMGJzxFEr5dkfQ/UhEg2S3DKknRtrY5vFgcIFjpz9qUHoT17WktK6Jsmy6S+x4O Fpo2Zklo8SKLYwWb0BxBNW/Jc5LmSfrQGfIz6c67YL3UmBp4MQSC650wRxRrBBsOTxJU jIbO8kDw+LQ0L/UBeBZsbcbjd7tRgwVpO3SG1iomwffwk0MoxcTHgQB3qWrjxElUQLcQ JWhd1ypBpedvVr8YO2JsNRLMsUUtnXvFnfgmVUz/uUH/DL3E9qZDb/tRV8us4j0n8BNt 4ga1OgPA5Hxd13+fhuU0aH9dS7MExI11P3CM3GwVRUtDDRxyfG6o/fBGCU/MIT7CMSzC H5cw== X-Gm-Message-State: AFqh2kpE7Ag/OUTo/8orDvfqSGZwVHCVaI9HlYyscMYem9MwXycje7SW CVNYxjMVVlPplcoJHeCATxc= X-Google-Smtp-Source: AMrXdXuCVIAtogZJ8Wl10NTSlhRj1h5W/tH+JOMNylfgRNyFtoGe9dvI0J3SfdY/SrIRuSVQEYhs8w== X-Received: by 2002:adf:dd92:0:b0:242:39bc:4ac with SMTP id x18-20020adfdd92000000b0024239bc04acmr19506056wrl.51.1672414394244; Fri, 30 Dec 2022 07:33:14 -0800 (PST) Received: from [192.168.1.9] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id s17-20020adfea91000000b0027dcc2d6fc3sm13518058wrm.113.2022.12.30.07.33.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Dec 2022 07:33:13 -0800 (PST) Message-ID: <980e49f1-e4e7-cace-e2d8-847d90484770@draigBrady.com> Date: Fri, 30 Dec 2022 15:33:12 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.0 Subject: Re: bug#60416: Be more liberal using copy_file_range() with NFS mounted filesystems Content-Language: en-US To: Braiam , 60416@debbugs.gnu.org References: From: =?UTF-8?Q?P=c3=a1draig_Brady?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.9 (/) X-Debbugs-Envelope-To: 60416 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.9 (-) On 29/12/2022 16:04, Braiam wrote: > When using a nfs export, cp seems to not try hard enough using > copy_file_range(). This was > the conclusion we arrived in this forum thread[1] at Truenas forums. > It was found a way to force > cp to use it, but it should not be necessary, since there are supposed > to be fallbacks. > > I'm unsure if we found something that triggered the undesired behavior. > > [1]: https://www.truenas.com/community/threads/nfs-does-not-support-server-side-copy-with-zfs.103309/post-712071 > Currently we don't use copy_file_range() with sparse files, as per the Linux man page "copy_file_range() may expand any holes existing in the requested range". I confirmed that copy_file_range() definitely expands holes on ext4 on Linux 5.7 at least. Also the FreeBSD man page says "this system call attempts to maintain holes in the output file for the byte range being copied. However, this does not always work well." Now maybe we should give precedence to server side copy for remote file systems, though that would be optimizing runtime and network usage while potentially pessimizing storage usage if holes were expanded in the destination. Now fundamentally copy_file_range() isn't restricted from maintaining holes from source to destination, which suggests we could give precedence to copy_file_range() on remote file systems. Also perhaps we can improve the heuristic somehow, even again just for remote file systems. Maybe determine a file is sparse on remote systems only if it seems that more than half of the file is sparse. For completeness, one might be wondering why we're using copy_file_range() at all with --sparse=never, as that syscall doesn't guarantee sparseness. However in this case we only use copy_file_range() with the portion of the file considered non sparse (and manually write the zeros)¹. So in summary pseudo code could be: sparse_file = blocks < size/blocksize; very_sparse_file = blocks < (size/2)/blocksize; if ( (!possible_hole_in_range || sparse_mode=auto) && reflinks_allowed && ( (remote_file && !very_sparse_file) || (!remote_file && !sparse_file) ) ) copy_file_range(...); Note `stat ; df -T ` would give us some concrete heuristics for your case at least. Note it would be useful to get such stats from files that were completely copied by copy_file_range() on your systems (i.e. not by cp), to see if holes were expanded for your case. cheers, Pádraig ¹ Actually I now notice that where SEEK_HOLE is _not_ available and copy_file_range() is, then `cp --sparse=never` would not be honored, as copy_file_range() would expand the holes (confirmed on ext4 at least). Now I don't know of any practical systems having copy_file_range() and not having SEEK_HOLE, but I might add the constraint to the code, at least for clarification reasons. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 30 14:52:13 2022 Received: (at 60416) by debbugs.gnu.org; 30 Dec 2022 19:52:13 +0000 Received: from localhost ([127.0.0.1]:36132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBLQL-00011H-5u for submit@debbugs.gnu.org; Fri, 30 Dec 2022 14:52:13 -0500 Received: from mail-wm1-f54.google.com ([209.85.128.54]:42636) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBLQI-000112-KR for 60416@debbugs.gnu.org; Fri, 30 Dec 2022 14:52:11 -0500 Received: by mail-wm1-f54.google.com with SMTP id i17-20020a05600c355100b003d99434b1cfso5558344wmq.1 for <60416@debbugs.gnu.org>; Fri, 30 Dec 2022 11:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:references:to:from:content-language:subject:user-agent :mime-version:date:message-id:sender:from:to:cc:subject:date :message-id:reply-to; bh=QCquFtSrXxSuOLNnaPLpXc3s0oubWMBCB0ULgVylXbk=; b=AVABvOZ9W0mah2wu6GAPrrkDA6H2brHoGPLg6n0eplLisJWu7ygC8JAdUE85nqTYg/ 2qFlduIIBSV2mU30IDHOybqfn08VOLCHs/BDLehSjGFcjhw/+a75AAnB7svKJ0W4IAVp nQZqinBZqFJtcUDi5jukuHt+SzKl6ntgRTFnLB/S9bTx6ch7J2hdduUx270QB1ao8nzL UWyaxTAFw64Yli5GsD5F8ypLf9YnVlDlfv87mlozWatrQivnpT0AwJn5mo7KeviLQs6E N3ShPSjq67TpeKhjg7BR+ASf1fWOJCQogc3Fag4RlqVNDI4aHSvmuULEU6HutG6NreEX y0RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:references:to:from:content-language:subject:user-agent :mime-version:date:message-id:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QCquFtSrXxSuOLNnaPLpXc3s0oubWMBCB0ULgVylXbk=; b=PZy0IXiP0H/joPxJJbPwdnJDLM1TX/uKM8CtzsBS+MtMJYtzQ1sUiqSHbdew0yG0tM Fjbsj6yvtPF/QpBPPTba87vpMeE2GL0RTmDVgjkJvdidf7rIY93tWgK3sYrxAwcJPt2G 9PTH8l1CdQgIgctuFqQZZkINdGINVAEs6UFFfyxG+yWa/2FjHYqqdaPfkRQ4xV99BGdH YmusYicfwRxS2yJnH7iJ9dCIa1svVHH7gu+YBVy/bjMoB6v06LyyyD4j/8x06cHWtq98 zngH/trsakkmvObAwunuMEnXXc4CF56R33dThj1ny/gvlZ1hsTcAjXvT4Uhb0H9VzAYr fDZg== X-Gm-Message-State: AFqh2koGSM9HwHgcn6jJpi6PlSPhCRm4eD0sOgFcJUhWSvIFA8CcfHTE E9WndzwZK6c9kBvjYzlpONc= X-Google-Smtp-Source: AMrXdXtPXRRcuTU+Jg27dQEYEcZngWktzU1RDw31E43Q/cw1x8K3nY2hgSRM+gG1j3MMweX3vy37jw== X-Received: by 2002:a05:600c:540c:b0:3d9:922b:b148 with SMTP id he12-20020a05600c540c00b003d9922bb148mr8751706wmb.27.1672429924258; Fri, 30 Dec 2022 11:52:04 -0800 (PST) Received: from [192.168.1.9] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id f18-20020a05600c4e9200b003d35c845cbbsm38411055wmq.21.2022.12.30.11.52.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Dec 2022 11:52:03 -0800 (PST) Content-Type: multipart/mixed; boundary="------------9tAhjG9Tk3Fmooqp8xIKq6OE" Message-ID: <6ad3b71d-140c-005f-b4d8-799c99dab3bf@draigBrady.com> Date: Fri, 30 Dec 2022 19:52:02 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.0 Subject: [PATCH] copy: attempt copy offload with sparse files Content-Language: en-US From: =?UTF-8?Q?P=c3=a1draig_Brady?= To: Braiam , 60416@debbugs.gnu.org References: <980e49f1-e4e7-cace-e2d8-847d90484770@draigBrady.com> In-Reply-To: <980e49f1-e4e7-cace-e2d8-847d90484770@draigBrady.com> X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 60416 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) This is a multi-part message in MIME format. --------------9tAhjG9Tk3Fmooqp8xIKq6OE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 30/12/2022 15:33, Pádraig Brady wrote: > On 29/12/2022 16:04, Braiam wrote: >> When using a nfs export, cp seems to not try hard enough using >> copy_file_range(). This was >> the conclusion we arrived in this forum thread[1] at Truenas forums. >> It was found a way to force >> cp to use it, but it should not be necessary, since there are supposed >> to be fallbacks. >> >> I'm unsure if we found something that triggered the undesired behavior. >> >> [1]: https://www.truenas.com/community/threads/nfs-does-not-support-server-side-copy-with-zfs.103309/post-712071 >> > > Currently we don't use copy_file_range() with sparse files, > as per the Linux man page "copy_file_range() may expand any > holes existing in the requested range". > I confirmed that copy_file_range() definitely expands holes > on ext4 on Linux 5.7 at least. > Also the FreeBSD man page says "this system call attempts > to maintain holes in the output file for the byte range being copied. > However, this does not always work well." > > Now maybe we should give precedence to server side copy for remote file systems, > though that would be optimizing runtime and network usage > while potentially pessimizing storage usage > if holes were expanded in the destination. > > Now fundamentally copy_file_range() isn't restricted from > maintaining holes from source to destination, > which suggests we could give precedence to copy_file_range() > on remote file systems. > > Also perhaps we can improve the heuristic somehow, > even again just for remote file systems. > Maybe determine a file is sparse on remote systems > only if it seems that more than half of the file is sparse. > > For completeness, one might be wondering why we're using > copy_file_range() at all with --sparse=never, as that syscall > doesn't guarantee sparseness. However in this case we > only use copy_file_range() with the portion of the file > considered non sparse (and manually write the zeros)¹. > > So in summary pseudo code could be: > > sparse_file = blocks < size/blocksize; > very_sparse_file = blocks < (size/2)/blocksize; > > if ( (!possible_hole_in_range || sparse_mode=auto) > && reflinks_allowed > && ( > (remote_file && !very_sparse_file) > || (!remote_file && !sparse_file) > ) > ) > copy_file_range(...); > > > Note `stat ; df -T ` would > give us some concrete heuristics for your case at least. > Note it would be useful to get such stats from files > that were completely copied by copy_file_range() on your systems > (i.e. not by cp), to see if holes were expanded for your case. > > cheers, > Pádraig > > ¹ Actually I now notice that where SEEK_HOLE is _not_ available > and copy_file_range() is, then `cp --sparse=never` would not be honored, > as copy_file_range() would expand the holes (confirmed on ext4 at least). > Now I don't know of any practical systems having copy_file_range() > and not having SEEK_HOLE, but I might add the constraint to the code, > at least for clarification reasons. Looking a bit closer at things, the current code does something like: if file appears sparse use SEEK_DATA to iterate over data parts, try writing data with copy_file_range() if sparse_mode == never (as thinking was there is no need to look for additional holes) else use copy_file_range if sparse_never || sparse_auto Now the use of copy_file_range() with sparse=never may be problematic, as assumes copy_file_range() won't add additional holes. This is problematic in first case as SEEK_HOLE is best effort, and in the second (else) case as file sparseness is a heuristic. Also from above analysis the OP's case seems to be first sparse case, as in second (else) case, with --sparse=auto, copy_file_range() would have been used (as file appears non sparse (so plain scan used)). So while we theoretically should only be allowing copy_file_range() with --sparse=auto, we definitely should not be precluding it in the first case with that sparse mode. I.e. for the first case we should only disallow copy_file_range() with sparse=ALWAYS, because --sparse=auto is best effort, and we've enough signal from SEEK_DATA as to the likelihood of processing holes or not. The attached makes that change. It would be great if you could test that on your systems. To that end you might find the following tarball useful, which has the patch already applied: https://pixelbeat.org/cu/coreutils-9.1.109-bd17b.tar.xz which can be built like: tar -xf coreutils-9.1.109-bd17b.tar.xz cd coreutils-9.1.109-bd17b/ ./configure && make -j $(nproc) then tested with: src/cp ... cheers, Pádraig --------------9tAhjG9Tk3Fmooqp8xIKq6OE Content-Type: text/x-patch; charset=UTF-8; name="copy-sparse-offload.patch" Content-Disposition: attachment; filename="copy-sparse-offload.patch" Content-Transfer-Encoding: base64 RnJvbSBiZDE3YjhkOTBiODUwMDgxOTRjMTgzMGU2MzUzNTNiYzhjYTE5NmE4IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/UD1DMz1BMWRyYWlnPTIwQnJhZHk/ PSA8UEBkcmFpZ0JyYWR5LmNvbT4KRGF0ZTogRnJpLCAzMCBEZWMgMjAyMiAxOTozNDoyNyAr MDAwMApTdWJqZWN0OiBbUEFUQ0hdIGNvcHk6IGF0dGVtcHQgY29weSBvZmZsb2FkIHdpdGgg c3BhcnNlIGZpbGVzCgoqIHNyYy9jb3B5LmMgKGxzZWVrX2NvcHkpOiBBbHNvIHNldCBob2xl X3NpemUgdG8gMCwKaS5lLiBlbmFibGUgY29weV9maWxlX3JhbmdlKCksIHdpdGggLS1zcGFy c2U9YXV0byAodGhlIGRlZmF1bHQpLAp0byBlbmFibGUgY29weSBvZmZsb2FkIGluIHRoaXMg Y2FzZSwgYXMgd2UndmUgc3Ryb25nIHNpZ25hbApmcm9tIFNFRUtfREFUQSB0aGF0IHdlJ3Jl IG9wZXJhdGluZyBvbiBhY3R1YWwgZGF0YSBhbmQgbm90IGhvbGVzIGhlcmUuCkFkZHJlc3Nl cyBodHRwczovL2J1Z3MuZ251Lm9yZy82MDQxNgotLS0KIHNyYy9jb3B5LmMgfCA0ICsrLS0K IDEgZmlsZSBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCgpkaWZm IC0tZ2l0IGEvc3JjL2NvcHkuYyBiL3NyYy9jb3B5LmMKaW5kZXggZTQ2NTI3MWVmLi43NDA3 NTE3ZjEgMTAwNjQ0Ci0tLSBhL3NyYy9jb3B5LmMKKysrIGIvc3JjL2NvcHkuYwpAQCAtNTI2 LDEyICs1MjYsMTIgQEAgbHNlZWtfY29weSAoaW50IHNyY19mZCwgaW50IGRlc3RfZmQsIGNo YXIgKiphYnVmLCBzaXplX3QgYnVmX3NpemUsCiAgICAgICBsYXN0X2V4dF9sZW4gPSBleHRf bGVuOwogCiAgICAgICAvKiBDb3B5IHRoaXMgZXh0ZW50LCBsb29raW5nIGZvciBmdXJ0aGVy IG9wcG9ydHVuaXRpZXMgdG8gbm90Ci0gICAgICAgICBib3RoZXIgdG8gd3JpdGUgemVyb3Mg dW5sZXNzIC0tc3BhcnNlPW5ldmVyLCBzaW5jZSBTRUVLX0hPTEUKKyAgICAgICAgIGJvdGhl ciB0byB3cml0ZSB6ZXJvcyBpZiAtLXNwYXJzZT1hbHdheXMsIHNpbmNlIFNFRUtfSE9MRQog ICAgICAgICAgaXMgY29uc2VydmF0aXZlIGFuZCBtYXkgbWlzcyBzb21lIGhvbGVzLiAgKi8K ICAgICAgIG9mZl90IG5fcmVhZDsKICAgICAgIGJvb2wgcmVhZF9ob2xlOwogICAgICAgaWYg KCAhIHNwYXJzZV9jb3B5IChzcmNfZmQsIGRlc3RfZmQsIGFidWYsIGJ1Zl9zaXplLAotICAg ICAgICAgICAgICAgICAgICAgICAgICBzcGFyc2VfbW9kZSA9PSBTUEFSU0VfTkVWRVIgPyAw IDogaG9sZV9zaXplLAorICAgICAgICAgICAgICAgICAgICAgICAgICBzcGFyc2VfbW9kZSAh PSBTUEFSU0VfQUxXQVlTID8gMCA6IGhvbGVfc2l6ZSwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgdHJ1ZSwgYWxsb3dfcmVmbGluaywgc3JjX25hbWUsIGRzdF9uYW1lLAogICAgICAg ICAgICAgICAgICAgICAgICAgICBleHRfbGVuLCAmbl9yZWFkLCAmcmVhZF9ob2xlKSkKICAg ICAgICAgcmV0dXJuIGZhbHNlOwotLSAKMi4yNi4yCgo= --------------9tAhjG9Tk3Fmooqp8xIKq6OE-- From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 30 17:32:24 2022 Received: (at 60416) by debbugs.gnu.org; 30 Dec 2022 22:32:24 +0000 Received: from localhost ([127.0.0.1]:36226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBNvM-0005CQ-Es for submit@debbugs.gnu.org; Fri, 30 Dec 2022 17:32:24 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:60702) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBNvK-0005C9-AF for 60416@debbugs.gnu.org; Fri, 30 Dec 2022 17:32:23 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1D412160078; Fri, 30 Dec 2022 14:32:16 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id WdVMkBb1d5JS; Fri, 30 Dec 2022 14:32:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 62D23160079; Fri, 30 Dec 2022 14:32:15 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 62D23160079 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1672439535; bh=VqAMEm2JVjjdRTD1V5pPc3zwwHhjWCmQYtVqbLUkySg=; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type: Content-Transfer-Encoding; b=HwTFAnZbG//Xzpgtax8ID281G0+gSpyQrMFYZBP0Hs1x3W5WsauD+A5hKY+OAWDFQ k98Jo1Y6XtUQDzTFSkd/a1sdFy4VI/w05k8UGASsQzq8gm/kK0tJnqPoshZWAp84HM L7iiV072VXH4cqQzKZkZnSukZ8zC6mR5LzhTcDvY= X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VIlaSnS0OUpX; Fri, 30 Dec 2022 14:32:15 -0800 (PST) Received: from [192.168.86.236] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 33C6E160078; Fri, 30 Dec 2022 14:32:15 -0800 (PST) Message-ID: <09b7a83c-a078-1bcc-a55d-62f76939c3b2@cs.ucla.edu> Date: Fri, 30 Dec 2022 14:32:14 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#60416: [PATCH] copy: attempt copy offload with sparse files Content-Language: en-US To: =?UTF-8?Q?P=c3=a1draig_Brady?= , Braiam , 60416@debbugs.gnu.org References: <980e49f1-e4e7-cace-e2d8-847d90484770@draigBrady.com> <6ad3b71d-140c-005f-b4d8-799c99dab3bf@draigBrady.com> From: Paul Eggert In-Reply-To: <6ad3b71d-140c-005f-b4d8-799c99dab3bf@draigBrady.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: 60416 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.4 (----) Thanks, looks good, please install. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 30 19:23:40 2022 Received: (at 60416-done) by debbugs.gnu.org; 31 Dec 2022 00:23:40 +0000 Received: from localhost ([127.0.0.1]:36283 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBPf1-00087p-Rj for submit@debbugs.gnu.org; Fri, 30 Dec 2022 19:23:40 -0500 Received: from mail-wm1-f52.google.com ([209.85.128.52]:39424) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBPf0-00087b-4c for 60416-done@debbugs.gnu.org; Fri, 30 Dec 2022 19:23:38 -0500 Received: by mail-wm1-f52.google.com with SMTP id g25-20020a7bc4d9000000b003d97c8d4941so10782040wmk.4 for <60416-done@debbugs.gnu.org>; Fri, 30 Dec 2022 16:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=AnDLBYT1nBwPcnHFY5y5IzcbBPVDMuWqYEm4MBjKETQ=; b=LsmerLl3cryQ4g7dRMYY5kWNZW1QgKh5BHV+X2lDdxAsaj+afxzGg+SY28Tqiao24X MvpFZjbiwxv5AW5N/HJUDjwYjQlNrH9F9DSiOXpjYkdTpmaba03Ff2LKF27oa0y/5WSW CQqR97nbExgUzJw4VUMlGijf00qFvi9xF562HgUJASPgdKm3eYmS/7+k8fQkxTrpxR/Q afAwxGZ9L3KPtTchdUU5SguDvSroO/Qfkk3TQVN0+qHQMJgVLWKBhNS5Yq+s9I5fHMO2 aWuko3Mw6bN5QVtByc7fL+TzkIIIrz0r5zNMHFmvGJXBm5bew8T+QF/BCUa8GVc+AFaO 6Dew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AnDLBYT1nBwPcnHFY5y5IzcbBPVDMuWqYEm4MBjKETQ=; b=fgqpLSiX5jE8c7rrAlEQTARPRR6MZGuTmwzdAfoqoEsmk/WX+8z0nU+ysH9wLsMl63 PdbA07RbpB9ApdnlP28kLFxgW2WjUDpfAE8q/IUoRiPxJP+ENb2tGyBsOIlVjgI4qrI+ WhvXZxvM9woJMw7C6uLJM6xit6XcFXPr+o9K4aVoZ1Fj2djwhBShSd0Z9H9HKQNPBa8M oVXhcXVbhWpia3L1P54i8Qm1TX3JgfrRY+FoMhirr1Qkq/xbFWbM0ocXrVfqji6kcY+W auovWEajsYZpKzj/4gaVK4U/NrKBS9DaEx3S/X6ys+QRQapx6bHvVctYWb4n0NQYY7yY uGAA== X-Gm-Message-State: AFqh2kptCGKLs+slwBvVLohJGlNnyBMUze79DjrpT93on8XvQAb70hxO 4KPvkgHmhVAqxDyhkIEN2g0= X-Google-Smtp-Source: AMrXdXs49pjxW05BzLzXjBtzz65lVAvLiTuUf3BIrtiXN1/gcSOucY8XC5FA0oh3UDQ/7LCj0E5lPQ== X-Received: by 2002:a05:600c:4e48:b0:3cf:5d41:b748 with SMTP id e8-20020a05600c4e4800b003cf5d41b748mr27054902wmq.36.1672446212168; Fri, 30 Dec 2022 16:23:32 -0800 (PST) Received: from [192.168.1.9] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id l42-20020a05600c1d2a00b003cfbbd54178sm51371789wms.2.2022.12.30.16.23.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Dec 2022 16:23:31 -0800 (PST) Message-ID: <637162a7-d215-ac74-b422-a5539c09bff4@draigBrady.com> Date: Sat, 31 Dec 2022 00:23:30 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.0 Subject: Re: bug#60416: [PATCH] copy: attempt copy offload with sparse files Content-Language: en-US To: Paul Eggert , Braiam , 60416-done@debbugs.gnu.org References: <980e49f1-e4e7-cace-e2d8-847d90484770@draigBrady.com> <6ad3b71d-140c-005f-b4d8-799c99dab3bf@draigBrady.com> <09b7a83c-a078-1bcc-a55d-62f76939c3b2@cs.ucla.edu> From: =?UTF-8?Q?P=c3=a1draig_Brady?= In-Reply-To: <09b7a83c-a078-1bcc-a55d-62f76939c3b2@cs.ucla.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.9 (/) X-Debbugs-Envelope-To: 60416-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.9 (-) On 30/12/2022 22:32, Paul Eggert wrote: > Thanks, looks good, please install. Thanks for the review. OP also posted good results. Pushed with NEWS entry. Marking this as done. I may follow up with a related patch to ensure we _don't_ use copy_file_range with --sparse=never. cheers, Pádraig From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 30 20:36:35 2022 Received: (at 60416-done) by debbugs.gnu.org; 31 Dec 2022 01:36:36 +0000 Received: from localhost ([127.0.0.1]:36325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBQnb-0001WF-La for submit@debbugs.gnu.org; Fri, 30 Dec 2022 20:36:35 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:44128) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBQnZ-0001W0-7r for 60416-done@debbugs.gnu.org; Fri, 30 Dec 2022 20:36:34 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 33991160041; Fri, 30 Dec 2022 17:36:26 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id j__H--Lo0WDt; Fri, 30 Dec 2022 17:36:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7EA80160064; Fri, 30 Dec 2022 17:36:25 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 7EA80160064 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1672450585; bh=b/OzZesAyTTOsMYmawpJ6h61wkpJCd2SRsMv4HUEGjM=; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type: Content-Transfer-Encoding; b=OjmSbVbbyzbNSjJgw/pd2KJvKWeMACbRNEwmgsaRtDSmUYJl69mS3F3Wf7O/q+NKk 7xkuPww4dTnA7PBEKi3NYFG7XL7gYpQ9Q5BFrMf4hyKk9HPnsV5LiAS/veON/4vcMD Hw6c4PcbVee4DB12000iVo9Kb5/XiuU6u8jROvYw= X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Yrl4kpQRJtaZ; Fri, 30 Dec 2022 17:36:25 -0800 (PST) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 4C321160041; Fri, 30 Dec 2022 17:36:25 -0800 (PST) Message-ID: <397e91ba-fbed-4baf-288c-a75f574742e7@cs.ucla.edu> Date: Fri, 30 Dec 2022 17:36:24 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#60416: [PATCH] copy: attempt copy offload with sparse files To: =?UTF-8?Q?P=c3=a1draig_Brady?= , Braiam , 60416-done@debbugs.gnu.org References: <980e49f1-e4e7-cace-e2d8-847d90484770@draigBrady.com> <6ad3b71d-140c-005f-b4d8-799c99dab3bf@draigBrady.com> <09b7a83c-a078-1bcc-a55d-62f76939c3b2@cs.ucla.edu> <637162a7-d215-ac74-b422-a5539c09bff4@draigBrady.com> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <637162a7-d215-ac74-b422-a5539c09bff4@draigBrady.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: 60416-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.4 (----) On 2022-12-30 16:23, P=C3=A1draig Brady wrote: >=20 > I may follow up with a related patch to > ensure we _don't_ use copy_file_range with --sparse=3Dnever. Not sure it's worth the bother. A file system that would create holes=20 with copy_file_range could also do so with plain 'write', no? From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 31 07:04:37 2022 Received: (at 60416-done) by debbugs.gnu.org; 31 Dec 2022 12:04:37 +0000 Received: from localhost ([127.0.0.1]:36755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBabM-0002pu-Vf for submit@debbugs.gnu.org; Sat, 31 Dec 2022 07:04:37 -0500 Received: from mail-wm1-f41.google.com ([209.85.128.41]:56105) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBabL-0002pe-EO for 60416-done@debbugs.gnu.org; Sat, 31 Dec 2022 07:04:35 -0500 Received: by mail-wm1-f41.google.com with SMTP id l26so15423901wme.5 for <60416-done@debbugs.gnu.org>; Sat, 31 Dec 2022 04:04:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=NHINH5B7DDjqcmUB4hOsHWPlNVu1AQS5Apix/KJViJo=; b=BAy5S67QdUIfw6tGS0Y+XMqskSFKTra7vWRBEVxhsqTnYcyeqVteTG/yt1dJUCyXdb Mu1nvyIkJMaQxrjBK/g+obydpFXgsgslxH1brh9vbG5wwcHaaDuVOy/AMe7WZues+qIM vBkF8LkSzs5favyD/rVwk4m+iqkIZCjNRJ5gV1B2nuYD5IukN8e0aeVq13VxnoZyORLu 0hUJaUpgm6lO992JKBD2Su2DgvuqKYRO6BA9EJZHpShqIJ5D135o+CvGISYAoChyZC/D YFj0iYk4kMRoNJJ6TxxD1rLUOWe3xBOHuwK7auU9M4X/VXlM7fGa2K5Rh9N+JPw4O/KJ Tu7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NHINH5B7DDjqcmUB4hOsHWPlNVu1AQS5Apix/KJViJo=; b=1+i+/rrylDi1Z5H0lM6I7lbIojIpoB0tFBCa9qg5TgVVZ6Q8w+i7jErZt9JWsPX9cV mxawis1b6mQAJLF05LIOetMP/4RKpOsdRFw6nWkLrDT9OkNxvMotwy1rpZxHRhblyNSz sPc/7LS4iOC092RWERud1M3k5rZFC5VG1dkZFHPLL3+6E7pSX5KiCArmvdmnfUYox7l7 VAZhjnPJA7bvpE66YOZmbMCfay9Ja8Xr3u5xq3iUQWxicZP+K9NyRX2wA2GwkaBFAUqz DK4FjB5Yjuz3ArKr3KwfdbKSLQ34ZPkz9JSdhbl4RLtxth02zjnfujGgT4LMqiSvwta8 O7jw== X-Gm-Message-State: AFqh2kpSaJijx6abSnXHAVoaAELfv7Z/I5vcYxArZ5at7Ulh2CYGlq7h pbTzDY1uaURDHrsin13Cqsk= X-Google-Smtp-Source: AMrXdXv6yFhJGws2ZblC1uI3ylfjKVrjN8fK5cZrS4K8DWrdVXbMgCXPI74gJit7WYi0kABtQwR75g== X-Received: by 2002:a05:600c:22c4:b0:3cf:8ed7:712d with SMTP id 4-20020a05600c22c400b003cf8ed7712dmr28094691wmg.14.1672488269340; Sat, 31 Dec 2022 04:04:29 -0800 (PST) Received: from [192.168.1.9] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id fc7-20020a05600c524700b003a3442f1229sm40738148wmb.29.2022.12.31.04.04.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 31 Dec 2022 04:04:28 -0800 (PST) Message-ID: <50220b20-3047-01ea-5ecb-066d8cf26379@draigBrady.com> Date: Sat, 31 Dec 2022 12:04:27 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.0 Subject: Re: bug#60416: [PATCH] copy: attempt copy offload with sparse files Content-Language: en-US To: Paul Eggert , Braiam , 60416-done@debbugs.gnu.org References: <980e49f1-e4e7-cace-e2d8-847d90484770@draigBrady.com> <6ad3b71d-140c-005f-b4d8-799c99dab3bf@draigBrady.com> <09b7a83c-a078-1bcc-a55d-62f76939c3b2@cs.ucla.edu> <637162a7-d215-ac74-b422-a5539c09bff4@draigBrady.com> <397e91ba-fbed-4baf-288c-a75f574742e7@cs.ucla.edu> From: =?UTF-8?Q?P=c3=a1draig_Brady?= In-Reply-To: <397e91ba-fbed-4baf-288c-a75f574742e7@cs.ucla.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.9 (/) X-Debbugs-Envelope-To: 60416-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.9 (-) On 31/12/2022 01:36, Paul Eggert wrote: > On 2022-12-30 16:23, Pádraig Brady wrote: >> >> I may follow up with a related patch to >> ensure we _don't_ use copy_file_range with --sparse=never. > > Not sure it's worth the bother. A file system that would create holes > with copy_file_range could also do so with plain 'write', no? Well copy_file_range() would be lower level and within its remit to propagate holes. The FreeBSD docs allude to this also. But yes, our use of copy_file_range() is generally restricted to non holes, so less of an issue for us. Also there may be users using `cp --sparse=never` to avoid the perf issue currently, like we saw on the OP web thread. I'll hold off on that change so. Hopefully copy_file_range() flags are introduced to give control over this (like I suggested on lkml years ago). cheers, Pádraig From unknown Sun Jun 15 08:52:11 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 28 Jan 2023 12:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator