Re: How does READ_PLUS differ from READ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 22, 2023 at 2:48 PM Cedric Blancher
<cedric.blancher@xxxxxxxxx> wrote:
>
> On Sun, 19 Nov 2023 at 19:02, Anna Schumaker <schumaker.anna@xxxxxxxxx> wrote:
> >
> > On Sun, Nov 19, 2023 at 12:59 PM Cedric Blancher
> > <cedric.blancher@xxxxxxxxx> wrote:
> > >
> > > On Sun, 19 Nov 2023 at 18:48, Anna Schumaker <schumaker.anna@xxxxxxxxx> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Sun, Nov 19, 2023 at 12:38 PM Cedric Blancher
> > > > <cedric.blancher@xxxxxxxxx> 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 ranges
> > > > 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 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 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.

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

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





[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux