draft-ietf-nfsv4-directory-delegation-00.txt   draft-ietf-nfsv4-directory-delegation-01.txt 
skipping to change at page 1, line 43 skipping to change at page 1, line 43
ABSTRACT ABSTRACT
This document proposes adding directory delegations and notifications This document proposes adding directory delegations and notifications
to NFS Version 4 [RFC3530]. It is hoped that these changes will be to NFS Version 4 [RFC3530]. It is hoped that these changes will be
part of a new minor version of NFS, such as NFSv4.1. part of a new minor version of NFS, such as NFSv4.1.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Proposed protocol extensions. . . . . . . . . . . . . . . . . 3 2. Proposed protocol extensions. . . . . . . . . . . . . . . . . 3
3. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. New Operation 40: GET_DIR_DELEGATION - Get a directory 4. New Operation 40: GET_DIR_DELEGATION - Get a directory
delegation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 delegation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. New Recommended Attributes . . . . . . . . . . . . . . . . . . 7 5. New Recommended Attributes . . . . . . . . . . . . . . . . . . 8
6. New Callback Operation: CB_NOTIFY - Notify directory changes . 8 6. New Callback Operation: CB_NOTIFY - Notify directory changes . 9
7. Delegation Recall . . . . . . . . . . . . . . . . . . . . . 11 7. Delegation Recall . . . . . . . . . . . . . . . . . . . . . 12
8. New Callback Operation: CB_RECALL_ANY - Keep any N 8. New Callback Operation: CB_RECALL_ANY - Keep any N
delegations . . . . . . . . . . . . . . . . . . . . . . . . 11 delegations . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Delegation Recovery . . . . . . . . . . . . . . . . . . . . 12 9. Delegation Recovery . . . . . . . . . . . . . . . . . . . . 14
10. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Synchronous vs. Asynchronous notifications . . . . . . . 12 10.1. Synchronous vs. Asynchronous notifications . . . . . . . 14
11. RPC Definition File Changes . . . . . . . . . . . . . . . . 13 11. RPC Definition File Changes . . . . . . . . . . . . . . . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 23
14. Normative References . . . . . . . . . . . . . . . . . . . 22 14. Normative References . . . . . . . . . . . . . . . . . . . 23
15. Informative References . . . . . . . . . . . . . . . . . . 23 15. Informative References . . . . . . . . . . . . . . . . . . 24
16. Author's Address . . . . . . . . . . . . . . . . . . . . . 23 16. Author's Address . . . . . . . . . . . . . . . . . . . . . 24
17. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . 23 17. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . 24
18. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 23 18. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
This document assumes understanding of the NFSv4.0 specification. It This document assumes understanding of the NFSv4.0 specification. It
also assumes that the changes proposed by [talpey] will be present in also assumes that the changes proposed by [talpey] will be present in
the same minor version and that the protocol would need some the same minor version or certain incremental additions to this
adjustment in the event that the session changes are not present. proposal will be required, as discussed later in the document.
The major addition to NFS version 4 in the area of caching is the The major addition to NFS version 4 in the area of caching is the
ability of the server to delegate certain responsibilities to the ability of the server to delegate certain responsibilities to the
client. When the server grants a delegation for a file to a client, client. When the server grants a delegation for a file to a client,
the client receives certain semantic guarentees with respect to the the client receives certain semantics with respect to the sharing of
sharing of that file with other clients. At OPEN, the server may that file with other clients. At OPEN, the server may provide the
provide the client either a read or write delegation for the file. If client either a read or write delegation for the file. If the client
the client is granted a read delegation, it is assured that no other is granted a read delegation, it is assured that no other client has
client has the ability to write to the file for the duration of the the ability to write to the file for the duration of the delegation.
delegation. If the client is granted a write delegation, the client If the client is granted a write delegation, the client is assured
is assured that no other client has read or write access to the file. that no other client has read or write access to the file. This
This reduces network traffic by allowing the client to perform reduces network traffic and server load by allowing the client to
various operations locally on file data. perform certain operations on local file data and can also provide
stronger consistency for the local data.
Directory caching for the NFS version 4 protocol is similar to Directory caching for the NFS version 4 protocol is similar to
previous versions. Clients typically cache directory information for previous versions. Clients typically cache directory information for
a duration determined by the client. At the end of a predefined a duration determined by the client. At the end of a predefined
timeout, the client will query the server to see if the directory has timeout, the client will query the server to see if the directory has
been updated. By caching attributes, clients reduce the number of been updated. By caching attributes, clients reduce the number of
GETATTR calls made to the server to validate attributes. Furthermore, GETATTR calls made to the server to validate attributes. Furthermore,
frequently accessed files and directories, such as the current frequently accessed files and directories, such as the current
working directory, have their attributes cached on the client so that working directory, have their attributes cached on the client so that
some NFS operations can be performed without having to make an RPC some NFS operations can be performed without having to make an RPC
call. By caching name and inode information about most recently call. By caching name and inode information about most recently
looked up entries in DNLC (Directory Name Lookup Cache), clients do looked up entries in DNLC (Directory Name Lookup Cache), clients do
not need to send LOOKUP calls to the server every time these files not need to send LOOKUP calls to the server every time these files
are accessed. are accessed.
This caching approach works reasonably well at reducing network
traffic in many environments. However, it does not address
environments where there are numerous queries for files that do not
exist. In these cases of "misses", the client must make RPC calls to
the server in order to provide reasonable application semantics and
promptly detect the creation of new directory entries. Examples of
high miss activity are compilation in software development
environments. The current behavior of NFS limits its potential
scalability and wide-area sharing effectiveness in these types of
environments. Other distributed stateful filesystem architectures
such as AFS and DFS have proven that adding state around directory
contents can greatly reduce network traffic in high miss
environments.
Delegation of directory contents is proposed as an extension for Delegation of directory contents is proposed as an extension for
NFSv4. Such an extension would provide similar traffic reduction NFSv4. Such an extension would provide similar traffic reduction
benefits as with file delegations. By allowing clients to cache benefits as with file delegations. By allowing clients to cache
directory contents (in a read-only fashion) while being notified of directory contents (in a read-only fashion) while being notified of
changes, the client can avoid making frequent requests to interrogate changes, the client can avoid making frequent requests to interrogate
the contents of slowly-changing directories, reducing network traffic the contents of slowly-changing directories, reducing network traffic
and improving client performance. and improving client performance.
These extensions allow improved namespace cache consistency to be
achieved through delegations and synchronous recalls alone without
asking for notifications. In addition, if time-based consistency is
sufficient, asynchronous notifications can provide performance
benefits for the client, and possibly the server, under some common
operating conditions such as slowly-changing and/or very large
directories.
2. Proposed protocol extensions. 2. Proposed protocol extensions.
This document includes the definition of protocol extensions to This document includes the definition of protocol extensions to
implement directory delegations. It is believed that these extension implement directory delegations. It is believed that these extension
fit within the minor-versioning framework presented in RFC3530, fit within the minor-versioning framework presented in RFC3530.
although careful review on this point needs to be undertaken. As
stated above, these extensions are designed supposing that the The NFSv4 Sessions Extensions [talpey] include a new operation
session extensions [talpey] will be present in the same minor (called SEQUENCE) in each COMPOUND procedure which carries the
version, as currently seems likely. Some modifications will be clientid associated with the session to which the procedure belongs.
necessary, if that turns out not to be the case. In NFSv4.0, only certain COMPOUND procedures may carry such a
clientid. When present, this clientid provides all the necessary
context for maintaining directory delegations, and dispatching
appropriate callbacks.
If the directory delegation protocol described here is not able to
leverage any pre-existing clientid present in each COMPOUND request,
then the equivalent clientid must be provided where necessary. This
could be accomplished by simply including the SEQUENCE operation in
each compound of the new minor version, regardless of the status of
any session.
Mainly in the interests of clarity of presentation, elements within Mainly in the interests of clarity of presentation, elements within
these extensions are assigned numeric identifiers such as operation these extensions are assigned numeric identifiers such as operation
numbers and attribute identitifies. It should be understood that numbers and attribute identifiers. It should be understood that when
when these extensions are included in a minor version of NFSv4, the these extensions are included in a minor version of NFSv4, the actual
actual numeric identifiers assigned may be different from the ones numeric identifiers assigned may be different from the ones chosen
chosen here. here.
3. Design 3. Design
A client gets a directory delegation by use of a new operation A new operation GET_DIR_DELEGATION is used by the client to ask for a
(GET_DIR_DELEGATION) and also informs the server if it wants to be directory delegation. The delegation covers directory attributes and
notified of any changes that are made to the directory. If the server all entries in the directory. If either of these change the
is unable to notify the client of some set of changes, it should delegation will be recalled synchronously. The operation causing the
inform the client of its inability to do so. The server will send recall will have to wait before the recall is complete. Any changes
notifications for all change events it has agreed to. Because true to directory entry attributes will not cause the delegation to be
synchronous notification poses significant server implementation recalled.
difficulties, the document describes just an asynchronous approach.
The clients are notified of changes to the directory only after the
change has been processed by the server. See the section "Synchronous
vs. Asynchronous notifications" for a discussion on different types
of notifications and the reason for choosing asynchronous
notifications. The delegation is read only and the client may not
make changes to the directory other than by performing NFSv4
operations that modify the directory or the associated file
attributes so that the server has knowledge of these changes. If a
client holding the delegation makes any changes to the directory, it
will not be notified and the delegation will not be recalled. The
client making changes is presumed not to need notifications of
changes that it itself is making.
Delegations can be recalled by the server. The server is free to In addition to asking for delegations, a client can also ask for
recall the delegation at any time. Normally, the server will recall notifications for certain events. These events include changes to
the delegation when the directory changes in a way that is not directory attributes and/or its contents. If a client asks for
covered by the notification, or when there is a directory change and notification for a certain event, the server will notify the client
notifications have not been requested. when that event occurs. This will not result in the delegation being
recalled for that client. The notifications are asynchronous and
provide a way of avoiding recalls in situations where a directory is
changing enough that the pure recall model may not be effective while
trying to allow the client to get substantial benefit. In the absence
of notifications, once the delegation is recalled the client has to
refresh its directory cache which might not be very efficient for
very large directories.
The delegation is read only and the client may not make changes to
the directory other than by performing NFSv4 operations that modify
the directory or the associated file attributes so that the server
has knowledge of these changes. In order to keep the client namespace
in sync with the server, the server will notify the client holding
the delegation of the changes made as a result. This is to avoid any
subsequent GETATTR or READDIR calls to the server. If a client
holding the delegation makes any changes to the directory, the
delegation will not be recalled.
Delegations can be recalled by the server at any time. Normally, the
server will recall the delegation when the directory changes in a way
that is not covered by the notification, or when the directory
changes and notifications have not been requested.
Also if the server notices that handing out a delegation for a Also if the server notices that handing out a delegation for a
directory is causing too many notifications to be sent out, it may directory is causing too many notifications to be sent out, it may
decide not to hand out a delegation for that directory or recall decide not to hand out a delegation for that directory or recall
existing delegations. If another client removes the directory for existing delegations. If another client removes the directory for
which a delegation has been granted, the server will recall the which a delegation has been granted, the server will recall the
delegation. delegation.
Both the notification and recall operations need a callback path to Both the notification and recall operations need a callback path to
exist between the client and server. If the callback path does not exist between the client and server. If the callback path does not
exist, then delegations should not be granted. Note that with the exist, then delegation can not be granted. Note that with the session
session extensions [talpey] that should not be an issue. extensions [talpey] that should not be an issue. In the absense of
sessions, the server will have to establish a callback path to the
client to send callbacks.
4. New Operation 40: GET_DIR_DELEGATION - Get a directory delegation 4. New Operation 40: GET_DIR_DELEGATION - Get a directory delegation
SYNOPSIS SYNOPSIS
(cfh), requested notification -> (cfh), cookieverf, stateid, (cfh), requested notification -> (cfh), cookieverf, stateid,
supported notification supported notification
ARGUMENT ARGUMENT
struct GET_DIR_DELEGATION4args { struct GET_DIR_DELEGATION4args {
dir_notification_type4 notification_type; dir_notification_type4 notification_type;
attr_notice file_attr_notice; attr_notice4 child_attr_delay;
attr_notice dir_attr_notice; attr_notice4 dir_attr_delay;
}; };
/* /*
* Notification types. * Notification types.
*/ */
const DIR_NOTIFICATION_NONE = 0x00000000; const DIR_NOTIFICATION_NONE = 0x00000000;
const DIR_NOTIFICATION_CHANGE_FILE_ATTRIBUTES = 0x00000001; const DIR_NOTIFICATION_CHANGE_CHILD_ATTRIBUTES = 0x00000001;
const DIR_NOTIFICATION_CHANGE_DIR_ATTRIBUTES = 0x00000002; const DIR_NOTIFICATION_CHANGE_DIR_ATTRIBUTES = 0x00000002;
const DIR_NOTIFICATION_REMOVE_ENTRY = 0x00000004; const DIR_NOTIFICATION_REMOVE_ENTRY = 0x00000004;
const DIR_NOTIFICATION_ADD_ENTRY = 0x00000008; const DIR_NOTIFICATION_ADD_ENTRY = 0x00000008;
const DIR_NOTIFICATION_RENAME_ENTRY = 0x00000010; const DIR_NOTIFICATION_RENAME_ENTRY = 0x00000010;
const DIR_NOTIFICATION_CHANGE_COOKIE_VERIFIER = 0x00000020; const DIR_NOTIFICATION_CHANGE_COOKIE_VERIFIER = 0x00000020;
typedef uint32_t dir_notification_type4; typedef uint32_t dir_notification_type4;
typedef nfstime4 attr_notice4;
RESULT RESULT
struct GET_DIR_DELEGATION4resok { struct GET_DIR_DELEGATION4resok {
verifier4 cookieverf; verifier4 cookieverf;
/* Stateid for get_dir_delegation */ /* Stateid for get_dir_delegation */
stateid4 stateid; stateid4 stateid;
/* Which notifications can the server support */ /* Which notifications can the server support */
dir_notification_type4 supp_notification; dir_notification_type4 supp_notification;
fattr4 file_attributes; bitmap4 child_attributes;
fattr4 dir_attributes; bitmap4 dir_attributes;
};
struct attr_notice {
bitmap4 attr_notice_req;
uint32_t attr_notice_delays<>;
}; };
union GET_DIR_DELEGATION4res switch (nfsstat4 status) { union GET_DIR_DELEGATION4res switch (nfsstat4 status) {
case NFS4_OK: case NFS4_OK:
/* CURRENT_FH: delegated dir */ /* CURRENT_FH: delegated dir */
GET_DIR_DELEGATION4resok resok4; GET_DIR_DELEGATION4resok resok4;
default: default:
void; void;
}; };
DESCRIPTION: DESCRIPTION:
The GET_DIR_DELEGATION operation is used by the client to The GET_DIR_DELEGATION operation is used by a client to request
request a directory delegation. The directory is represented by a directory delegation. The directory is represented by the
the current filehandle. The client also specifies whether it current filehandle. The client also specifies whether it wants
wants the server to notify it when the directory changes in the server to notify it when the directory changes in certain
certain ways by setting bits in a bitmap. The server may choose ways by setting one or more bits in a bitmap. The server may
not to grant the delegation. In that case the server will return also choose not to grant the delegation. In that case the server
NFS4ERR_DIRDELEG_UNAVAIL. If the server decides to hand out the will return NFS4ERR_DIRDELEG_UNAVAIL. If the server decides to
delegation, it will return a cookie verifier for that directory. hand out the delegation, it will return a cookie verifier for
If the cookie verifier changes when the client is holding the that directory. If the cookie verifier changes when the client
delegation, it will be notified about the change, provided the is holding the delegation, the delegation will be recalled
client has asked for the notification. Otherwise, the delegation unless the client has asked for notification for this event. In
will be recalled. that case a notification will be sent to the client.
The server will also return a directory delegation stateid in The server will also return a directory delegation stateid in
addition to the cookie verifier as a result of the addition to the cookie verifier as a result of the
GET_DIR_DELEGATION operation. This stateid will appear in GET_DIR_DELEGATION operation. This stateid will appear in
callback messages related to the delegation, such as callback messages related to the delegation, such as
notifications and delegation recalls. The client will use this notifications and delegation recalls. The client will use this
stateid to return the delegation voluntarily or upon recall. stateid to return the delegation voluntarily or upon recall. A
Delegation is returned by calling the DELEGRETURN operation. delegation is returned by calling the DELEGRETURN operation.
The server may not be able to support notifications of certain The server may not be able to support notifications of certain
events. If the client asks for such notifications, the server events. If the client asks for such notifications, the server
must inform the client of its inability to do so as part of the must inform the client of its inability to do so as part of the
GET_DIR_DELEGATION reply. GET_DIR_DELEGATION reply by not setting the appropriate bits in
the supported notifications bitmask contained in the reply.
The GET_DIR_DELEGATION operation can be used for both normal and The GET_DIR_DELEGATION operation can be used for both normal and
named attribute directories. named attribute directories. It covers all the entries in the
directory except the ".." entry. That means if a directory and
its parent both hold directory delegations, any changes to the
parent will not cause a notification to be sent for the child
even though the child's ".." entry points to the parent.
IMPLEMENTATION: IMPLEMENTATION:
Directory delegation provides the benefit of improving cache
consistency of namespace information. This is done through
synchronous callbacks. A server must support synchronous
callbacks in order to support directory delegations. In addition
to that, asynchronous notifications provide a way to reduce
network traffic as well as improve client performance in certain
conditions. Notifications would not be requested when the goal
is just cache consitency.
Notifications are specified in terms of potential changes to the Notifications are specified in terms of potential changes to the
directory. A client can ask to be notified whenever an entry is directory. A client can ask to be notified whenever an entry is
added to a directory by setting notification_type to added to a directory by setting notification_type to
DIR_NOTIFICATION_ADD_ENTRY. It can also ask for notifications on DIR_NOTIFICATION_ADD_ENTRY. It can also ask for notifications on
entry removal, renames, attribute and cookie verifier changes by entry removal, renames, directory attribute changes and cookie
setting notification_type flag appropriately . A client can also verifier changes by setting notification_type flag
ask to be notified of all events that would invalidate its appropriately. In addition to that, the client can also ask for
attribute cache. In that case it will set the notification_type notifications upon attribute changes to children in the
to D IR_NOTIFICATION_CHANGE_FILE_ATTRIBUTES and directory to keep its attribute cache up to date. However any
DIR_NOTIFICATION_CHANGE_DIR_ATTRIBUTES. The server will then changes made to child attributes do not cause the delegation to
noti fy it of any file or directory attribute changes. If a be recalled. If a client is interested in directory entry
client is interested in directory entry caching, or negative caching, or negative name caching, it can set the
name caching, it can set the notification_type appropriately and notification_type appropriately and the server will notify it of
the server will notify it of all changes that would otherwise all changes that would otherwise invalidate its name cache. The
invalidate its name cache. kind of notification a client asks for may depend on the
directory size, its rate of change and the applications being
used to access that directory. However, the conditions under
which a client might ask for a notification, is out of the scope
of this specification.
The client will set one or more bits in a bitmap to let the The client will set one or more bits in a bitmap
server know what kind of notification(s) it is interested in (notification_type) to let the server know what kind of
getting. For attribute caching the client registers interest in notification(s) it is interested in. For attribute notifications
getting notifications for certain attributes by setting file and it will set bits in another bitmap to indicate which attributes
directory attributes in file_attr_notice and dir_attr_notice it wants to be notified of. If the server does not support
arguments. One of the bitmaps covers directory attributes notifications for changes to a certain attribute, it should not
changes and the other covers changes to any files in the set that attribute in the supported attribute bitmap
directory. The client will also specify the frequency of (supp_notification) specified in the reply.
notifications for each attribute change by setting the delay in
file_attr_notice and dir_attr_notice arguments. The server can
choose to support notificati ons on only a subset of attributes.
The server will deny the request if it does not support
notifications on that attribute or the requested frequency. If
the client wants notifications for all changes, it will set the
time delay to zero indicating it wants to be notified as soon as
the change occurs. For other types of notifications, the client
does not need to provide the server with this additional
information. So in these cases the attribute masks for file and
directory will not be set.
The server will set a bitmap to inform the client of which In addition to that, the client will also let the server know if
notifications the server can support. If it agrees to send it wants to get the notification as soon as the attribute change
attribute notifications, it will also set two attribute masks occurs or after a certain delay by setting a delay factor,
indicating which attribute change notifications it supports. One child_attr_delay for attribute changes to children and
of the masks covers changes in directory attributes and the dir_attr_delay for attribute changes to the directory. If this
other covers atttribute changes to any files in the directory. delay factor is set to zero, that indicates to the server that
the client wants to be notified of any attribute changes as soon
as they occur. If the delay factor is set to N, the server will
make a best effort guarantee that attribute updates are not out
of sync by more than that. One value covers all attribute
changes for the directory and another value covers all attribute
changes for all children in the directory. If the client asks
for a delay factor that the server does not support or that may
cause significant resource consumption on the server by causing
the server to send a lot of notifications, the server should not
commit to sending out notifications for that attribute and
therefore must not set the approprite bit in the
child_attributes and dir_attributes bitmaps in the response.
The server will let the client know about which notifications it
can support by setting appropriate bits in a bitmap. If it
agrees to send attribute notifications, it will also set two
attribute masks indicating which attributes it will send change
notifications for. One of the masks covers changes in directory
attributes and the other covers atttribute changes to any files
in the directory.
The client should use a security flavor that the filesystem is
exported with. If it uses a different flavor, the server should
return NFS4ERR_WRONGSEC.
ERRORS ERRORS
NFS4ERR_ACCESS NFS4ERR_ACCESS
NFS4ERR_BADHANDLE NFS4ERR_BADHANDLE
NFS4ERR_BADCHAR
NFS4ERR_BADNAME
NFS4ERR_BADXDR NFS4ERR_BADXDR
NFS4ERR_FHEXPIRED NFS4ERR_FHEXPIRED
NFS4ERR_INVAL NFS4ERR_INVAL
NFS4ERR_MOVED NFS4ERR_MOVED
NFS4ERR_NAMETOOLONG
NFS4ERR_NOENT
NFS4ERR_NOFILEHANDLE NFS4ERR_NOFILEHANDLE
NFS4ERR_NOTDIR NFS4ERR_NOTDIR
NFS4ERR_RESOURCE NFS4ERR_RESOURCE
NFS4ERR_SERVERFAULT NFS4ERR_SERVERFAULT
NFS4ERR_STALE NFS4ERR_STALE
NFS4ERR_DIRDELEG_UNAVAIL NFS4ERR_DIRDELEG_UNAVAIL
NFS4ERR_DIRDELEG_DENIED NFS4ERR_WRONGSEC
NFS4ERR_EIO
NFS4ERR_NOTSUPP
5. New Recommended Attributes 5. New Recommended Attributes
#56 - supp_dir_attr_notice - Range of notification delays on #56 - supp_dir_attr_notice - notification delays on directory
directory attributes attributes
#57 - supp_file_attr_notice - Range of notification delays on file #57 - supp_child_attr_notice - notification delays on child
attributes attributes
DESCRIPTION: DESCRIPTION:
These attributes allow the client and server to negotiate the These attributes allow the client and server to negotiate the
frequency of notifications sent due to changes in attributes. frequency of notifications sent due to changes in attributes.
The server returns these attributes for every attribute that it These attributes are returned as part of a GETATTR call on the
supports. Each has a range of supported notification delay for directory. The supp_dir_attr_notice value covers all attribute
every attribute. If the server does not support notifications on changes to the directory and the supp_child_attr_notice covers
a certain attribute, it must indicate that by not setting these all attribute changes to any child in the directory.
attributes.
These attributes are per filesystem attributes. The client need
only get the values when it encounters a new fsid during
navigation of the server's namespace.
The client gets this information when it does a GETATTR on a These attributes are per directory. The client needs to get
directory. The server will return supp_dir_attr_notice on every these values by doing a GETATTR on the directory for which it
directory attribute giving a range of notification frequencies. wants notifications. However these attributes are only required
It is possible that the server does not support or supports when the client is interested in getting attribute
different ranges for file attributes. The server will set notifications. For all other types of notifications and
supp_file_attr_notice to indicate the range of notification delegation requests without notifications, these attributes are
frequencies for file attribute changes. One value covers all not required.
files in the directory. e.g. A server can choose to support
notifications for mtime updates between 0 to 5 seconds. If the
client specifies a time delay of 3 seconds, the server will
guarentee that mtime updates are not out of sync by more than 3
seconds. For file changes, the server will provide the same
guarentee for any mtime change on any file in the directory.
When the client calls the GET_DIR_DELEGATION operation and asks When the client calls the GET_DIR_DELEGATION operation and asks
for attribute change notifications, it will request a for attribute change notifications, it will request a
notification time that is within the supported server range. If notification delay that is within the server's supported range.
the client violates what supp_attr_file_notice or If the client violates what supp_attr_file_notice or
supp_attr_dir_notice values are, GET_DIR_DELEGATION fails with supp_attr_dir_notice values are, the server should not commit to
NFS4ERR_DIRDELEG_DENIED. sending notifications for that change event.
A value of zero for these attributes means the server will send
the notification as soon as the change occurs. It is not
recommended to set this value to zero since that can put a lot
of burden on the server. A value of N means that the server
will make a best effort guarentee that attribute notification
are not delayed by more than that. nfstime4 values that compute
to negative values are illegal.
6. New Callback Operation: CB_NOTIFY - Notify directory changes 6. New Callback Operation: CB_NOTIFY - Notify directory changes
SYNOPSIS SYNOPSIS
stateid, notification -> {} stateid, notification -> {}
ARGUMENT ARGUMENT
struct CB_NOTIFY4args { struct CB_NOTIFY4args {
stateid4 stateid; stateid4 stateid;
dir_notification4 changes<>; dir_notification4 changes<>;
}; };
/* /*
* Notification information sent to the client. * Notification information sent to the client.
*/ */
union dir_notification4 union dir_notification4
switch (dir_notification_type4 notification_type) { switch (dir_notification_type4 notification_type) {
case DIR_NOTIFICATION_CHANGE_FILE_ATTRIBUTE: case DIR_NOTIFICATION_CHANGE_CHILD_ATTRIBUTES:
dir_notification_attribute4 change_file_attributes; dir_notification_attribute4 change_child_attributes;
case DIR_NOTIFICATION_CHANGE_DIR_ATTRIBUTE: case DIR_NOTIFICATION_CHANGE_DIR_ATTRIBUTES:
fattr4 change_dir_attributes; fattr4 change_dir_attributes;
case DIR_NOTIFICATION_REMOVE_ENTRY: case DIR_NOTIFICATION_REMOVE_ENTRY:
dir_notification_remove4 remove_notification; dir_notification_remove4 remove_notification;
case DIR_NOTIFICATION_ADD_ENTRY: case DIR_NOTIFICATION_ADD_ENTRY:
dir_notification_add4 add_notification; dir_notification_add4 add_notification;
case DIR_NOTIFICATION_RENAME_ENTRY: case DIR_NOTIFICATION_RENAME_ENTRY:
dir_notification_rename4 rename_notification; dir_notification_rename4 rename_notification;
case DIR_NOTIFICATION_CHANGE_COOKIE_VERIFIER: case DIR_NOTIFICATION_CHANGE_COOKIE_VERIFIER:
dir_notification_verifier4 verf_notification; dir_notification_verifier4 verf_notification;
}; };
/*
* Changed entry information.
*/
struct dir_entry {
component4 file;
fattr4 attrs;
};
struct dir_notification_attribute4 { struct dir_notification_attribute4 {
dir_entry changed_entry; dir_entry changed_entry;
fattr4 change_dir_attributes;
}; };
struct dir_notification_remove4 { struct dir_notification_remove4 {
dir_entry old_entry; dir_entry old_entry;
nfs_cookie4 old_entry_cookie; nfs_cookie4 old_entry_cookie;
}; };
struct dir_notification_rename4 { struct dir_notification_rename4 {
dir_entry old_entry; dir_entry old_entry;
dir_notification_add4 new_entry; dir_notification_add4 new_entry;
}; };
struct dir_notification_verifier4 { struct dir_notification_verifier4 {
verifier4 old_cookieverf; verifier4 old_cookieverf;
verifier4 new_cookieverf; verifier4 new_cookieverf;
}; };
skipping to change at page 9, line 19 skipping to change at page 10, line 46
struct dir_notification_verifier4 { struct dir_notification_verifier4 {
verifier4 old_cookieverf; verifier4 old_cookieverf;
verifier4 new_cookieverf; verifier4 new_cookieverf;
}; };
struct dir_notification_add4 { struct dir_notification_add4 {
dir_entry new_entry; dir_entry new_entry;
/* what READDIR would have returned for this entry */ /* what READDIR would have returned for this entry */
nfs_cookie4 new_entry_cookie; nfs_cookie4 new_entry_cookie;
bool last_entry; bool last_entry;
prev_entry4 prev_entry_info; prev_entry_info4 prev_info;
}; };
union prev_entry4 switch (bool isprev) { union prev_entry_info4 switch (bool isprev) {
case TRUE: /* A previous entry exists */ case TRUE: /* A previous entry exists */
prev_entry4 prev_entry_info; prev_entry4 prev_entry_info;
case FALSE: /* we are adding to an empty case FALSE: /* we are adding to an empty
directory */ directory */
void; void;
}; };
/* /*
* Previous entry information * Previous entry information
*/ */
struct prev_entry4 { struct prev_entry4 {
dir_entry prev_entry; dir_entry prev_entry;
/* what READDIR returned for this entry */ /* what READDIR returned for this entry */
nfs_cookie4 prev_entry_cookie; nfs_cookie4 prev_entry_cookie;
}
/*
* Changed entry information.
*/
struct dir_entry {
component4 file;
fattr4 attrs;
}; };
RESULT RESULT
struct CB_NOTIFY4res { struct CB_NOTIFY4res {
nfsstat4 status; nfsstat4 status;
}; };
DESCRIPTION: DESCRIPTION:
The CB_NOTIFY operation is used by the server to send The CB_NOTIFY operation is used by the server to send
notifications to clients about changes in a delegated directory. notifications to clients about changes in a delegated directory.
These notifications are sent over the callback path. The These notifications are sent over the callback path. The
notification is sent once the original request has been notification is sent once the original request has been
processed on the server. The server will send an array of processed on the server. The server will send an array of
notifications for all changes that might have occured in the notifications for all changes that might have occurred in the
directory. It will send the following information for each directory. The dir_notification_type4 can only have one bit set
operation: for each notification in the array. If the client holding the
delegation makes any changes in the directory that cause files
or sub directories to be added or removed, the server will
notify that client of the resulting change(s). If the client
holding the delegation is making attribute or cookie verifier
changes only, the server does not need to send notifications to
that client. The server will send the following information for
each operation:
o ADDING A FILE: The server sends information about the new o ADDING A FILE: The server will send information about the
entry being created along with the cookie for that entry. The new entry being created along with the cookie for that entry.
entry information contains the nfs name of the entry and The entry information contains the nfs name of the entry and
attributes. If this entry is added to the end of the attributes. If this entry is added to the end of the
directory, the server will set a last_entry flag to true. If directory, the server will set a last_entry flag to true. If
the file is added such that there is atleast one entry before the file is added such that there is atleast one entry before
it, the server will also return the previous entry it, the server will also return the previous entry
information along with its cookie. This is to help clients information along with its cookie. This is to help clients
find the right location in their DNLC or directory caches find the right location in their DNLC or directory caches
where this entry should be cached. where this entry should be cached.
o REMOVING A FILE: The server sends information about the o REMOVING A FILE: The server will send information about the
directory entry being deleted. The server also sends the directory entry being deleted. The server will also send the
cookie value for the deleted entry so that clients can get to cookie value for the deleted entry so that clients can get to
the cached information for this entry. the cached information for this entry.
o RENAMING A FILE: The server sends information about both the o RENAMING A FILE: The server will send information about both
old entry and the new entry. This includes name and the old entry and the new entry. This includes name and
attributes for each entry. This notification is only sent if attributes for each entry. This notification is only sent if
both entries are in the same directory. If the rename is both entries are in the same directory. If the rename is
across directories, the server will send a remove across directories, the server will send a remove
notification to one directory and an add notification to the notification to one directory and an add notification to the
other directory, assuming both have a directory delegation. other directory, assuming both have a directory delegation.
o FILE/DIR ATTRIBUTE CHANGE: The client uses the attribute o FILE/DIR ATTRIBUTE CHANGE: The client will use the attribute
mask to inform the server of attributes for which it wants to mask to inform the server of attributes for which it wants to
receive notifications. This change notification can be receive notifications. This change notification can be
requested for both changes to the attributes of the directory requested for both changes to the attributes of the directory
as well as changes to any files in the directory by using two as well as changes to any file attributes in the directory by
separate attribute masks. The client can not ask for change using two separate attribute masks. The client can not ask
attribute notification per file. One attribute mask covers for change attribute notification per file. One attribute
all the files in the directory. Upon any attribute change, mask covers all the files in the directory. Upon any
the server will send back the values of changed attributes. attribute change, the server will send back the values of
If the client asks for change attributes on files, the server changed attributes. Notifications might not make sense for
will send back the change notification for both files and some filesystem wide attributes and it is up to the server to
directory. Notifications might not make sense for some
filesystem wide attributes and it is up to the server to
decide which subset it wants to support. The client can decide which subset it wants to support. The client can
negotiate the frequency of attribute notifications by letting negotiate the frequency of attribute notifications by letting
the server know how often it wants to be notified of an the server know how often it wants to be notified of an
attribute change. The server will return a range of supported attribute change. The server will return supported
notification frequencies or an indication that no notification frequencies or an indication that no
notification is permitted for every attribute by setting the notification is permitted for directory or child attributes
supp_attr_file_notice and supp_attr_dir_notice attributes. by setting the supp_dir_attr_notice and
supp_child_attr_notice attributes respectively.
o COOKIE VERIFIER CHANGE: If the cookie verifier changes while o COOKIE VERIFIER CHANGE: If the cookie verifier changes while
a client is holding a delegation, the server will notify the a client is holding a delegation, the server will notify the
client so that it can invalidate its cookies and reissue a client so that it can invalidate its cookies and reissue a
READDIR to get the new set of cookies. READDIR to get the new set of cookies.
ERRORS ERRORS
NFS4ERR_BAD_STATEID NFS4ERR_BAD_STATEID
NFS4ERR_INVAL NFS4ERR_INVAL
NFS4ERR_BADXDR NFS4ERR_BADXDR
NFS4ERR_SERVERFAULT
7. Delegation Recall 7. Delegation Recall
The server will recall the directory delegation by sending a callback The server will recall the directory delegation by sending a callback
to the client. It will use the same callback procedure as used for to the client. It will use the same callback procedure as used for
recalling file delegations. The server will recall the delegation recalling file delegations. The server will recall the delegation
when the directory changes in a way that is not covered by the when the directory changes in a way that is not covered by the
notification. Also if the server notices that handing out a notification. However the server will not recall the delegation if
delegation for a directory is causing too many notifications to be attributes of an entry within the directory change. Also if the
sent out, it may decide not to hand out a delegation for that server notices that handing out a delegation for a directory is
directory. If another client tries to remove the directory for which causing too many notifications to be sent out, it may decide not to
a delegation has been granted, the server may recall the delegation. hand out a delegation for that directory. If another client tries to
remove the directory for which a delegation has been granted, the
server will recall the delegation.
The server will recall the delegation by sending a CB_RECALL callback The server will recall the delegation by sending a CB_RECALL callback
to the client and if the delegation is being recalled due to a change to the client. If the recall is done because of a directory changing
being made to the directory that is not covered by the notification, event, the request making that change will need to wait while the
the request making that change may need to wait while the client client returns the delegation.
returns the delegation.
8. New Callback Operation: CB_RECALL_ANY - Keep any N delegations 8. New Callback Operation: CB_RECALL_ANY - Keep any N delegations
SYNOPSIS SYNOPSIS
N -> {} N -> {}
ARGUMENT ARGUMENT
struct CB_RECALLANYY4args { struct CB_RECALLANYY4args {
uint4 dlgs_to_keep; uint4 dlgs_to_keep;
} }
skipping to change at page 12, line 22 skipping to change at page 13, line 48
reclaiming frequently used delegations. In that case the server reclaiming frequently used delegations. In that case the server
may issue a CB_RECALL_ANY callback to the client asking it to may issue a CB_RECALL_ANY callback to the client asking it to
keep N delegations and return the rest. The reason why keep N delegations and return the rest. The reason why
CB_RECALL_ANY specifies a count of delegations the client may CB_RECALL_ANY specifies a count of delegations the client may
keep as opposed to a count of delegations the client must yield keep as opposed to a count of delegations the client must yield
is as follows. Were it otherwise, there is a potential for a is as follows. Were it otherwise, there is a potential for a
race between a CB_RECALL_ANY that had a count of delegations to race between a CB_RECALL_ANY that had a count of delegations to
free with a set of client originated operations to return free with a set of client originated operations to return
delegations. As a result of the race the client and server would delegations. As a result of the race the client and server would
have differing ideas as to how many delegations to return. Hence have differing ideas as to how many delegations to return. Hence
the client could mistakenly free too many delegations. the client could mistakenly free too many delegations. This
operation applies to delegations for a regular file (read or
write) as well as for a directory.
The client can choose to return any type of delegation as a The client can choose to return any type of delegation as a
result of this callback i.e. read, write or directory result of this callback i.e. read, write or directory
delegation. The client can also choose to keep more delegations delegation. The client can also choose to keep more delegations
than what the server asked for and it is up to the server to than what the server asked for and it is up to the server to
handle this situation. The server must give the client enough handle this situation. The server must give the client enough
time to return the delegations. This time should not be less time to return the delegations. This time should not be less
than the lease period. than the lease period.
ERRORS ERRORS
NFS4ERR_RESOURCE NFS4ERR_RESOURCE
9. Delegation Recovery 9. Delegation Recovery
Since the mode of notifications proposed in this draft is Crash recovery has two main goals, avoiding the necessity of breaking
asynchronous in nature, and since the primary use of directory application guarantees with respect to locked files and delivery of
delegations is anticipated to be in the conjunction with updates cached at the client. Neither of these applies to
notifications, adding reclaim functionality will add unnecessary directories protected by read delegations and notifications. Thus,
implementation complexity. Thus, the client is required to establish the client is required to establish a new delegation on a server or
a new delegation on a server or client reboot. client reboot.
10. Issues 10. Issues
10.1. Synchronous vs. Asynchronous notifications 10.1. Synchronous vs. Asynchronous notifications
An async notification would be sent to a client holding the Asynchronous notifications are defined as a way of updating namespace
delegation after a directory changing event has taken place. It is information for directories. For example, for directories that are
possible that the client holding the delegation tries to act on the very large or changing very slowly, the recall and subsequent
change before it has been notified by the server and fails. It would reacquiring of state may be too expensive. In that case if used
certainly be better if the notification was synchronous so that when properly notifications can reduce the overhead of recalling
the client tried to access, e.g. a newly created file, it was delegations and re-fetching directory contents with a reduction in
guaranteed to be there. network traffic.
For one form of synchronous notification, the server would suspend
the request and send a notification to the client notifying it of the
change about to occur. However this is not a true synchronous
notification, since after the server has sent out the notification,
it might discover that due to some error the request cannot be
completed. If this is for a regular file create, the client might add
this information to its directory cache and return bogus positive
information as a result of a readdir call. This puts the client in a
worse situation than with async notifications where the change is
guaranteed to be available but a delay may be involved.
For another form of synchronous notification, the server would notify
a client holding the delegation about a change about to occur in a
directory, only after the server has determined that this request is
definitely going to succeed. At that time, the server would send a
notification to the client holding the delegation while suspending
the original request. However note that the server has not yet
committed the change so at this point in time, only the client
holding the delegation knows about this change. Once the client
acknowledges the notification, the server will commit the change
making it visible to all other clients. It is doubtful many operating
environments would allow a server to provide this form of
notification.
Since synchronous notifications do not guarentee true request For achieving namespace cache consistency with lower network traffic,
ordering any better than asynchronous notifications except by adding delegations along with synchronous callbacks are sufficient. Adding
substantial implementation complexity, asynchronous notifications are synchronous notifications on top of that does not provide much
proposed as the default method for notifying the client. These additional benefits.
notifications will be sent after the directory changing operation has
completed.
11. RPC Definition File Changes 11. RPC Definition File Changes
/* /*
* Copyright (C) The Internet Society (2003) * Copyright (C) The Internet Society (2003)
* All Rights Reserved. * All Rights Reserved.
*/ */
/* /*
* nfs41_prot.x * nfs41_prot.x
skipping to change at page 14, line 16 skipping to change at page 15, line 18
/* /*
* Notification mask for letting the server know which notifications * Notification mask for letting the server know which notifications
* the client is interested in. * the client is interested in.
*/ */
typedef uint32_t dir_notification_type4; typedef uint32_t dir_notification_type4;
/* /*
* The bitmask constants used for notification_type field * The bitmask constants used for notification_type field
*/ */
const DIR_NOTIFICATION_NONE = 0x00000000; const DIR_NOTIFICATION_NONE = 0x00000000;
const DIR_NOTIFICATION_CHANGE_FILE_ATTRIBUTES = 0x00000001; const DIR_NOTIFICATION_CHANGE_CHILD_ATTRIBUTES = 0x00000001;
const DIR_NOTIFICATION_CHANGE_DIR_ATTRIBUTES = 0x00000002; const DIR_NOTIFICATION_CHANGE_DIR_ATTRIBUTES = 0x00000002;
const DIR_NOTIFICATION_REMOVE_ENTRY = 0x00000004; const DIR_NOTIFICATION_REMOVE_ENTRY = 0x00000004;
const DIR_NOTIFICATION_ADD_ENTRY = 0x00000008; const DIR_NOTIFICATION_ADD_ENTRY = 0x00000008;
const DIR_NOTIFICATION_RENAME_ENTRY = 0x00000010; const DIR_NOTIFICATION_RENAME_ENTRY = 0x00000010;
const DIR_NOTIFICATION_CHANGE_COOKIE_VERIFIER = 0x00000020; const DIR_NOTIFICATION_CHANGE_COOKIE_VERIFIER = 0x00000020;
typedef nfstime4 attr_notice4;
/* /*
* Input arguments passed to the GET_DIR_DELEGATION operation. * Input arguments passed to the GET_DIR_DELEGATION operation.
*/ */
struct GET_DIR_DELEGATION4args { struct GET_DIR_DELEGATION4args {
/* CURRENT_FH: directory */ /* CURRENT_FH: directory */
dir_notification_type4 notification_type; dir_notification_type4 notification_type;
attr_notice file_attr_notice; attr_notice4 child_attr_delay;
attr_notice dir_attr_notice; attr_notice4 dir_attr_delay;
}; };
/* /*
* Result flags * Result flags
*/ */
struct GET_DIR_DELEGATION4resok { struct GET_DIR_DELEGATION4resok {
verifier4 cookieverf; verifier4 cookieverf;
/* Stateid for get_dir_delegation */ /* Stateid for get_dir_delegation */
stateid4 stateid; stateid4 stateid;
/* Which notifications can the server support */ /* Which notifications can the server support */
dir_notification_type4 supp_notification; dir_notification_type4 supp_notification;
/* Which attribute notifications can the server support */ /* Which attribute notifications can the server support */
fattr4 file_attributes; bitmap4 child_attributes;
fattr4 dir_attributes; bitmap4 dir_attributes;
};
struct attr_notice {
bitmap4 attr_notice_req;
uint32_t attr_notice_delays<>;
}; };
union GET_DIR_DELEGATION4res switch (nfsstat4 status) { union GET_DIR_DELEGATION4res switch (nfsstat4 status) {
case NFS4_OK: case NFS4_OK:
/* CURRENT_FH: delegated dir */ /* CURRENT_FH: delegated dir */
GET_DIR_DELEGATION4resok resok4; GET_DIR_DELEGATION4resok resok4;
default: default:
void; void;
}; };
/* /*
skipping to change at page 19, line 35 skipping to change at page 20, line 35
NFS4ERR_BADCHAR = 10040,/* utf-8 char not supported*/ NFS4ERR_BADCHAR = 10040,/* utf-8 char not supported*/
NFS4ERR_BADNAME = 10041,/* name not supported */ NFS4ERR_BADNAME = 10041,/* name not supported */
NFS4ERR_BAD_RANGE = 10042,/* lock range not supported*/ NFS4ERR_BAD_RANGE = 10042,/* lock range not supported*/
NFS4ERR_LOCK_NOTSUPP = 10043,/* no atomic up/downgrade */ NFS4ERR_LOCK_NOTSUPP = 10043,/* no atomic up/downgrade */
NFS4ERR_OP_ILLEGAL = 10044,/* undefined operation */ NFS4ERR_OP_ILLEGAL = 10044,/* undefined operation */
NFS4ERR_DEADLOCK = 10045,/* file locking deadlock */ NFS4ERR_DEADLOCK = 10045,/* file locking deadlock */
NFS4ERR_FILE_OPEN = 10046,/* open file blocks op. */ NFS4ERR_FILE_OPEN = 10046,/* open file blocks op. */
NFS4ERR_ADMIN_REVOKED = 10047,/* lockowner state revoked */ NFS4ERR_ADMIN_REVOKED = 10047,/* lockowner state revoked */
NFS4ERR_CB_PATH_DOWN = 10048,/* callback path down */ NFS4ERR_CB_PATH_DOWN = 10048,/* callback path down */
NFS4ERR_DIRDELEG_UNAVAIL= 10049,/* dir dlg. not returned */ NFS4ERR_DIRDELEG_UNAVAIL= 10049,/* dir dlg. not returned */
NFS4ERR_DIRDELEG_DENIED = 10050 /* dir delegation denied */
}; };
/* /*
* New Callback operation CB_NOTIFY * New Callback operation CB_NOTIFY
*/ */
struct CB_NOTIFY4args { struct CB_NOTIFY4args {
stateid4 stateid; stateid4 stateid;
dir_notification4 changes<>; dir_notification4 changes<>;
}; };
skipping to change at page 20, line 9 skipping to change at page 21, line 8
/* /*
* Changed entry information. * Changed entry information.
*/ */
struct dir_entry { struct dir_entry {
component4 file; component4 file;
fattr4 attrs; fattr4 attrs;
}; };
struct dir_notification_attribute4 { struct dir_notification_attribute4 {
dir_entry changed_entry; dir_entry changed_entry;
fattr change_dir_attributes;
}; };
struct dir_notification_remove4 { struct dir_notification_remove4 {
dir_entry old_entry; dir_entry old_entry;
nfs_cookie4 old_entry_cookie; nfs_cookie4 old_entry_cookie;
}; };
struct dir_notification_rename4 { struct dir_notification_rename4 {
dir_entry old_entry; dir_entry old_entry;
dir_notification_add4 new_entry; dir_notification_add4 new_entry;
skipping to change at page 20, line 33 skipping to change at page 21, line 31
verifier4 old_cookieverf; verifier4 old_cookieverf;
verifier4 new_cookieverf; verifier4 new_cookieverf;
}; };
struct dir_notification_add4 { struct dir_notification_add4 {
dir_entry new_entry; dir_entry new_entry;
nfs_cookie4 new_entry_cookie; /* what READDIR would nfs_cookie4 new_entry_cookie; /* what READDIR would
have returned have returned
for this entry */ for this entry */
bool last_entry; bool last_entry;
prev_entry4 prev_entry_info; prev_entry_info4 prev_info;
}; };
union prev_entry4 switch (bool isprev) { union prev_entry_info4 switch (bool isprev) {
case TRUE: case TRUE:
prev_entry4 prev_entry_info; prev_entry4 prev_entry_info;
case FALSE: /* we are adding to an empty directory */ case FALSE: /* we are adding to an empty directory */
void; void;
}; };
/* /*
* Previous entry information * Previous entry information
*/ */
struct prev_entry4 { struct prev_entry4 {
dir_entry prev_entry; dir_entry prev_entry;
/* what READDIR returned for this entry */ /* what READDIR returned for this entry */
nfs_cookie4 prev_entry_cookie; nfs_cookie4 prev_entry_cookie;
}; };
/* /*
* Notification information sent to the client. * Notification information sent to the client.
*/ */
union dir_notification4 union dir_notification4
switch (dir_notification_type4 notification_type) { switch (dir_notification_type4 notification_type) {
case DIR_NOTIFICATION_CHANGE_FILE_ATTRIBUTE: case DIR_NOTIFICATION_CHANGE_CHILD_ATTRIBUTES:
dir_notification_attribute4 change_file_attributes; dir_notification_attribute4 change_child_attributes;
case DIR_NOTIFICATION_CHANGE_DIR_ATTRIBUTE: case DIR_NOTIFICATION_CHANGE_DIR_ATTRIBUTES:
fattr4 change_dir_attributes; fattr4 change_dir_attributes;
case DIR_NOTIFICATION_REMOVE_ENTRY: case DIR_NOTIFICATION_REMOVE_ENTRY:
dir_notification_remove4 remove_notification; dir_notification_remove4 remove_notification;
case DIR_NOTIFICATION_ADD_ENTRY: case DIR_NOTIFICATION_ADD_ENTRY:
dir_notification_add4 add_notification; dir_notification_add4 add_notification;
case DIR_NOTIFICATION_RENAME_ENTRY: case DIR_NOTIFICATION_RENAME_ENTRY:
dir_notification_rename4 rename_notification; dir_notification_rename4 rename_notification;
case DIR_NOTIFICATION_CHANGE_COOKIE_VERIFIER: case DIR_NOTIFICATION_CHANGE_COOKIE_VERIFIER:
dir_notification_verifier4 verf_notification; dir_notification_verifier4 verf_notification;
}; };
skipping to change at page 22, line 35 skipping to change at page 23, line 33
utf8str_cs tag; utf8str_cs tag;
nfs_cb_resop4 resarray<>; nfs_cb_resop4 resarray<>;
}; };
12. IANA Considerations 12. IANA Considerations
The IANA considerations of NFSv4.0 apply to NFSv4.1. The IANA considerations of NFSv4.0 apply to NFSv4.1.
13. Acknowledgements 13. Acknowledgements
David Noveck and Michael Eisler for their constructive feedback and David Noveck, Michael Eisler, Carl Burnett, Ted Anderson and Thomas
critical comments. Talpey for their constructive feedback and critical comments.
14. Normative References 14. Normative References
[RFC3530] [RFC3530]
S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M.
Eisler, D. Noveck, "NFS version 4 Protocol", RFC 3530, April, Eisler, D. Noveck, "NFS version 4 Protocol", RFC 3530, April,
2003. 2003.
[talpey] [talpey]
T. Talpey, S. Shepler, "NFSv4 RDMA and Session Extensions", T. Talpey, S. Shepler, J. Bauman "NFSv4 Session Extensions",
Internet-Draft, May, 2003. A URL for this Internet-Draft is Internet-Draft, July, 2004. A URL for this Internet-Draft is
available at http://www.ietf.org/internet-drafts/draft-talpey- available at http://www.ietf.org/internet-drafts/draft-ietf-
nfsv4-rdma-sess-00.txt nfsv4-sess-00.txt
15. Informative References 15. Informative References
None. None.
16. Author's Address 16. Author's Address
Saadia Khan Saadia Khan
2324 Dubois Street 2324 Dubois Street
Milpitas, CA 95035 Milpitas, CA 95035
skipping to change at page 23, line 43 skipping to change at page 24, line 43
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
18. Copyright Notice 18. Copyright Notice
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein is provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/