Re: git: 643336549081 - main - If copy_file_range(2) fails with EXDEV, use fall-back.

On Tue, Apr 04, 2023 at 11:31:49AM +0000, Alexey Dokuchaev wrote:
> On Tue, Apr 04, 2023 at 12:31:53PM +0200, Yuri wrote:
> > Mateusz Guzik wrote:
> > > On 4/4/23, Poul-Henning Kamp <phk@phk.freebsd.dk> 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?
> 
> If cp(1) producing empty files for me after commit c98a764c681f is also
> EXDEV-related (which I'm not sure as of yet), it could be that recent
> OpenZFS merely exposed an earlier bug (c98a764c681f is from Jan 2 2021).
> And I didn't have any ZFS on that machine.

Never mind, I've eventually figured it out, it's a totally different bug,
having nothing to do with OpenZFS or EXDEV.

./danfe