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: Benny Halevy (bhalevy@panasas.com)
Date: 05/13/03-08:23:52 PM Z


Message-ID: <3EC19AA8.7020308@panasas.com>
From: Benny Halevy <bhalevy@panasas.com>
Subject: Re: [nfsv4] Clarification on READ with an all bits 1 stateid
Date: Tue, 13 May 2003 21:23:52 -0400


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