RE: [nfsv4] Clarification on READ with an all bits 1 stateid

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 05/14/03-09:01:41 AM Z


Subject: RE: [nfsv4] Clarification on READ with an all bits 1 stateid
Message-ID: <C8CF60CFC4D8A74E9945E32CF096548A6D33DA@silver.nane.netapp.com>
From: "Noveck, Dave" <Dave.Noveck@netapp.com>
Date: Wed, 14 May 2003 07:01:41 -0700

I agree this would be a lot more elegant than the all bits
1 approach (although not mainly because it itself is all that
elegant :-).

I think you could break tis up into two pieces that might be
implemented independently.

The first piece is simply to designate outside the protocol
some server-specific mechanism (e.g. mount option) a specific
user having this property.  It isn't clear whether that is
allowed in the current spec (as part of the server's fs semantics).
If it isn't this could be changed in v4.1.  Even if it is,
clarification of this area in v4.1 would be helpful.

Providing a method within the protocol to specify the user(s)
having this behavior, via a new ACE access mask bit, to be 
added in a v4.1 or another minor version.  The issue here would
be server implementations that would have trouble implementng
this semantic.  If it was done as "MAY override", then this 
wouldn't be an issue although that would also make it less
useful for client, although we currently have "MAY override"
for the all bits 1 thing anyway.

-----Original Message-----
From: Benny Halevy [mailto:bhalevy@panasas.com]
Sent: Tuesday, May 13, 2003 9:24 PM
To: Noveck, Dave
Cc: Carl Burnett; nfsv4@ietf.org
Subject: Re: [nfsv4] Clarification on READ with an all bits 1 stateid



Noveck, Dave wrote:
> 
> Yes, but this is only read.  I'm assuming that the intention of
> this is for somethng like backup.  Today, the issue doesn't arise 
> because backup is done with some sort of local access and the v4
> ruls don't apply.  If someone wants to do a backup and use v4 to 
> access the files, then it might be reasonable for him to say that
> he want to be able to backup a file even though someone has it 
> opened denying read.  If clients implement a way for him to request
> all-ones stateid to do this read, and customers need that functionality
> then I could see creating an option to allow the locking checks to
> be bypassed  in this case.
>  

Wouldn't it make more sense to use the ACL for such a feature: i.e. 
allow someone (e.g. backup admin account) to overide locks for read access?

I know this is not in NFSv4 but could be much more elegant than the all 
bits 1 solution.

--
Benny Halevy
bhalevy@panasas.com


_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-02:12:25 AM Z CST