Re: [nfsv4] Disk protection problem for pNFS block

"J. Bruce Fields" <> Thu, 21 October 2010 18:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FE383A6A32 for <>; Thu, 21 Oct 2010 11:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ziFPq9OoqOek for <>; Thu, 21 Oct 2010 11:17:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BA1C83A6452 for <>; Thu, 21 Oct 2010 11:17:47 -0700 (PDT)
Received: from bfields by with local (Exim 4.71) (envelope-from <>) id 1P8zjX-0002mu-8C; Thu, 21 Oct 2010 14:19:23 -0400
Date: Thu, 21 Oct 2010 14:19:22 -0400
To: sfaibish <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2009-06-14)
From: "J. Bruce Fields" <>
Cc: nfsv4 list <>
Subject: Re: [nfsv4] Disk protection problem for pNFS block
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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


> 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 :
> _______________________________________________
> nfsv4 mailing list