Received-SPF: pass (google.com: domain of linux-nfs+bounces-40-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Precedence: bulk
MIME-Version: 1.0
References: <CALXu0UeGnSvBbrfgnRNqdNGjDTag5Lz8uWOvuy_n57RHO3CRqw@mail.gmail.com>
 <CAFX2JfnzDczbegELv3GMCYb3CEKZ+5WfgVotdoA3CyjUprGpTQ@mail.gmail.com>
 <CALXu0UebE2oGgWLMn-NkfGq5n+2dEFnqrOy617SRMmKF-dGOXg@mail.gmail.com>
 <CAFX2JfnDC1xZvuuUiHe8_RpBehwCZriZ13yYPk6pQSPSV4V-qQ@mail.gmail.com>
 <CALXu0UevOCU0dm-0WUEZZFCV=V8jQxmy2OQYhtptVyVAZeWs3g@mail.gmail.com> <CAM5tNy7QYgMUo_tTSPQ6hqxO8WrscBn1O2XpeJVK67OCQMu+2w@mail.gmail.com>
In-Reply-To: <CAM5tNy7QYgMUo_tTSPQ6hqxO8WrscBn1O2XpeJVK67OCQMu+2w@mail.gmail.com>
From: Cedric Blancher <cedric.blancher@gmail.com>
Date: Thu, 23 Nov 2023 23:13:42 +0100
Message-ID: <CALXu0Ue6d7Z+gh5VS_64scjUwPA_-PVKmsv0W+uEx93vbf6dgw@mail.gmail.com>
Subject: Re: How does READ_PLUS differ from READ?
To: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 23 Nov 2023 at 00:19, Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Wed, Nov 22, 2023 at 2:48=E2=80=AFPM Cedric Blancher
> <cedric.blancher@gmail.com> wrote:
> >
> > On Sun, 19 Nov 2023 at 19:02, Anna Schumaker <schumaker.anna@gmail.com>=
 wrote:
> > >
> > > On Sun, Nov 19, 2023 at 12:59=E2=80=AFPM Cedric Blancher
> > > <cedric.blancher@gmail.com> wrote:
> > > >
> > > > On Sun, 19 Nov 2023 at 18:48, Anna Schumaker <schumaker.anna@gmail.=
com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Sun, Nov 19, 2023 at 12:38=E2=80=AFPM Cedric Blancher
> > > > > <cedric.blancher@gmail.com> wrote:
> > > > > >
> > > > > > Good evening!
> > > > > >
> > > > > > How does READ_PLUS differ from READ? Has anyone made a simpler
> > > > > > presentation (PowerPoint slides) than the RFCs?
> > > > >
> > > > > No slides, but at a high level READ_PLUS can compress out long ra=
nges
> > > > > of zeroes in a read reply by returning a HOLE segment instead of =
the
> > > > > actual zeroes. It's perfectly valid for the server to skip the ze=
ro
> > > > > detection and return everything as a data segment, however.
> > > >
> > > > So how do you differ between
> > > > 1. a hole, aka no filesystem blocks allocated
> > > > 2. a long sequence of valid data with all zero bytes in them
> > >
> > > That's up to the server! It could use something like fiemap or lseek
> > > with SEEK_HOLE or SEEK_DATA. It could also scan the data to see if
> > > there are any zeroes that could be compressed out.
> >
> > How can the client figure out whether the data in a READ_PLUS reply
> > are zeros of data, or zeros from a hole?
> As I understand the RFC, it cannot. Or put another way "a hole is a
> region that reads as all 0s, which may or may not have allocated blocks
> on the server file system".
>
> Although SEEK_HOLE typically returns the offset of an unallocated
> region, I don't think either the POSIX draft (was it ever ratified?) nor
> RFC7862 actually define a "hole" as an unallocated region.

Opengroup ratified that one. See https://austingroupbugs.net/view.php?id=3D=
415

>
> On a similar vein, Deallocate can simply write 0s to the region.
> (It does not actually have to "deallocate data blocks".)
>
> At least that is my understanding of POSIX and RFC7862, rick

Can anyone please confirm that RFC7862 and READPLUS cannot distinguish
between allocated and unallocated regions in a file?

Ced
--=20
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur