Please issue a working group last call on this document, so that it may be submitted to IESG as a full Standard. _______________________________________________ nfsv4 mailing list nfsv4 <at> ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4
> > Please note all I-Ds that are to be discussed are listed and pointers > provided. > What about the possiblity of a conference call? I'd like to listen in and participate in some of the discussions, especially the ones in the afternoon. I wasn't able to get travel though... Thanx... ps _______________________________________________ nfsv4 mailing list nfsv4 <at> ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4
unfortunately, there is no conference call facilities at the interim WG meeting location.... -->Andy Adamson > > > > > Please note all I-Ds that are to be discussed are listed and pointers > > provided. > > > > What about the possiblity of a conference call? I'd like to listen > in and participate in some of the discussions, especially the ones > in the afternoon. I wasn't able to get travel though... > > Thanx... > > ps > > _______________________________________________ > nfsv4 mailing list > nfsv4 <at> ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > _______________________________________________ nfsv4 mailing list nfsv4 <at> ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4(Continue reading)
To make the meeting effective please take the time to review specs before hand. Bring detailed comments and questions - let's make this a good use of everyone's time. > Please note all I-Ds that are to be discussed are listed and pointers > provided. > > --------------------------------------------------------------------- > > > > Agenda for NFSv4 WG interim meeting (4 June 2003): > ------------------------------------------------- > > 10:00AM EDT Start > ----------------- > > - Welcome, Note Well, and Agenda bashing (5 minutes) (WG co-chairs) > > - Review current NFSv4 Charter and Milestones (10 minutes) (WG co-chairs) > > - "XDR: External Data Representation Standard" > http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rfc1832bis-01.txt > Mike Eisler (2 minutes) > > - "RPC Numbering Authority Transfer to IANA" > http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rpc-iana-00.txt > Rob Thurlow (10 minutes)(Continue reading)
Hi, I am sorry to ask so many questions but we have some controversary here with various interpretations of some locking issues. It seems that when ever we have two people read something we come up with at least three interpretations. I would appreciate it if you could clear up our vision. thanks, Ron 1. I assume that NFS V4 does not preclude reads and writes without a preceeding open. I.e. a client could issue V4 lookup operation to determine a file handle and then use it with stateid of 0s or 1s to read or write. Is it correct to allow this behavior? Is this valid only to an advisory locking file? 1. if we allow V4 read or write without open to a mandatory locking file, I assume that we get a share reservation for the duration of the read or write request. Is this correct? 2. Certainly a client cannot issue V4 locks without valid open, the " locker parameter " on the lock operation does not make sense otherwise. Is this correct? 2. mandatory vs advisory locking questions: 1. it seems that the stateids (as an indication of what locks are held) are only interesting if V4 reads or writes are issued for a mandatory locking file. If access is done to an advisory locking file, a byte range access conflict is determined during the lock operation. V4 read and write operations to an advisory locking file should not check for valid lock ranges being held. If the server did check, there is no error code (not_locked for example) to indicate the error. Is this(Continue reading)
[IBM sure asks a lot of locking questions...] Ronald E Bretschneider wrote: > 1. I assume that NFS V4 does not preclude reads and writes without a > preceeding open. I.e. a client could issue V4 lookup operation to determine > a file handle and then use it with stateid of 0s or 1s to read or write. Is > it correct to allow this behavior? Is this valid only to an advisory > locking file? Yes, and Maybe. Bottom line is that a server may reject any use of all 0's or all 1's stateids for any reason. But it is expected that doing I/O via a LOOKUP and READ/WRITE without an OPEN will generally be allowed. It is up to the server to determine how it interacts with other locking mechanisms and if it will allow it in the face of an outstanding lock, be it mandatory or advisory. The design encourages I/O operations that will not corrupt an active lock, such as reading a read or write locked file but not allowing a write to a file with any locks. But again, it is up to the server to define the behavior. > 1. if we allow V4 read or write without open to a mandatory locking > file, I assume that we get a share reservation for the duration of the > read or write request. Is this correct? No, there are no "implicit" locks for any operation (this was hinted in early drafts that just confused things). How the server allows interaction from a client without an OPEN to one with a current share resv is server defined. Some servers may never cause a request to be denied, other may always. In general, share reservations are orthogonal to byte range locks, one controls access to OPEN a file, the other(Continue reading)
On Mon, David Robinson wrote: > [IBM sure asks a lot of locking questions...] > > Ronald E Bretschneider wrote: > >1. I assume that NFS V4 does not preclude reads and writes without a > >preceeding open. I.e. a client could issue V4 lookup operation to determine > >a file handle and then use it with stateid of 0s or 1s to read or write. Is > >it correct to allow this behavior? Is this valid only to an advisory > >locking file? > > Yes, and Maybe. Bottom line is that a server may reject any use > of all 0's or all 1's stateids for any reason. But it is expected > that doing I/O via a LOOKUP and READ/WRITE without an OPEN will > generally be allowed. It is up to the server to determine how it > interacts with other locking mechanisms and if it will allow > it in the face of an outstanding lock, be it mandatory or advisory. > The design encourages I/O operations that will not corrupt an > active lock, such as reading a read or write locked file but not > allowing a write to a file with any locks. But again, it is up to > the server to define the behavior. > > > 1. if we allow V4 read or write without open to a mandatory locking > > file, I assume that we get a share reservation for the duration of the > > read or write request. Is this correct? > > No, there are no "implicit" locks for any operation (this was hinted in > early drafts that just confused things). How the server allows > interaction from a client without an OPEN to one with a current share > resv is server defined. Some servers may never cause a request to be > denied, other may always. In general, share reservations are orthogonal(Continue reading)
Two personal draft were announced today (summaries are includede below). These arrived too late to be fully considered for tomorrow's interim meeting but there are agenda items already present related to these. Therefore, the I-Ds will not be fully considered but the topics on the agenda still hold. -- Spencer --------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mapping Between NFSv4 and Posix Draft ACLs Author(s) : M. Eriksen Filename : draft-eriksen-nfsv4-acl-02.txt Pages : 10 Date : 2003-6-2 The NFS (Network File System) version 4[rfc3530] (NFSv4) specifies a flavor of Access Control Lists (ACLs) that apply to file system objects. ACLs specify an access level for a number of entities. The NFSv4 ACLs model resembles that of Windows NT. A POSIX draft[posixacl] proposes another, more restrictive ACL model. Many systems implement this proposed standard. Differing in syntax, semantics and extensiveness, it is only feasible to create a correct representation for POSIX ACLs with NFSv4 ACLs. This does not hold for an attempt to represent arbitrary NFSv4 ACLs with POSIX ACLs. A URL for this Internet-Draft is:(Continue reading)
David Robinson worte: > Ronald E Bretschneider wrote: > > 1. I assume that NFS V4 does not preclude reads and writes without a > > preceeding open. I.e. a client could issue V4 lookup operation to determine > > a file handle and then use it with stateid of 0s or 1s to read or write. Is > > it correct to allow this behavior? Is this valid only to an advisory > > locking file? > Yes, and Maybe. Bottom line is that a server may reject any use > of all 0's or all 1's stateids for any reason. I don't see this in the spec anywhere. The spec leaves a lot of room for server semantics, but I don't see any special freedom for the all 0's or all 1's case. > But it is expected > that doing I/O via a LOOKUP and READ/WRITE without an OPEN will > generally be allowed. The spec is ambivalent about this issue. It says: To provide correct share semantics, a client MUST use the OPEN operation to obtain the initial filehandle and indicate the desired access and what if any access to deny. Even if the client intends to use a stateid of all 0's or all 1's, it must still obtain the filehandle for the regular file with the OPEN operation so the appropriate share semantics can be applied. On the other hand, if you are always going to do an OPEN, you have a stateid (other than all 0's) with which to do the IO so there is no(Continue reading)
On Tue, Jun 03, 2003 at 09:47:02AM -0500, Spencer Shepler wrote: > > Two personal draft were announced today (summaries are includede > below). These arrived too late to be fully considered for tomorrow's > interim meeting but there are agenda items already present related to > these. Therefore, the I-Ds will not be fully considered but the > topics on the agenda still hold. BTW, I submitted my draft last week (on Wednesday), but for some reason the I-D submission took four business days to be processed. Sigh. Nico -- -- _______________________________________________ nfsv4 mailing list nfsv4 <at> ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4
RSS Feed178 | |
|---|---|
81 | |
31 | |
24 | |
40 | |
16 | |
72 | |
174 | |
56 | |
57 | |
47 | |
99 | |
174 | |
50 | |
85 | |
130 | |
75 | |
43 | |
40 | |
121 | |
197 | |
139 | |
143 | |
146 | |
169 | |
264 | |
197 | |
63 | |
37 | |
45 | |
125 | |
273 | |
128 | |
53 | |
97 | |
118 | |
42 | |
77 | |
144 | |
14 | |
60 | |
89 | |
28 | |
108 | |
157 | |
123 | |
53 | |
46 | |
67 | |
309 | |
101 | |
45 | |
41 | |
88 | |
63 | |
66 | |
14 | |
60 | |
8 | |
65 | |
143 | |
97 | |
195 | |
148 | |
136 | |
192 | |
355 | |
77 | |
83 | |
47 | |
116 | |
97 | |
38 | |
99 | |
47 | |
65 | |
87 | |
76 | |
48 | |
46 | |
106 | |
282 | |
287 | |
196 | |
91 | |
86 | |
220 | |
136 | |
95 | |
47 | |
135 | |
103 | |
97 | |
185 | |
111 | |
40 | |
39 | |
69 | |
81 | |
55 | |
19 | |
106 | |
104 | |
30 | |
53 | |
55 | |
66 | |
94 | |
59 | |
59 | |
28 | |
52 | |
120 | |
110 | |
26 | |
82 | |
105 | |
52 | |
25 | |
54 | |
106 | |
15 | |
68 | |
74 | |
69 | |
166 | |
83 | |
40 | |
55 | |
147 | |
144 | |
72 | |
59 | |
62 |
