Date: Sun, 24 Aug 2025 19:08:23 -0700 From: Rick Macklem <rick.macklem@gmail.com> To: Rob Norris <robn@despairlabs.com> Cc: freebsd-hackers@freebsd.org Subject: Re: NFSv4.2 READ_PLUS support? Message-ID: <CAM5tNy4j2t5FpJE9dWBOkZpWKtJaAkq=mhnb0A7x0KQ%2BpZdBSQ@mail.gmail.com> In-Reply-To: <99aea3ba-73d3-4f0b-be2c-ae06752da4bb@app.fastmail.com> References: <CALXu0UfzyaZti2dSbZHPf_YXU88_2oCP98cXJPM6mQ9Fsr6ZuQ@mail.gmail.com> <CAM5tNy7x=AttZiu=ZLFtiQS3U2JD=gZOgjeGE-VoB1Obp9eZxQ@mail.gmail.com> <aKh3ZpxPYSIfMFfX@kib.kiev.ua> <CAM5tNy6WL93tVX18RsEUymYXON-W50i_-xm1CxrN6n0nbecmYg@mail.gmail.com> <CALXu0Uf%2B=GD8ZkZmN1v3s2GKp8Y5VDoiTO-cjay3Ypf1wmPMQw@mail.gmail.com> <CAM5tNy7nNCJBukrsC0MZJz9oQsGk5=CUaGhMJYkue6VL0yEmww@mail.gmail.com> <99aea3ba-73d3-4f0b-be2c-ae06752da4bb@app.fastmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 24, 2025 at 6:49 PM Rob Norris <robn@despairlabs.com> wrote:
>
> On Sat, 23 Aug 2025, at 1:24 AM, Rick Macklem wrote:
> > There is a performance problem for ZFS related to holes and recently
> > written data (if vfs.zfs.dmu_offset_next_sync=1 recently created holes
> > will be found, but it really slows things down).
>
> To be clear, "recently created" here means that the record has not yet
> been written to disk, and so hasn't been through the compression stage
> in the IO pipeline yet, which is where things are turned into holes.
> dmu_offset_next_sync=1 is slow because it forces the entire transaction
> to be written down before doing the hole check. It's a very blunt
> instrument.
>
> There is some work happening to improve this situation (GH#16025[1] and
> followup[2]) that I hope to have time to assist with before the end of
> the year, so I think at least it's ok to plan for a future where ZFS is
> rather less slow at hole detection.
>
> > To get this right, it will take someone that really knows ZFS to
> > figure out how to do a VOP_READPLUS() well.
>
> I'd be happy to work on the ZFS side with a partner on the FreeBSD side.
I will think about what arguments a VOP_READPLUS() might have, but it
will be a while. (Next year is probably a reasonable timeframe.)
And, yes, I would definitely need help w.r.t. the ZFS implementation.
Fyi, Sec. 15.11.3 of RFC7862 seems to be vague on what the Seek
operation (and what a hole is). It does state...
SEEK is an operation that allows a client to determine the location
of the next data_content4 in a file. It allows an implementation of
the emerging extension to the lseek(2) function to allow clients to
determine the next hole whilst in data or the next data whilst in
a hole.
Which seems to indicate that it is meant to be lseek(2) compatible
and, although it was not a ratified standard when RFC7862 was
published, I think it is now a ratified POSIX standard (or will be
soon?).
rick
ps: I have never seen a statement that SEEK_DATA/SEEK_HOLE
must find all unallocated regions in a sparse file, although I
understand that that would be a nice feature.
>
> Cheers,
> Rob.
>
> 1. https://github.com/openzfs/zfs/pull/16025
> 2. https://github.com/openzfs/zfs/compare/master...rrevans:zfs:find_dirty
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy4j2t5FpJE9dWBOkZpWKtJaAkq=mhnb0A7x0KQ%2BpZdBSQ>