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
