Re: [nfsv4] draft-eisler-nfsv4-enterprise-apps-00.txt

"J. Bruce Fields" <bfields@fieldses.org> Thu, 14 October 2010 16:53 UTC

Return-Path: <bfields@fieldses.org>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C763A699F for <nfsv4@core3.amsl.com>; Thu, 14 Oct 2010 09:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level:
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwu1mxgZm4zS for <nfsv4@core3.amsl.com>; Thu, 14 Oct 2010 09:53:55 -0700 (PDT)
Received: from fieldses.org (fieldses.org [174.143.236.118]) by core3.amsl.com (Postfix) with ESMTP id 99AFC3A693A for <nfsv4@ietf.org>; Thu, 14 Oct 2010 09:53:55 -0700 (PDT)
Received: from bfields by fieldses.org with local (Exim 4.71) (envelope-from <bfields@fieldses.org>) id 1P6R5F-000058-0n; Thu, 14 Oct 2010 12:55:13 -0400
Date: Thu, 14 Oct 2010 12:55:13 -0400
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Chuck Lever <chuck.lever@oracle.com>
Message-ID: <20101014165512.GM24146@fieldses.org>
References: <c8401bdd91b16fd501edd08b5957302c.squirrel@webmail.eisler.com> <20101014160917.GJ24146@fieldses.org> <D75D55EB-5F3F-4BC6-B3CB-837A2B05B106@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D75D55EB-5F3F-4BC6-B3CB-837A2B05B106@oracle.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] draft-eisler-nfsv4-enterprise-apps-00.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2010 16:53:57 -0000

On Thu, Oct 14, 2010 at 12:21:34PM -0400, Chuck Lever wrote:
> 
> On Oct 14, 2010, at 12:09 PM, J. Bruce Fields wrote:
> 
> > On Wed, Oct 13, 2010 at 03:40:21PM -0700, Mike Eisler wrote:
> >> 
> >> (apologies if this a dup)
> >> 
> >> Margaret Susairaj of Oracle and I (of NetApp) posted this
> >> internet-draft, which proposes extensions to NFSv4 for better
> >> support of enterprise applications, such as databases.
> >> 
> >> http://www.ietf.org/id/draft-eisler-nfsv4-enterprise-apps-00.txt
> >> 
> >> I have requested time at the IETF meeting in Beijing to discuss
> >> this.
> > 
> > Miscellaneous, possibly dumb questions:
> > 
> > 	- Can you define "enterprise application" for the purpose of
> > 	this draft?
> > 
> > 	- INITIALIZE: - I'm confused by the motivation.  So an
> > 	application is trying to detect whether an unused section of a
> > 	file has been corrupted?  Does it even care about corruption of
> > 	regions where it hasn't stored any data?  What does data
> > 	corruption in an unallocated region even mean?  If you care
> > 	about data corruption, don't you need additional
> > 	application-level mechanisms (say, checksums of some kind) that
> > 	would render INITIALIZE unnecessary?  I'm sure I'm just missing
> > 	something; pointers to literature welcomed.
> 
> The goal is to look for misplaced writes by applications.  In other
> words, it's a way to detect application software bugs, or
> inappropriate accesses to files by other applications.

Makes sense, thanks--though is a solution that only catches misplaced
writes to unallocated areas so useful?  I'd think it would be more
important to get writes to allocated areas--and that once you've done
that extending it to the holes wouldn't be much more trouble.

> On regular
> disks, you might also look for drive firmware bugs that cause a drive
> to write data into the wrong sectors.

They recommend not allocating space for INITIALIZE-initialized data
(pretty much required if you're going to anwer the rpc request in a
reasonable amount of time).

But I suppose you could copy the data later, or read-modify-write small
portions of it, at which point some of it would be subject to drive
errors, OK.

> > 		- Has anyone talked to e.g. linux filesystem people to
> > 		figure out support for interfaces necessary for an
> > 		application to perform INITIALIZE from a client, and/or
> > 		to let an nfs server perform it on a filesystem?
> 
> I think these are not necessarily intended for a POSIX-style file
> system API with a VFS layer.  A VFS client implementation might
> implement these operations via ioctl.  But... it might be appropriate
> for the server to report to clients that it cannot support these
> features.
> 
> > 	- ADVISE ops: the types look almost like those in posix_fadvise,
> > 	but not exactly; out of curiosity, why the differences?
> > 
> > 	- SESSION_CTL: why is managing an additional sessions more
> > 	complicated than implementing SESSION_CTL?
> 
> And I wonder why the client can't simply terminate a session and
> negotiate a new one with the new parameters.  Increasing the size of
> the session's slot table while there are still slots in use might be
> kind of interesting to implement.

They recommend draining all the other slots before sending SESSION_CTL,
at which point yes maybe it becomes not much different from destroying
one session and creating another.

--b.