Subject: Re: [nfsv4] nfsv4 Digest, Vol 85, Issue 15

From: Morgan Lean <[email-masked]>
Date: Wed, 11 May 2011 10:06:38 +1000

UNSUBSCRIBE

On Wed, May 11, 2011 at 9:53 AM,  <[email-masked]> wrote:
> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/nfsv4
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send nfsv4 mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.ietf.org/mailman/listinfo/nfsv4
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of nfsv4 digest..."
>
>
> Today's Topics:
>
>   1. Re: [LNFS] Namespace access (Nico Williams)
>   2. Re: [NFSv4.2] Meeting Notes for 05/05/2011 (Thomas Haynes)
>   3. [LNFS] Meeting Agenda for 05/12/2011 (new conference number)
>      (Thomas Haynes)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 10 May 2011 16:16:18 -0500
> From: Nico Williams <[email-masked]>
> To: Thomas Haynes <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [nfsv4] [LNFS] Namespace access
> Message-ID: <BANLkTin2JmWu8rAKFL=h=[email-masked]>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, May 10, 2011 at 1:34 PM, Thomas Haynes <[email-masked]> wrote:
>> One of the sections I pulled in was:
>>
>> 8. ?Namespace Access
>> ?? The server should provide a means to authorize selective access to
>> ?? the exported file system namespace based upon client credentials and
>> ?? according to security policy.
>> ?? This is a common requirement of MLS-enabled systems, which often need
>> ?? to present selective views of namespaces based upon the clearances of
>> ?? the subjects.
>>
>> I'm not sure now whether we want to have it or not. I think the difference
>> between NFSv3
>> and NFSv4 namespace semantics combined with the MAC checks on?both READDIR
>> and LOOKUP should solve this issue.
>> I.e., MOUNT does not exist in NFSv4 as a separate protocol and as such, the
>> checks
>> on existing operations should suffice.
>
> +1
>
> In NFSv4 there's no real difference between "mount" and "open" (the
> client can and should want to notice when it crosses server-side
> mounts, but it's not strictly necessary).
>
>> The larger question might be whether we want to specify what happens in
>> READDIR
>> and LOOKUP when MAC access checks fail?
>
> READDIR needs to be able to filter results by MAC policy (and share
> ACLs) -- this is new, but the rest is not.
>
> Nico
> --
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 10 May 2011 16:49:51 -0500
> From: Thomas Haynes <[email-masked]>
> To: Dean Hildebrand <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [nfsv4] [NFSv4.2] Meeting Notes for 05/05/2011
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
>
> On May 10, 2011, at 12:45 PM, Dean Hildebrand wrote:
>
>>> Dean wants a completely fleshed out proposal
>>> that he can forward to other people for review. He
>>> wants to see it rewritten to specifically address
>>> corruption. He doesn't want to see sparse reads
>>> forced into this framework, he believes it is too complex.
>>> He wants ADBs out of NFSv4.2 as he believes that
>>> they are not mature enough.
>>
>> Let me clarify my concerns:
>> 1) Lack of related work.  Why are ADBs the best method for NFS to detect data corruption?  What are the other possibilities     (checksums, etc) and why are they inferior?  From the calls, I think there is a general lack of understanding of why this proposal is superior to the breadth of other data corruption detection techniques.
>>
>
>
> The section in the NFSv4.2 draft addresses this issue - the approach taken is
> a generic bare bones approach that provides the framework necessary to
> implement this functionality across a wide range of applications.
>
> The example in the section also illustrates that while checksums are
> one means of detecting corruption, each application might be able to
> exploit rules on the state of the ADB.
>
> One of the key points to understanding this approach is that the
> guard pattern does not allow detection of corruption based on
> overwrites, but as a state token. The guard pattern informs the
> application on how to detect corruption in the block. And not only
> can different applications have different corruption detection
> algorithms, but the same application might have different approaches
> in the same file.
>
> Also, this focus on only corruption does not do service to the full
> proposal, which was summarized in the notes as:
>
> The proposal is for a generic framework to allow:
>
> 1) corruption detection - which applications already do
>
> 2) efficient transfer and storage of data blocks - which
> applications cannot do because NFS does not have
> any protocol support yet.
>
> Another way to think of it is:
>
> The ADB proposal allows applications which manage data
> corruption to leverage modern storage efficiency.
>
>
>
>
>> 2) Transparency. This proposal puts all the onus on the application developer to detect the corruption.  Is it be possible to provide a end-to-end data corruption detection mechanism that is more transparent to the application developer?
>>
>
>
> The WG has considered checksums for NFSv4 in the past, see for example
> http://www.connectathon.org/talks06/aggarwal.pdf . Some issues with that
> are settling on an algorithm and the cost of computing it.
>
> What is missing from that approach is the ability for the application to
> know the state of the data and possible corruption based on that.
>
> Consider the example from the draft, a block of data versus an indirect block.
> In the first, a checksum is sufficient to find issues. In the second, whilst
> a checksum might find no issues, simple checks to see if the same block
> number is dereferenced multiple times or if a block number is greater
> than the max available could detection application level corruption.
>
>
>
>> 3) Examples. So far all discussion around ADBs has been on how they work at the NFS level.  The motivation though seems to be to provide a data corruption technique for application developers.  To this point, what is clearly missing is a simple example of how your average C programmer would take advantage of ADBs.
>
>
> This is present in the NFSv4.2 section.
>
> Note that this was pointed out as a deficiency in the 4/21 meeting and provided on 5/3
> in time to be absorbed by the 5/5 meeting.
>
>
>>
>> 4) An document has never existed (just emails) that answered all of these issues.  The original enterprise apps ID had many items in it that were not related to this proposal.  If such a document existed, it could be sent to a wider database and file system community to garner valuable feedback regarding data corruption techniques in distributed file systems.
>
>
> Stating the the Enterprise Apps I-D contains unrelated items is not sufficient to
> stating that these issues are unanswered. Crafting that document down to
> the issues we are willing to work on is an editorial process. And that editorial
> process is an ongoing effort.
>
> The NFSv4.2 I-D had a section that reflected that editorial process prior to this meeting.
> After the meeting, edits were made to help clarify the section.
>
> If you believe a wider audience should be considering the proposal, please
> point them to the document. It is out in the open. Please make them aware
> that it is a work in progress.
>
> Also, we have a choice whether to spend our energy on selling this document
> or making it release ready. We had the same issue with the Labeled NFS
> work and chose to focus on making it release ready. We still do not know
> whether LNFS will come into NFSv4.2, but if we spend our time on making
> it pretty, it will not be as functional as it can be.
>
>>
>> 5) Time. There are other much more mature proposals that were agreed to be in NFSv4.2.  With so many unanswered questions, and some clear uncertainty over the number and range of application developers that would take advantage of ADBs, is this really ready for the train?
>
>
> The original Enterprise Apps I-D presented a comprehensive approach to
> sparse files (reading and writing), hole punching, and space reservations.
> Each of which were considered important on their own.
>
> Each of these items still have open issues that need to be addressed, either
> in the context of ADBs or on their own. I.e., does a hole punch go to the
> MDS or the DS? If it goes to the MDS, does it force the layout to be
> recalled?
>
> Our criteria for the time driven release model is how much energy is someone
> willing to apply - not how much energy is it going to take. The way that will
> be enforced is our commitment to drop something from the release because it
> impacts the schedule.
>
> Finally, what is NFSv4.2 supposed to be? Is it a vehicle to introduce major
> infrastructural changes like NFSv4.0 and NFSv4.1?
>
> No.
>
> I believe the focus on NFSv4.2 is to bridge the gap between applications,
> the protocol, and storage. We know storage systems can support sparse
> files, hole punches, space reservations, and server to server copy. And
> we know applications will perform much better if these features can
> be exploited during data transfer. We also know applications can
> detect data corruption at the application and not OS level. We need to
> exploit both ends of the spectrum.
>
>
>
>>
>> Dean
>>>
>>> Tom disagrees.
>>>
>>> The proposal is for a generic framework to
>>> allow:
>>>
>>> 1) corruption detection - which applications already do
>>>
>>> 2) efficient transfer and storage of data blocks - which
>>> applications cannot do because NFS does not have
>>> any protocol support yet.
>>>
>>>
>>>
>>> + NFS4ERR_NOTSUPP and enums
>>>
>>> We did not get to this item.
>>>
>>> _______________________________________________
>>> nfsv4 mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>> _______________________________________________
>> nfsv4 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nfsv4
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/nfsv4/attachments/20110510/179dc8a3/attachment.htm>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 10 May 2011 18:52:51 -0500
> From: Thomas Haynes <[email-masked]>
> To: [email-masked]
> Subject: [nfsv4] [LNFS] Meeting Agenda for 05/12/2011 (new conference
>        number)
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> Thursday's proposed agenda is below. Please let me know if
> you would like to add additional topics.
>
> PLEASE NOTE: Both the phone numbers and the conference ID have been changed.
>
>   Time: Thursdays 12:30-1:30 PM CST/1:30-2:30 PM EST/10:30-11:30 AM PST
> Dial-in: 1-866-844-9418 (Toll Free)
>       1-517-345-9208 (Caller paid)
>         1800-936-206 (Israel toll free)
>
>     Id: 9744122017
>
> Proposed Agenda
> ---------------
>
> + IETF Note Well Agreement
>
>  This is a reminder that our discussions are governed by the
>  IETF Note Well Agreement. See:
>
>   http://www.ietf.org/NOTEWELL.html
>
>  We will start each week's meeting with this announcement.
>
> + Administrivia
>
> This is the new conference number for all further meetings.
>
> + Multiple labels per object
>
> Simple XDR change to allow multiple labels per object.
>
> Expectation is first implementations will only encode 1, but
> want to be flexible.
>
> + Discovery of DOI supported by server
>
> A per filesystem attribute or is this per object?
>
> Does it matter to the client?
>
> Again, expectation is 99% of the systems will only encode 1.
>
> + Label aware server
>
> I've proposed we allow a LFS=0 to be a label aware server. I think
> Sorin effectively showed this will not work. I.e., we want the
> smart clients to use labels that they can understand.
>
> Is this a useful attribute to let a client be aware of?
>
> + LFS Registry
>
> Sorin has proposed that we pull this into the I-D, which will finally
> consolidate all LFS documentation into one. I've done this.
>
> + Namespace access
>
> Motion is to strike that section as no MOUNT sideband protocol.
>
> Need to add text about READDIR processing.
>
> + CB_LABEL_CHANGED
>
> Nico proposed that instead of a CB that just flags a label
> change, we have a CB that informs the client that the
> attributes have changed. Two levels - critical and non-critical.
>
> The client would then query the server for the changes.
>
> + Label change algorithm
>
> We went over this both in the last meeting and in the followup
> email. I want to make sure I captured what we agreed to...
>
> Server gets request to change object label
>
> Server satisfies preconditions to allow change
> 1) At the spec level: if open delegations, must be recalled
> 2) At the DOI level: ala Solaris TX, file must be 'tranquil'
>
> Server makes change
>
> Effects are immediate
> 1) I.e., if more restrictive, subject loses access, writes lost, etc
>
> Server sends out CB_LABEL_CHANGED
>
> Questions:
>
> Q1) Do we want to differentiate between NFS4ERR_DELAY
> and something like NFS4ERR_DOI_BLOCKING?
>
> Q2) Do we want to provide a means for a client to state
> that the change must be applied right now! I.e.,
> revoke delegations right away and ignore DOI
> constraints?
>
> + Interop Testing at the BAT
>
> NFSv4.2 spec temporarily has XDR for LNFS.
>
> Who is bringing a prototype and what level?
>
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/nfsv4/attachments/20110510/0a7b666c/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>
> End of nfsv4 Digest, Vol 85, Issue 15
> *************************************
>

