Received-SPF: pass (google.com: domain of linux-nfs+bounces-42-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
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> <CALXu0Ue6d7Z+gh5VS_64scjUwPA_-PVKmsv0W+uEx93vbf6dgw@mail.gmail.com>
In-Reply-To: <CALXu0Ue6d7Z+gh5VS_64scjUwPA_-PVKmsv0W+uEx93vbf6dgw@mail.gmail.com>
From: Rick Macklem <rick.macklem@gmail.com>
Date: Thu, 23 Nov 2023 14:42:07 -0800
Message-ID: <CAM5tNy4h8__9Xu1nEx3akLb_qZo-5XfgoT9M=fRYfZt6N2AcrQ@mail.gmail.com>
Subject: Re: How does READ_PLUS differ from READ?
To: Cedric Blancher <cedric.blancher@gmail.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 23, 2023 at 2:14=E2=80=AFPM Cedric Blancher
<cedric.blancher@gmail.com> wrote:
>
> 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.co=
m> 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@gmai=
l.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 simple=
r
> > > > > > > presentation (PowerPoint slides) than the RFCs?
> > > > > >
> > > > > > No slides, but at a high level READ_PLUS can compress out long =
ranges
> > > > > > of zeroes in a read reply by returning a HOLE segment instead o=
f the
> > > > > > actual zeroes. It's perfectly valid for the server to skip the =
zero
> > > > > > 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 lsee=
k
> > > > 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?) no=
r
> > RFC7862 actually define a "hole" as an unallocated region.
>
> Opengroup ratified that one. See https://austingroupbugs.net/view.php?id=
=3D415
>
> >
> > 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?
The best place to ask this is the nfsv4@ietf.org mailing list.
Alternately, you just read the words yourself...
Having said that, here are a few snippets of RFC7862 (neither of which are
in the READ_PLUS section):
In definitions...
   Hole:  A byte range within a sparse file that contains all zeros.  A
      hole might or might not have space allocated or reserved to it.

And in the section on DEALLOCATE...
   All further READs from
   the region passed to DEALLOCATE MUST return zeros until overwritten.
   [irrelevant stuff snipped]
   Situations may arise where da_offset and/or da_offset + da_length
   will not be aligned to a boundary for which the server does
   allocations or deallocations.  For most file systems, this is the
   block size of the file system.  In such a case, the server can
   deallocate as many bytes as it can in the region.  The blocks that
   cannot be deallocated MUST be zeroed.

Now, if the above is not enough to convince you that "hole" does not
necessarily imply "unallocated", then I suggest you read it and then
ask on nfsv4@ietf.org.
(Btw, the DEALLOCATE section uses the term "unreserved" and not
"unallocated".)

I'll also admit I do not understand why you care?
Is there a Windows API that specifically returns unallocated regions
of files?

rick

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