|
From: | Pádraig Brady |
Subject: | bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS |
Date: | Fri, 10 Feb 2023 14:02:19 +0000 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Thunderbird/109.0 |
On 10/02/2023 12:13, George Valkov wrote:
On 2023-02-10, at 11:18 AM, Pádraig Brady <P@draigBrady.com> wrote: I'll apply the simple patch later I think.I have an interesting idea: If I copy a large file, say the 16 GB disk image where I compiled OpenWRT. So I copy this on the same filesystem, and check disk usage before an after: no change. Also the copy is instant. That’s because APFS supports copy-on-write. Initially both files share the same sectors on disk, any changes made after that are copied to new sectors. This is the most efficient way to copy files on APFS, and should produce no corruption. Let’s implement it. I would assume there is a system cal that does the entire copy, And we don’t need to read and write any data. Does the trace contain any interesting calls that might be related to that?
When you say "I copy a large file", is that with gcp or something else? Since coreutils 9.1 we try the CoW by default with fclonefileat() which is available since macOS 10.12 (2016). Note that works only when src and dest are within the same file system, but that is the case for you if I'm reading your original report correctly. When I mentioned that earlier I thought your macOS version was too old to support that, but in fact your 12.6.3 should support fclonefileat() fine. So that's another variable. Is that call failing completely for you? You might be quicker to add a couple of printfs around the fclonefileat() calls in the coreutils from latest git you compliled. Note there is new error handling related to that call in the latest git, compared to what was released in coreutils 9.1. Note also I don't see any fclonefileat() syscalls in your Finder logs at least. cheers, Pádraig
[Prev in Thread] | Current Thread | [Next in Thread] |