---

From: "Sorin Faibish" <[email-masked]>
Date: Tue, 10 May 2011 20:39:12 -0400

What is this message about?

On Tue, 10 May 2011 20:06:38 -0400, Morgan Lean
<[email-masked]> wrote:

>>> 1) Lack of related work.  Why are ADBs the best method for NFS to  
>>> detect data corruption?  What are the other possibilities      
>>> (checksums, etc) and why are they inferior?  From the calls, I think  
>>> there is a general lack of understanding of why this proposal is  
>>> superior to the breadth of other data corruption detection techniques.
>>>
>>
>>
>>> 2) Transparency. This proposal puts all the onus on the application  
>>> developer to detect the corruption.  Is it be possible to provide a  
>>> end-to-end data corruption detection mechanism that is more  
>>> transparent to the application developer?
>>>
>>
>>
>>> 3) Examples. So far all discussion around ADBs has been on how they  
>>> work at the NFS level.  The motivation though seems to be to provide a  
>>> data corruption technique for application developers.  To this point,  
>>> what is clearly missing is a simple example of how your average C  
>>> programmer would take advantage of ADBs.
>>
>>
>>> 4) An document has never existed (just emails) that answered all of  
>>> these issues.  The original enterprise apps ID had many items in it  
>>> that were not related to this proposal.  If such a document existed,  
>>> it could be sent to a wider database and file system community to  
>>> garner valuable feedback regarding data corruption techniques in  
>>> distributed file systems.
>>
>>
>>> 5) Time. There are other much more mature proposals that were agreed  
>>> to be in NFSv4.2.  With so many unanswered questions, and some clear  
>>> uncertainty over the number and range of application developers that  
>>> would take advantage of ADBs, is this really ready for the train?
>>
>>
>> URL:  
>> <http://www.ietf.org/mail-archive/web/nfsv4/attachments/20110510/179dc8a3/attachment.htm>
>>
>> URL:  
>> <http://www.ietf.org/mail-archive/web/nfsv4/attachments/20110510/0a7b666c/attachment.htm>
>>

-- 
Best Regards
Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division

           EMC²
where information lives

Phone: 508-435-1000 x 48545
Cellphone: 617-510-0422
Email : [email-masked]

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 11 May 2011 00:55:36 +0000

It appears that Morgan was thinking this was an email list managed by older technology instead of following the mailman link provided in the email to unsubscribe from the list.

Spencer

-----Original Message-----
From: Sorin Faibish
Sent: Tuesday, May 10, 2011 6:53 PM
To: [email-masked]
Subject: Re: [nfsv4] nfsv4 Digest, Vol 85, Issue 15

           EMC²
where information lives