Re: [nfsv4] Disk protection problem for pNFS block

"J. Bruce Fields" <bfields@fieldses.org> Thu, 21 October 2010 18:17 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 4FE383A6A32 for <nfsv4@core3.amsl.com>; Thu, 21 Oct 2010 11:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level:
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 ziFPq9OoqOek for <nfsv4@core3.amsl.com>; Thu, 21 Oct 2010 11:17:47 -0700 (PDT)
Received: from fieldses.org (fieldses.org [174.143.236.118]) by core3.amsl.com (Postfix) with ESMTP id BA1C83A6452 for <nfsv4@ietf.org>; Thu, 21 Oct 2010 11:17:47 -0700 (PDT)
Received: from bfields by fieldses.org with local (Exim 4.71) (envelope-from <bfields@fieldses.org>) id 1P8zjX-0002mu-8C; Thu, 21 Oct 2010 14:19:23 -0400
Date: Thu, 21 Oct 2010 14:19:22 -0400
To: sfaibish <sfaibish@emc.com>
Message-ID: <20101021181922.GC10192@fieldses.org>
References: <op.vkxrtzyxunckof@usensfaibisl2e.eng.emc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <op.vkxrtzyxunckof@usensfaibisl2e.eng.emc.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
From: "J. Bruce Fields" <bfields@fieldses.org>
Cc: nfsv4 list <nfsv4@ietf.org>
Subject: Re: [nfsv4] Disk protection problem for pNFS block
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, 21 Oct 2010 18:17:50 -0000

On Thu, Oct 21, 2010 at 01:21:25PM -0400, sfaibish wrote:
> I want to discuss this issue in preparation for the WG discussion on
> this topic. In the current pNFS block protocol the client has to
> contact the MDS in order to get the signature offset of the devices
> used by the block client.
> 
> Users of pNFS block in Linux want to be able to identify a LUN being used
> to store pNFS data without having to contact the metadata server but the
> protocol doesn't define a fixed location; the MDS will send it at mount
> time. The location of the signature is not defined in the protocol but
> we can make it a configuration parameter in the client that will define
> the signature location for each pNFS block server. My prefered solution
> would be to enhance the block protocol.
> 
> In more details the pNFS FS writes a signature to the LUN, but to find
> out the offset of the signature the client first needs to talk with the
> MDS to be told the offset that the signature is located when using
> GETDEVICEINFO. But this is too late and can only be done after the boot
> ends and as a result some boot time applications can destroy the FS.

I'm confused: you're assuming such applications may write to every disk
they discover that isn't on some list of disks not to touch?

The pnfs block protocol has to assume *some* level of sanity from
clients.

--b.

> One
> possible solution is to "hide" pNFS devices or write protect the devices
> that contain pNFS data even if that host doesn't mount the pNFS
> block volume.
> 
> The concern was that there is a window of time before the devices can be
> protected at mount time but it leaves a window of possible data corruption.
> I would also like to include some kind of protection mechanism in
> the protocol
> as an extenssion to RFS5663 for example. So Jason and I propose
> something like
> this:
> 
> 1) Clients can have configuration file that specifies the signatures
> to protect.
>    The signature should be vendor agnostic: "pNFS block device" but
> at a fixed offset.
> 2) Clients could come pre-configured with a protection file that recognizes
>    "most signatures"
> 3) pNFS servers could define a function that will return such signatures.
>    It will be late, but every time one does a mount, the client
> could retrieve
>    the signatures, and then make sure that they are listed in the
> configuration
>    file.  This way the system learns what it needs to protect in
> cases where a
>    new non-standard pNFS server is introduced.
> 
> What do people think about the problem and the solution idea? I will
> collect
> all the opinion and include in the discussion in Beijing. Thank you
> for your
> consideration
> 
> /Sorin
> 
> 
> -- 
> Best Regards
> 
> Sorin Faibish
> Corporate Distinguished Engineer
> Unified Storage Division
>         EMC²
> where information lives
> 
> Phone: 508-249-5745
> Cellphone: 617-510-0422
> Email : sfaibish@emc.com
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4