[Top][All Lists]

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

Re: Dataloss copying file using copy-file on RHEL 8.

From: Paul Eggert
Subject: Re: Dataloss copying file using copy-file on RHEL 8.
Date: Wed, 12 Feb 2020 17:32:55 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 2/12/20 2:37 PM, David Koppelman wrote:
Except I don't get the
efficient kernel-space-to-kernel-space transfer that copy_file_range

It's more than just kernel-space-to-kernel-space copying. When copying a file within an NFS server, you don't need to ship its contents over the network; the server can do the copy. Also, many modern filesystems can copy files by fiddling with pointers rather than data and thus can copy much faster than read+write would do, even on local filesystems. So avoiding copy_file_range entirely would mean a big performance loss on big files.
I do not experience the problem on the version of Emacs packaged with
rhel 8, "GNU Emacs 26.1 (build 1, x86_64-redhat-linux-gnu, GTK+
Version 3.22.30) of 2018-09-10".

Emacs 26.1 doesn't use copy_file_range, which explains why it doesn't encounter your problem. Emacs 27 is planned to use it, though, so we should see how to best fix the problem.

As you say, it's a serious bug in your filesystem. It strikes me that it is likely to affect programs other than Emacs, so it should be high priority to fix regardless of what we do in Emacs.

Some questions: What is the NFS fileserver (NetApp, etc.)? What's the blocksize on the remote file system? Does copy_file_range work correctly when the size is a multiple of 32*1024? If so, perhaps we could tweak Emacs to use copy_file_range for most of the file, and use read+write only for the trailing <32 KiB.

When I have time I'll try to reproduce the problem with a quick C++
routine using copy_file_range.

To save you some time, attached is a quick C routine that attempts to reproduce the problem. Does it reproduce the problem for you? If so, you can use it in your bug report to Red Hat.

Also, can you strace the failing Emacs? Something like this:

strace -o trace.log emacs -Q -batch -eval '(copy-file "a" "b" t t)'

and then look at the relevant part of trace.log.

Attachment: cfrbug.c
Description: Text Data

reply via email to

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