[nfsv4] Disk protection problem for pNFS block

sfaibish <sfaibish@emc.com> Thu, 21 October 2010 17:20 UTC

Return-Path: <sfaibish@emc.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 7939F3A698E for <nfsv4@core3.amsl.com>; Thu, 21 Oct 2010 10:20:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.324
X-Spam-Status: No, score=-6.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id rG6xbMj+wRhD for <nfsv4@core3.amsl.com>; Thu, 21 Oct 2010 10:20:02 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com []) by core3.amsl.com (Postfix) with ESMTP id 5E0E53A69AF for <nfsv4@ietf.org>; Thu, 21 Oct 2010 10:20:02 -0700 (PDT)
Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com []) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9LHLalE016614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <nfsv4@ietf.org>; Thu, 21 Oct 2010 13:21:36 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com []) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for <nfsv4@ietf.org>; Thu, 21 Oct 2010 13:21:29 -0400
Received: from usensfaibisl2e.eng.emc.com (USENSFAIBISL2E.eng.emc.com []) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9LHLPE7029163 for <nfsv4@ietf.org>; Thu, 21 Oct 2010 13:21:25 -0400
Date: Thu, 21 Oct 2010 13:21:25 -0400
To: nfsv4 list <nfsv4@ietf.org>
From: sfaibish <sfaibish@emc.com>
Organization: EMC
Content-Type: text/plain; format="flowed"; delsp="yes"; charset="iso-8859-15"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <op.vkxrtzyxunckof@usensfaibisl2e.eng.emc.com>
User-Agent: Opera Mail/9.10 (Win32)
Subject: [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 17:20:03 -0000

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. 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  

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  
as an extenssion to RFS5663 for example. So Jason and I propose something  

1) Clients can have configuration file that specifies the signatures to  
    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  
    the signatures, and then make sure that they are listed in the  
    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  
all the opinion and include in the discussion in Beijing. Thank you for  


Best Regards

Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division
where information lives

Phone: 508-249-5745
Cellphone: 617-510-0422
Email : sfaibish@emc.com