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.
- [nfsv4] draft-eisler-nfsv4-enterprise-apps-00.txt Mike Eisler
- Re: [nfsv4] draft-eisler-nfsv4-enterprise-apps-00… J. Bruce Fields
- Re: [nfsv4] draft-eisler-nfsv4-enterprise-apps-00… Chuck Lever
- Re: [nfsv4] draft-eisler-nfsv4-enterprise-apps-00… J. Bruce Fields