Re: [nfsv4] Disk protection problem for pNFS block

[Benny Halevy <[e-mail]>]

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?

>> protocol doesn't define a fixed location; the MDS will send it at mount
>> time. 

The mount time thing is linux client specific actually.
The client can issue GETDEVICELIST and GETDEVICEINFO at any time.

>> 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 */
   /// };

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