From nobody Tue Apr 04 10:49:18 2023 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PrPdt4NcBz43NGg; Tue, 4 Apr 2023 10:49:22 +0000 (UTC) (envelope-from martin@matuska.de) Received: from www541.your-server.de (www541.your-server.de [213.133.107.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PrPdt2QLpz47ST; Tue, 4 Apr 2023 10:49:22 +0000 (UTC) (envelope-from martin@matuska.de) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=matuska.de; s=default2205; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID; bh=jYzR950VJtE58+WQGKBIWx8j7UNXwI7fig7N+IQODS4=; b=QjXbWG5xfrfNK6jle3HZlCbWI8 hoBGD5UBsLcviLw383Aoa4MamX/EgyHTwBNDUGaWkqCKEYOktLsNF+fmcgPpHDDlGJ9y9mX8iEuk+ 8nx0XnrvNTMCIyTSTfz0h0zNSa+BK5fm5mST/m7LOWNSsLAYHFwEK6LRjsAqK9kKwE3mSfn+/WBvR UDobyY03iwn5xoybV99pgbJ2HjiMHGx0Zp35ATY16SJY8BtLV+s+A7TiIyBzfP0R0fHeYzDvSabxm IBeYT+4YD5n9sXi9QKAqyFTjZbNWgwnIUphh1D32x/9nioy2Coj3/Ayp9lGCeRe46EF4tJN8A1QoT 66J3+LzA==; Received: from sslproxy03.your-server.de ([88.198.220.132]) by www541.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pjeE3-000MhC-BZ; Tue, 04 Apr 2023 12:49:19 +0200 Received: from [188.167.171.2] (helo=[10.0.9.128]) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pjeE3-0008Yk-0j; Tue, 04 Apr 2023 12:49:19 +0200 Message-ID: <80ec8122-b9c0-11e7-ae79-e51d217bd261@matuska.de> Date: Tue, 4 Apr 2023 12:49:18 +0200 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: git: 643336549081 - main - If copy_file_range(2) fails with EXDEV, use fall-back. Content-Language: en-US To: Yuri , Mateusz Guzik , Poul-Henning Kamp Cc: Alexey Dokuchaev , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202304040740.3347eiU8033699@gitrepo.freebsd.org> <202304040959.3349xqqB005509@critter.freebsd.dk> <202304041015.334AF7oF006042@critter.freebsd.dk> <872bff80-a306-a5b8-dbc1-cf54be85fa81@aetern.org> From: =?UTF-8?Q?Martin_Matu=c5=a1ka?= In-Reply-To: <872bff80-a306-a5b8-dbc1-cf54be85fa81@aetern.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: martin@matuska.de X-Virus-Scanned: Clear (ClamAV 0.103.8/26865/Tue Apr 4 09:24:56 2023) X-Rspamd-Queue-Id: 4PrPdt2QLpz47ST X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:213.133.96.0/19, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N I have filed this to address this issue: https://github.com/openzfs/zfs/pull/14713 It would be great if someone could review. On 4. 4. 2023 12:31, Yuri wrote: > Mateusz Guzik wrote: >> On 4/4/23, Poul-Henning Kamp wrote: >>> -------- >>> Alexey Dokuchaev writes: >>> >>>> Okay, but did it leave an empty file, I wonder? >>> I didn't check, but it probably would, because cp(1) must have opened >>> and created the destination in order to call copy_file_range(2). >>> >>> PS: I'll note that EXDEV is not a documented return value from >>> copy_file_range(2), and my surprise that cp(1) did not revert >>> to the fall-back, no matter why copy_file_range(2) failed. >>> >> that's a new one and should not be happening, something is borked in >> the kernel -- cross device copies *are* supported >> >> i'll look into it later > Likely has to do with openzfs merge issues reported by Cy just above?