Subject: [nfsv4] fate of ADHs in 4.2

From: Christoph Hellwig <[email-masked]>
Date: Mon, 10 Feb 2014 17:52:15 +0100

I'd like to bringing back an old discussion from November about the
problems with the ADH support in the current 4.2 draft.

Back then David wrote:

> Agree with this. Note that in -20 the fourth paragraph of 14.10.3 explains (incorrectly) why READ_PLUS  has to support NFS4ERR_UNION_NOTSUPP and so should be deleted.
> 
> Note that the bigger problem with READ_PLUS as currently specified is that there is no way to deal with the fact that the server can return a data_content4 that it supports but that the client does not. Given that such features as ADH's are to be optional, clients need to be able to avoid supporting such content types.

I brought up the same issue earlier and would like to avoid having the
current state of ADHs encoded in a standard.  My preference would be to
remove them entirely until people interested in actually implementing
them on the client server side can come up with a version that doesn't
have the the current drawback of destroying the flat file model, and
require any 4.2-capable client (or rather any client using READ_PLUS)
to deal with them.  If a version is kept I would much prefer it to be similar
to the INITIALIZE operation from the original enterprise applications draft,
which has non of these issues.

Back in Novemeber in addition to David and my opinions we managed to gather
the following others on the nfsv4 list:

Bruce Fields:
> > *         Getting rid of ADH's, at least for NFSv4.2.
>
> I think the latter's the default until someone speaks up for it.  No
> point trying to maintain protocol features that noone's still interested
> in.  (And we're unlikely to do it right without someone that knows what
> they want out of it anyway.)

Marc Eshel:
> I would prefer to remove ADH from NFSv4.2 but if we keep it than it should
> be a separate operation from READ/WRITE_PLUS and it can be an optional
> operation, I don't think we need to change EXCHANGE_ID.

I've not heard a single voice in support of ADHs in their current form since,
so I'd like to bring this whole discussion back under a proper subject in
case people that want to support ADHs missed the earlier discussion.

---

From: "Haynes, Tom" <[email-masked]>
Date: Mon, 10 Feb 2014 17:14:53 +0000

On Feb 10, 2014, at 8:52 AM, Christoph Hellwig <[email-masked]<mailto:[email-masked]>> wrote:

So I am interested in implementing ADHs.

I'm not particularly married to delivering the hole property in NFSv4.2. Why
deliver something better than T10 SBC?

Since you are bringing up history, here is the last I had on the discussion:

3) Solution

It appears the ADH concept developed from the INITIALIZE operation
proposed in

http://tools.ietf.org/html/draft-eisler-nfsv4-enterprise-apps-01

which has none of the above issues.  The INITIALIZE operation is modeled
after the T10 SBC WRITE SAME family of operations which have traditionally
been used by enterprise application, hypervisors and file systems to provide
the functionality that ADHs attempt to provide.

Despite being in discussion for over 2 years, no one has pointed out the
use of WRITE SAME before.

I don’t see a good description online about how it will handle the block
number and pattern. Do you have a reference?

I'm still waiting for someone who knows T10 SBC to step up and answer the question.

---

From: Christoph Hellwig <[email-masked]>
Date: Mon, 10 Feb 2014 18:29:30 +0100

> I'm still waiting for someone who knows T10 SBC to step up and answer the question.

http://www.ietf.org/mail-archive/web/nfsv4/current/msg12532.html has a pointer
to how patterns and block numbers work, do you need more details?

p.s. your mail client seems to not quote properly, at least the mail I got
does not actually quote my original text at all.  This makes reading the
mails a little painful.