Re: [nfsv4] Disk protection problem for pNFS block

[sfaibish <[e-mail]>]

On Thu, 21 Oct 2010 14:24:49 -0400, Benny Halevy <[e-mail]>  
wrote:

> On 2010-10-21 20:19, J. Bruce Fields wrote:
>> 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
>
> You mean before sending GETDEVICELIST and GETDEVICEINFO?
In order to issue these you need to have a connection to the MDS and it
is only established at mount time and it cannot be used during the boot.

>
>>> protocol doesn't define a fixed location; the MDS will send it at mount
>>> time.
>
> The mount time thing is linux client specific actually.
Nope. It is for any OS (Solaris as an example).

> The client can issue GETDEVICELIST and GETDEVICEINFO at any time.
To whom? How does he know the MDS before mount?

>
>>> The location of the signature is not defined in the protocol but
>
> Hmm, now I'm confused too :-/
> http://tools.ietf.org/html/rfc5663
> 2.2.  GETDEVICELIST and GETDEVICEINFO
>
> 2.2.1.  Volume Identification
>
>    /// struct pnfs_block_sig_component4 { /* disk signature component */
>    ///     int64_t bsc_sig_offset;        /* byte offset of component
>    ///                                       on volume*/
>    ///     opaque  bsc_contents<>;        /* contents of this component
>    ///                                       of the signature */
>    /// };
The disk signature location is sent to the client in the GETDEVICEINFO
but it only includes signature identifying the device not anything else.
we need something to be specific just ID is not enough to protect. This is
the real problem I want to solve.

/Sorin

>
> Benny
>
>>> 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: [phone]
>>> Cellphone: 617-510-0422
>>> Email : [e-mail]
>>> _______________________________________________
>>> nfsv4 mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4
>
>



-- 
Best Regards

Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division
         EMC²
where information lives

Phone: [phone]
Cellphone: 617-510-0422
Email : [e-mail]