| exporting.rst (976e3645923bdd2fe7893aae33fd7a21098bfb28) | exporting.rst (daab110e47f8d7aa6da66923e3ac1a8dbd2b2a72) |
|---|---|
| 1:orphan: 2 3Making Filesystems Exportable 4============================= 5 6Overview 7-------- 8 --- 140 unchanged lines hidden (view full) --- 149 get_name (optional) 150 When given a parent dentry and a child dentry, this should find a name 151 in the directory identified by the parent dentry, which leads to the 152 object identified by the child dentry. If no get_name function is 153 supplied, a default implementation is provided which uses vfs_readdir 154 to find potential names, and matches inode numbers to find the correct 155 match. 156 | 1:orphan: 2 3Making Filesystems Exportable 4============================= 5 6Overview 7-------- 8 --- 140 unchanged lines hidden (view full) --- 149 get_name (optional) 150 When given a parent dentry and a child dentry, this should find a name 151 in the directory identified by the parent dentry, which leads to the 152 object identified by the child dentry. If no get_name function is 153 supplied, a default implementation is provided which uses vfs_readdir 154 to find potential names, and matches inode numbers to find the correct 155 match. 156 |
| 157 flags 158 Some filesystems may need to be handled differently than others. The 159 export_operations struct also includes a flags field that allows the 160 filesystem to communicate such information to nfsd. See the Export 161 Operations Flags section below for more explanation. |
|
| 157 158A filehandle fragment consists of an array of 1 or more 4byte words, 159together with a one byte "type". 160The decode_fh routine should not depend on the stated size that is 161passed to it. This size may be larger than the original filehandle 162generated by encode_fh, in which case it will have been padded with 163nuls. Rather, the encode_fh routine should choose a "type" which 164indicates the decode_fh how much of the filehandle is valid, and how 165it should be interpreted. | 162 163A filehandle fragment consists of an array of 1 or more 4byte words, 164together with a one byte "type". 165The decode_fh routine should not depend on the stated size that is 166passed to it. This size may be larger than the original filehandle 167generated by encode_fh, in which case it will have been padded with 168nuls. Rather, the encode_fh routine should choose a "type" which 169indicates the decode_fh how much of the filehandle is valid, and how 170it should be interpreted. |
| 171 172Export Operations Flags 173----------------------- 174In addition to the operation vector pointers, struct export_operations also 175contains a "flags" field that allows the filesystem to communicate to nfsd 176that it may want to do things differently when dealing with it. The 177following flags are defined: 178 179 EXPORT_OP_NOWCC - disable NFSv3 WCC attributes on this filesystem 180 RFC 1813 recommends that servers always send weak cache consistency 181 (WCC) data to the client after each operation. The server should 182 atomically collect attributes about the inode, do an operation on it, 183 and then collect the attributes afterward. This allows the client to 184 skip issuing GETATTRs in some situations but means that the server 185 is calling vfs_getattr for almost all RPCs. On some filesystems 186 (particularly those that are clustered or networked) this is expensive 187 and atomicity is difficult to guarantee. This flag indicates to nfsd 188 that it should skip providing WCC attributes to the client in NFSv3 189 replies when doing operations on this filesystem. Consider enabling 190 this on filesystems that have an expensive ->getattr inode operation, 191 or when atomicity between pre and post operation attribute collection 192 is impossible to guarantee. |
|