Subject: Re: [nfsv4] Proposal for integrating application data holes into the traditional file model

From: Tom Haynes <[email-masked]>
Date: Mon, 21 Apr 2014 13:54:40 -0700

On Fri, Nov 08, 2013 at 08:11:48PM +0100, Christoph Hellwig wrote:
> On Fri, Nov 08, 2013 at 06:41:50PM +0000, Haynes, Tom wrote:
> > I don’t see a good description online about how it will handle the block
> > number and pattern. Do you have a reference?
> 
> Grab a copy of the SBC standard.  Unfortunately the current ones aren't
> publicly available since T10 went closed doors, but
> ftp://www.t10.org/t10/document.05/05-344r0.pdf is recent enough for dicussing
> the basic WRITE SAME features.
> 
> The payload to the WRITE SAME command is the pattern, which gets written
> into each LBA.  Unlike the ADH proposal it is not specified as a sub-region,
> but leaving most of the pattern as zero will archive the same effect in
> a slightly less efficient format.  The block number handling is a lot
> less flexible, but look at Table 75 on Page 42 for the few two options
> to put the logical block number in.
> 

The proposal by Christoph here is to introduce a WRITE_SAME modeled after the T10
WRITE_SAME.

I'll counter-propose that we take the basic idea, but leave a full fledged
WRITE_SAME for another day.

   struct app_data_block4 {
           offset4         adb_offset;
           length4         adb_block_size;
           length4         adb_block_count;
           length4         adb_reloff_blocknum;
           count4          adb_block_num;
           length4         adb_reloff_pattern;
           opaque          adb_pattern<>;
   };

   struct WRITE_ADB4args {
           /* CURRENT_FH: file */
           stateid4        wa_stateid;
           stable_how4     wa_stable;
           app_data_block4 wa_adb;
   };

The server writes adb_block_count copies of the block starting at adb_offset.

Whether the server actually writes the blocks our or not is server specific,
but when the server responds (unless it indicates the WRITE is asynchronous)
all subsequent reads will be as if the blocks had been initialized.

As per Christoph's original proposal, both READ_PLUS and SEEK would have
no knowledge of ADBs. I.e., they are not holes.

-- 
Tom Haynes
ex-cfb

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 22 Apr 2014 08:50:10 -0700

On Apr 21, 2014, at 11:40 PM, Christoph Hellwig <[email-masked]> wrote:

> On Mon, Apr 21, 2014 at 01:54:40PM -0700, Tom Haynes wrote:
> This seems to be very similar to the earlier WRITE SAME versions in SBC.
> 
> I've looked over your proposal and like it in general.  One highlevel
> question is if we really should even bother with the ADH high-level
> concept, that is give it it's own section and description.  The
> abstraction only matters for the arguments to WRITE_ADB, but not
> anywhere outside, so I'd consolidate all the information about it there.

Agreed, I was saving that as a second pass item.

> And btw, I'd prefer WRITE_SAME over WRITE_ADH just because people are
> familar with it.

I'll change it back.