Re: Why does rangelock_enqueue() hang for hours?

On Tue, Oct 21, 2025 at 7:50 AM Bakul Shah <bakul@iitbombay.org> wrote:
>
> I didn't read this thread before commenting on the forum where Peter
> first raised this issue. Adding the relevant part of my comment here:
> +---
> By git blame cat.c we find it was added on 2023-07-08 in commit 8113cc8276.
> git log 8113cc8276 says
>   cat: use copy_file_range(2) with fallback to previous behavior
>
>   This allows to use special filesystem features like server-side
>   copying on NFS 4.2 or block cloning on OpenZFS 2.2.
>
> May be it should check that these conditions are met? That is, both files should be
> remote or both files should be local for it to be really worth it. In any case IMHO
> this should not be the default behavior. Still, it should not hang....
Peter, you could try the attached trivial patch (untested).

I'm not sure if this is a reasonable thing to do, but at least you can report
back to let us know if it fixes your problem?

rick

> +---
>
>
> > On Oct 21, 2025, at 6:28 AM, Rick Macklem <rick.macklem@gmail.com> wrote:
> >
> > On Tue, Oct 21, 2025 at 6:09 AM Peter 'PMc' Much
> > <pmc@citylink.dinoex.sub.org> wrote:
> >>
> >>
> >> This is 14.3-RELEASE.
> >>
> >> I am copying a file from a NFSv4 share to a local filesystem. This
> >> takes a couple of hours.
> >>
> >> In the meantime I want to read that partially copied file. This is
> >> not possible. The reading process locks up in rangelock_enqueue(),
> >> unkillable(!), and only after the first slow copy has completed, it
> >> will do it's job.
> >>
> >> Even if I do the first copy to stdout with redirect to file, the
> >> same problem happens. I.e.:
> >>
> >> $ cat /nfsshare/File > /localfs/File &
> >> $ cat /localfs/File  --> HANGS unkillable
> > This is caused by "cat" using copy_file_range(2), where the
> > system call is taking a long time.
> >
> > The version done below makes "cat" not use copy_file_range(2).
> > (copy_file_range(2) is interruptible, but that stops the file copy.
> > It also has a "return after 1sec" option.
> > Maybe that option should be exposed to userland and used by
> > "cat", "cp" and friends at least when enabled by a command line
> > option. (I'll admit looking at a file while it is being copied is a bit odd?)
> > The whole idea behind range-lock is to prevent a read/write syscall
> > from seeing a partial write. It just happens that the "write" takes a long
> > time in this case.
> >
> > Do others have thoughts on this? rick
> >
> >>
> >> Only if I introduce another process, the tie is avoided:
> >>
> >> $ cat /nfsshare/File | cat > /localfs/File &
> >> $ cat /localfs/File  --> WORKS
> >>
> >> I very much doubt that this is how it should be.
> >>
> >> Also, if I try to get some information about the supposed operation
> >> of this "rangelock" feature, search engines point me to a
> >> "rangelock(9)" manpage on man.freebsd.org, but that page doesn't
> >> seem to exist. :(
> >>
> >
>