[nfsv4] Disk protection problem for pNFS block

[sfaibish <[e-mail]>]

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  
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: [phone]
Cellphone: 617-510-0422
Email : [e-mail]