| David Howells | 0dfc41d | 2009-04-03 16:42:36 +0100 | [diff] [blame] | 1 | ========================== | 
|  | 2 | FS-CACHE CACHE BACKEND API | 
|  | 3 | ========================== | 
|  | 4 |  | 
|  | 5 | The FS-Cache system provides an API by which actual caches can be supplied to | 
|  | 6 | FS-Cache for it to then serve out to network filesystems and other interested | 
|  | 7 | parties. | 
|  | 8 |  | 
|  | 9 | This API is declared in <linux/fscache-cache.h>. | 
|  | 10 |  | 
|  | 11 |  | 
|  | 12 | ==================================== | 
|  | 13 | INITIALISING AND REGISTERING A CACHE | 
|  | 14 | ==================================== | 
|  | 15 |  | 
|  | 16 | To start off, a cache definition must be initialised and registered for each | 
|  | 17 | cache the backend wants to make available.  For instance, CacheFS does this in | 
|  | 18 | the fill_super() operation on mounting. | 
|  | 19 |  | 
|  | 20 | The cache definition (struct fscache_cache) should be initialised by calling: | 
|  | 21 |  | 
|  | 22 | void fscache_init_cache(struct fscache_cache *cache, | 
|  | 23 | struct fscache_cache_ops *ops, | 
|  | 24 | const char *idfmt, | 
|  | 25 | ...); | 
|  | 26 |  | 
|  | 27 | Where: | 
|  | 28 |  | 
|  | 29 | (*) "cache" is a pointer to the cache definition; | 
|  | 30 |  | 
|  | 31 | (*) "ops" is a pointer to the table of operations that the backend supports on | 
|  | 32 | this cache; and | 
|  | 33 |  | 
|  | 34 | (*) "idfmt" is a format and printf-style arguments for constructing a label | 
|  | 35 | for the cache. | 
|  | 36 |  | 
|  | 37 |  | 
|  | 38 | The cache should then be registered with FS-Cache by passing a pointer to the | 
|  | 39 | previously initialised cache definition to: | 
|  | 40 |  | 
|  | 41 | int fscache_add_cache(struct fscache_cache *cache, | 
|  | 42 | struct fscache_object *fsdef, | 
|  | 43 | const char *tagname); | 
|  | 44 |  | 
|  | 45 | Two extra arguments should also be supplied: | 
|  | 46 |  | 
|  | 47 | (*) "fsdef" which should point to the object representation for the FS-Cache | 
|  | 48 | master index in this cache.  Netfs primary index entries will be created | 
|  | 49 | here.  FS-Cache keeps the caller's reference to the index object if | 
|  | 50 | successful and will release it upon withdrawal of the cache. | 
|  | 51 |  | 
|  | 52 | (*) "tagname" which, if given, should be a text string naming this cache.  If | 
|  | 53 | this is NULL, the identifier will be used instead.  For CacheFS, the | 
|  | 54 | identifier is set to name the underlying block device and the tag can be | 
|  | 55 | supplied by mount. | 
|  | 56 |  | 
|  | 57 | This function may return -ENOMEM if it ran out of memory or -EEXIST if the tag | 
|  | 58 | is already in use.  0 will be returned on success. | 
|  | 59 |  | 
|  | 60 |  | 
|  | 61 | ===================== | 
|  | 62 | UNREGISTERING A CACHE | 
|  | 63 | ===================== | 
|  | 64 |  | 
|  | 65 | A cache can be withdrawn from the system by calling this function with a | 
|  | 66 | pointer to the cache definition: | 
|  | 67 |  | 
|  | 68 | void fscache_withdraw_cache(struct fscache_cache *cache); | 
|  | 69 |  | 
|  | 70 | In CacheFS's case, this is called by put_super(). | 
|  | 71 |  | 
|  | 72 |  | 
|  | 73 | ======== | 
|  | 74 | SECURITY | 
|  | 75 | ======== | 
|  | 76 |  | 
|  | 77 | The cache methods are executed one of two contexts: | 
|  | 78 |  | 
|  | 79 | (1) that of the userspace process that issued the netfs operation that caused | 
|  | 80 | the cache method to be invoked, or | 
|  | 81 |  | 
|  | 82 | (2) that of one of the processes in the FS-Cache thread pool. | 
|  | 83 |  | 
|  | 84 | In either case, this may not be an appropriate context in which to access the | 
|  | 85 | cache. | 
|  | 86 |  | 
|  | 87 | The calling process's fsuid, fsgid and SELinux security identities may need to | 
|  | 88 | be masqueraded for the duration of the cache driver's access to the cache. | 
|  | 89 | This is left to the cache to handle; FS-Cache makes no effort in this regard. | 
|  | 90 |  | 
|  | 91 |  | 
|  | 92 | =================================== | 
|  | 93 | CONTROL AND STATISTICS PRESENTATION | 
|  | 94 | =================================== | 
|  | 95 |  | 
|  | 96 | The cache may present data to the outside world through FS-Cache's interfaces | 
|  | 97 | in sysfs and procfs - the former for control and the latter for statistics. | 
|  | 98 |  | 
|  | 99 | A sysfs directory called /sys/fs/fscache/<cachetag>/ is created if CONFIG_SYSFS | 
|  | 100 | is enabled.  This is accessible through the kobject struct fscache_cache::kobj | 
|  | 101 | and is for use by the cache as it sees fit. | 
|  | 102 |  | 
| David Howells | 0dfc41d | 2009-04-03 16:42:36 +0100 | [diff] [blame] | 103 |  | 
|  | 104 | ======================== | 
|  | 105 | RELEVANT DATA STRUCTURES | 
|  | 106 | ======================== | 
|  | 107 |  | 
|  | 108 | (*) Index/Data file FS-Cache representation cookie: | 
|  | 109 |  | 
|  | 110 | struct fscache_cookie { | 
|  | 111 | struct fscache_object_def	*def; | 
|  | 112 | struct fscache_netfs		*netfs; | 
|  | 113 | void				*netfs_data; | 
|  | 114 | ... | 
|  | 115 | }; | 
|  | 116 |  | 
|  | 117 | The fields that might be of use to the backend describe the object | 
|  | 118 | definition, the netfs definition and the netfs's data for this cookie. | 
|  | 119 | The object definition contain functions supplied by the netfs for loading | 
|  | 120 | and matching index entries; these are required to provide some of the | 
|  | 121 | cache operations. | 
|  | 122 |  | 
|  | 123 |  | 
|  | 124 | (*) In-cache object representation: | 
|  | 125 |  | 
|  | 126 | struct fscache_object { | 
|  | 127 | int				debug_id; | 
|  | 128 | enum { | 
|  | 129 | FSCACHE_OBJECT_RECYCLING, | 
|  | 130 | ... | 
|  | 131 | }				state; | 
|  | 132 | spinlock_t			lock | 
|  | 133 | struct fscache_cache		*cache; | 
|  | 134 | struct fscache_cookie		*cookie; | 
|  | 135 | ... | 
|  | 136 | }; | 
|  | 137 |  | 
|  | 138 | Structures of this type should be allocated by the cache backend and | 
|  | 139 | passed to FS-Cache when requested by the appropriate cache operation.  In | 
|  | 140 | the case of CacheFS, they're embedded in CacheFS's internal object | 
|  | 141 | structures. | 
|  | 142 |  | 
|  | 143 | The debug_id is a simple integer that can be used in debugging messages | 
|  | 144 | that refer to a particular object.  In such a case it should be printed | 
|  | 145 | using "OBJ%x" to be consistent with FS-Cache. | 
|  | 146 |  | 
|  | 147 | Each object contains a pointer to the cookie that represents the object it | 
|  | 148 | is backing.  An object should retired when put_object() is called if it is | 
|  | 149 | in state FSCACHE_OBJECT_RECYCLING.  The fscache_object struct should be | 
|  | 150 | initialised by calling fscache_object_init(object). | 
|  | 151 |  | 
|  | 152 |  | 
|  | 153 | (*) FS-Cache operation record: | 
|  | 154 |  | 
|  | 155 | struct fscache_operation { | 
|  | 156 | atomic_t		usage; | 
|  | 157 | struct fscache_object	*object; | 
|  | 158 | unsigned long		flags; | 
|  | 159 | #define FSCACHE_OP_EXCLUSIVE | 
|  | 160 | void (*processor)(struct fscache_operation *op); | 
|  | 161 | void (*release)(struct fscache_operation *op); | 
|  | 162 | ... | 
|  | 163 | }; | 
|  | 164 |  | 
|  | 165 | FS-Cache has a pool of threads that it uses to give CPU time to the | 
|  | 166 | various asynchronous operations that need to be done as part of driving | 
|  | 167 | the cache.  These are represented by the above structure.  The processor | 
|  | 168 | method is called to give the op CPU time, and the release method to get | 
|  | 169 | rid of it when its usage count reaches 0. | 
|  | 170 |  | 
|  | 171 | An operation can be made exclusive upon an object by setting the | 
|  | 172 | appropriate flag before enqueuing it with fscache_enqueue_operation().  If | 
|  | 173 | an operation needs more processing time, it should be enqueued again. | 
|  | 174 |  | 
|  | 175 |  | 
|  | 176 | (*) FS-Cache retrieval operation record: | 
|  | 177 |  | 
|  | 178 | struct fscache_retrieval { | 
|  | 179 | struct fscache_operation op; | 
|  | 180 | struct address_space	*mapping; | 
|  | 181 | struct list_head	*to_do; | 
|  | 182 | ... | 
|  | 183 | }; | 
|  | 184 |  | 
|  | 185 | A structure of this type is allocated by FS-Cache to record retrieval and | 
|  | 186 | allocation requests made by the netfs.  This struct is then passed to the | 
|  | 187 | backend to do the operation.  The backend may get extra refs to it by | 
|  | 188 | calling fscache_get_retrieval() and refs may be discarded by calling | 
|  | 189 | fscache_put_retrieval(). | 
|  | 190 |  | 
|  | 191 | A retrieval operation can be used by the backend to do retrieval work.  To | 
|  | 192 | do this, the retrieval->op.processor method pointer should be set | 
|  | 193 | appropriately by the backend and fscache_enqueue_retrieval() called to | 
|  | 194 | submit it to the thread pool.  CacheFiles, for example, uses this to queue | 
|  | 195 | page examination when it detects PG_lock being cleared. | 
|  | 196 |  | 
|  | 197 | The to_do field is an empty list available for the cache backend to use as | 
|  | 198 | it sees fit. | 
|  | 199 |  | 
|  | 200 |  | 
|  | 201 | (*) FS-Cache storage operation record: | 
|  | 202 |  | 
|  | 203 | struct fscache_storage { | 
|  | 204 | struct fscache_operation op; | 
|  | 205 | pgoff_t			store_limit; | 
|  | 206 | ... | 
|  | 207 | }; | 
|  | 208 |  | 
|  | 209 | A structure of this type is allocated by FS-Cache to record outstanding | 
|  | 210 | writes to be made.  FS-Cache itself enqueues this operation and invokes | 
|  | 211 | the write_page() method on the object at appropriate times to effect | 
|  | 212 | storage. | 
|  | 213 |  | 
|  | 214 |  | 
|  | 215 | ================ | 
|  | 216 | CACHE OPERATIONS | 
|  | 217 | ================ | 
|  | 218 |  | 
|  | 219 | The cache backend provides FS-Cache with a table of operations that can be | 
|  | 220 | performed on the denizens of the cache.  These are held in a structure of type: | 
|  | 221 |  | 
|  | 222 | struct fscache_cache_ops | 
|  | 223 |  | 
|  | 224 | (*) Name of cache provider [mandatory]: | 
|  | 225 |  | 
|  | 226 | const char *name | 
|  | 227 |  | 
|  | 228 | This isn't strictly an operation, but should be pointed at a string naming | 
|  | 229 | the backend. | 
|  | 230 |  | 
|  | 231 |  | 
|  | 232 | (*) Allocate a new object [mandatory]: | 
|  | 233 |  | 
|  | 234 | struct fscache_object *(*alloc_object)(struct fscache_cache *cache, | 
|  | 235 | struct fscache_cookie *cookie) | 
|  | 236 |  | 
|  | 237 | This method is used to allocate a cache object representation to back a | 
|  | 238 | cookie in a particular cache.  fscache_object_init() should be called on | 
|  | 239 | the object to initialise it prior to returning. | 
|  | 240 |  | 
|  | 241 | This function may also be used to parse the index key to be used for | 
|  | 242 | multiple lookup calls to turn it into a more convenient form.  FS-Cache | 
|  | 243 | will call the lookup_complete() method to allow the cache to release the | 
|  | 244 | form once lookup is complete or aborted. | 
|  | 245 |  | 
|  | 246 |  | 
|  | 247 | (*) Look up and create object [mandatory]: | 
|  | 248 |  | 
|  | 249 | void (*lookup_object)(struct fscache_object *object) | 
|  | 250 |  | 
|  | 251 | This method is used to look up an object, given that the object is already | 
|  | 252 | allocated and attached to the cookie.  This should instantiate that object | 
|  | 253 | in the cache if it can. | 
|  | 254 |  | 
|  | 255 | The method should call fscache_object_lookup_negative() as soon as | 
|  | 256 | possible if it determines the object doesn't exist in the cache.  If the | 
|  | 257 | object is found to exist and the netfs indicates that it is valid then | 
|  | 258 | fscache_obtained_object() should be called once the object is in a | 
|  | 259 | position to have data stored in it.  Similarly, fscache_obtained_object() | 
|  | 260 | should also be called once a non-present object has been created. | 
|  | 261 |  | 
|  | 262 | If a lookup error occurs, fscache_object_lookup_error() should be called | 
|  | 263 | to abort the lookup of that object. | 
|  | 264 |  | 
|  | 265 |  | 
|  | 266 | (*) Release lookup data [mandatory]: | 
|  | 267 |  | 
|  | 268 | void (*lookup_complete)(struct fscache_object *object) | 
|  | 269 |  | 
|  | 270 | This method is called to ask the cache to release any resources it was | 
|  | 271 | using to perform a lookup. | 
|  | 272 |  | 
|  | 273 |  | 
|  | 274 | (*) Increment object refcount [mandatory]: | 
|  | 275 |  | 
|  | 276 | struct fscache_object *(*grab_object)(struct fscache_object *object) | 
|  | 277 |  | 
|  | 278 | This method is called to increment the reference count on an object.  It | 
|  | 279 | may fail (for instance if the cache is being withdrawn) by returning NULL. | 
|  | 280 | It should return the object pointer if successful. | 
|  | 281 |  | 
|  | 282 |  | 
|  | 283 | (*) Lock/Unlock object [mandatory]: | 
|  | 284 |  | 
|  | 285 | void (*lock_object)(struct fscache_object *object) | 
|  | 286 | void (*unlock_object)(struct fscache_object *object) | 
|  | 287 |  | 
|  | 288 | These methods are used to exclusively lock an object.  It must be possible | 
|  | 289 | to schedule with the lock held, so a spinlock isn't sufficient. | 
|  | 290 |  | 
|  | 291 |  | 
|  | 292 | (*) Pin/Unpin object [optional]: | 
|  | 293 |  | 
|  | 294 | int (*pin_object)(struct fscache_object *object) | 
|  | 295 | void (*unpin_object)(struct fscache_object *object) | 
|  | 296 |  | 
|  | 297 | These methods are used to pin an object into the cache.  Once pinned an | 
|  | 298 | object cannot be reclaimed to make space.  Return -ENOSPC if there's not | 
|  | 299 | enough space in the cache to permit this. | 
|  | 300 |  | 
|  | 301 |  | 
|  | 302 | (*) Update object [mandatory]: | 
|  | 303 |  | 
|  | 304 | int (*update_object)(struct fscache_object *object) | 
|  | 305 |  | 
|  | 306 | This is called to update the index entry for the specified object.  The | 
|  | 307 | new information should be in object->cookie->netfs_data.  This can be | 
|  | 308 | obtained by calling object->cookie->def->get_aux()/get_attr(). | 
|  | 309 |  | 
|  | 310 |  | 
|  | 311 | (*) Discard object [mandatory]: | 
|  | 312 |  | 
|  | 313 | void (*drop_object)(struct fscache_object *object) | 
|  | 314 |  | 
|  | 315 | This method is called to indicate that an object has been unbound from its | 
|  | 316 | cookie, and that the cache should release the object's resources and | 
|  | 317 | retire it if it's in state FSCACHE_OBJECT_RECYCLING. | 
|  | 318 |  | 
|  | 319 | This method should not attempt to release any references held by the | 
|  | 320 | caller.  The caller will invoke the put_object() method as appropriate. | 
|  | 321 |  | 
|  | 322 |  | 
|  | 323 | (*) Release object reference [mandatory]: | 
|  | 324 |  | 
|  | 325 | void (*put_object)(struct fscache_object *object) | 
|  | 326 |  | 
|  | 327 | This method is used to discard a reference to an object.  The object may | 
|  | 328 | be freed when all the references to it are released. | 
|  | 329 |  | 
|  | 330 |  | 
|  | 331 | (*) Synchronise a cache [mandatory]: | 
|  | 332 |  | 
|  | 333 | void (*sync)(struct fscache_cache *cache) | 
|  | 334 |  | 
|  | 335 | This is called to ask the backend to synchronise a cache with its backing | 
|  | 336 | device. | 
|  | 337 |  | 
|  | 338 |  | 
|  | 339 | (*) Dissociate a cache [mandatory]: | 
|  | 340 |  | 
|  | 341 | void (*dissociate_pages)(struct fscache_cache *cache) | 
|  | 342 |  | 
|  | 343 | This is called to ask a cache to perform any page dissociations as part of | 
|  | 344 | cache withdrawal. | 
|  | 345 |  | 
|  | 346 |  | 
|  | 347 | (*) Notification that the attributes on a netfs file changed [mandatory]: | 
|  | 348 |  | 
|  | 349 | int (*attr_changed)(struct fscache_object *object); | 
|  | 350 |  | 
|  | 351 | This is called to indicate to the cache that certain attributes on a netfs | 
|  | 352 | file have changed (for example the maximum size a file may reach).  The | 
|  | 353 | cache can read these from the netfs by calling the cookie's get_attr() | 
|  | 354 | method. | 
|  | 355 |  | 
|  | 356 | The cache may use the file size information to reserve space on the cache. | 
|  | 357 | It should also call fscache_set_store_limit() to indicate to FS-Cache the | 
|  | 358 | highest byte it's willing to store for an object. | 
|  | 359 |  | 
|  | 360 | This method may return -ve if an error occurred or the cache object cannot | 
|  | 361 | be expanded.  In such a case, the object will be withdrawn from service. | 
|  | 362 |  | 
|  | 363 | This operation is run asynchronously from FS-Cache's thread pool, and | 
|  | 364 | storage and retrieval operations from the netfs are excluded during the | 
|  | 365 | execution of this operation. | 
|  | 366 |  | 
|  | 367 |  | 
|  | 368 | (*) Reserve cache space for an object's data [optional]: | 
|  | 369 |  | 
|  | 370 | int (*reserve_space)(struct fscache_object *object, loff_t size); | 
|  | 371 |  | 
|  | 372 | This is called to request that cache space be reserved to hold the data | 
|  | 373 | for an object and the metadata used to track it.  Zero size should be | 
|  | 374 | taken as request to cancel a reservation. | 
|  | 375 |  | 
|  | 376 | This should return 0 if successful, -ENOSPC if there isn't enough space | 
|  | 377 | available, or -ENOMEM or -EIO on other errors. | 
|  | 378 |  | 
|  | 379 | The reservation may exceed the current size of the object, thus permitting | 
|  | 380 | future expansion.  If the amount of space consumed by an object would | 
|  | 381 | exceed the reservation, it's permitted to refuse requests to allocate | 
|  | 382 | pages, but not required.  An object may be pruned down to its reservation | 
|  | 383 | size if larger than that already. | 
|  | 384 |  | 
|  | 385 |  | 
|  | 386 | (*) Request page be read from cache [mandatory]: | 
|  | 387 |  | 
|  | 388 | int (*read_or_alloc_page)(struct fscache_retrieval *op, | 
|  | 389 | struct page *page, | 
|  | 390 | gfp_t gfp) | 
|  | 391 |  | 
|  | 392 | This is called to attempt to read a netfs page from the cache, or to | 
|  | 393 | reserve a backing block if not.  FS-Cache will have done as much checking | 
|  | 394 | as it can before calling, but most of the work belongs to the backend. | 
|  | 395 |  | 
|  | 396 | If there's no page in the cache, then -ENODATA should be returned if the | 
|  | 397 | backend managed to reserve a backing block; -ENOBUFS or -ENOMEM if it | 
|  | 398 | didn't. | 
|  | 399 |  | 
|  | 400 | If there is suitable data in the cache, then a read operation should be | 
|  | 401 | queued and 0 returned.  When the read finishes, fscache_end_io() should be | 
|  | 402 | called. | 
|  | 403 |  | 
|  | 404 | The fscache_mark_pages_cached() should be called for the page if any cache | 
|  | 405 | metadata is retained.  This will indicate to the netfs that the page needs | 
|  | 406 | explicit uncaching.  This operation takes a pagevec, thus allowing several | 
|  | 407 | pages to be marked at once. | 
|  | 408 |  | 
|  | 409 | The retrieval record pointed to by op should be retained for each page | 
|  | 410 | queued and released when I/O on the page has been formally ended. | 
|  | 411 | fscache_get/put_retrieval() are available for this purpose. | 
|  | 412 |  | 
|  | 413 | The retrieval record may be used to get CPU time via the FS-Cache thread | 
|  | 414 | pool.  If this is desired, the op->op.processor should be set to point to | 
|  | 415 | the appropriate processing routine, and fscache_enqueue_retrieval() should | 
|  | 416 | be called at an appropriate point to request CPU time.  For instance, the | 
|  | 417 | retrieval routine could be enqueued upon the completion of a disk read. | 
|  | 418 | The to_do field in the retrieval record is provided to aid in this. | 
|  | 419 |  | 
|  | 420 | If an I/O error occurs, fscache_io_error() should be called and -ENOBUFS | 
|  | 421 | returned if possible or fscache_end_io() called with a suitable error | 
|  | 422 | code.. | 
|  | 423 |  | 
|  | 424 |  | 
|  | 425 | (*) Request pages be read from cache [mandatory]: | 
|  | 426 |  | 
|  | 427 | int (*read_or_alloc_pages)(struct fscache_retrieval *op, | 
|  | 428 | struct list_head *pages, | 
|  | 429 | unsigned *nr_pages, | 
|  | 430 | gfp_t gfp) | 
|  | 431 |  | 
|  | 432 | This is like the read_or_alloc_page() method, except it is handed a list | 
|  | 433 | of pages instead of one page.  Any pages on which a read operation is | 
|  | 434 | started must be added to the page cache for the specified mapping and also | 
|  | 435 | to the LRU.  Such pages must also be removed from the pages list and | 
|  | 436 | *nr_pages decremented per page. | 
|  | 437 |  | 
|  | 438 | If there was an error such as -ENOMEM, then that should be returned; else | 
|  | 439 | if one or more pages couldn't be read or allocated, then -ENOBUFS should | 
|  | 440 | be returned; else if one or more pages couldn't be read, then -ENODATA | 
|  | 441 | should be returned.  If all the pages are dispatched then 0 should be | 
|  | 442 | returned. | 
|  | 443 |  | 
|  | 444 |  | 
|  | 445 | (*) Request page be allocated in the cache [mandatory]: | 
|  | 446 |  | 
|  | 447 | int (*allocate_page)(struct fscache_retrieval *op, | 
|  | 448 | struct page *page, | 
|  | 449 | gfp_t gfp) | 
|  | 450 |  | 
|  | 451 | This is like the read_or_alloc_page() method, except that it shouldn't | 
|  | 452 | read from the cache, even if there's data there that could be retrieved. | 
|  | 453 | It should, however, set up any internal metadata required such that | 
|  | 454 | the write_page() method can write to the cache. | 
|  | 455 |  | 
|  | 456 | If there's no backing block available, then -ENOBUFS should be returned | 
|  | 457 | (or -ENOMEM if there were other problems).  If a block is successfully | 
|  | 458 | allocated, then the netfs page should be marked and 0 returned. | 
|  | 459 |  | 
|  | 460 |  | 
|  | 461 | (*) Request pages be allocated in the cache [mandatory]: | 
|  | 462 |  | 
|  | 463 | int (*allocate_pages)(struct fscache_retrieval *op, | 
|  | 464 | struct list_head *pages, | 
|  | 465 | unsigned *nr_pages, | 
|  | 466 | gfp_t gfp) | 
|  | 467 |  | 
|  | 468 | This is an multiple page version of the allocate_page() method.  pages and | 
|  | 469 | nr_pages should be treated as for the read_or_alloc_pages() method. | 
|  | 470 |  | 
|  | 471 |  | 
|  | 472 | (*) Request page be written to cache [mandatory]: | 
|  | 473 |  | 
|  | 474 | int (*write_page)(struct fscache_storage *op, | 
|  | 475 | struct page *page); | 
|  | 476 |  | 
|  | 477 | This is called to write from a page on which there was a previously | 
|  | 478 | successful read_or_alloc_page() call or similar.  FS-Cache filters out | 
|  | 479 | pages that don't have mappings. | 
|  | 480 |  | 
|  | 481 | This method is called asynchronously from the FS-Cache thread pool.  It is | 
|  | 482 | not required to actually store anything, provided -ENODATA is then | 
|  | 483 | returned to the next read of this page. | 
|  | 484 |  | 
|  | 485 | If an error occurred, then a negative error code should be returned, | 
|  | 486 | otherwise zero should be returned.  FS-Cache will take appropriate action | 
|  | 487 | in response to an error, such as withdrawing this object. | 
|  | 488 |  | 
|  | 489 | If this method returns success then FS-Cache will inform the netfs | 
|  | 490 | appropriately. | 
|  | 491 |  | 
|  | 492 |  | 
|  | 493 | (*) Discard retained per-page metadata [mandatory]: | 
|  | 494 |  | 
|  | 495 | void (*uncache_page)(struct fscache_object *object, struct page *page) | 
|  | 496 |  | 
|  | 497 | This is called when a netfs page is being evicted from the pagecache.  The | 
|  | 498 | cache backend should tear down any internal representation or tracking it | 
|  | 499 | maintains for this page. | 
|  | 500 |  | 
|  | 501 |  | 
|  | 502 | ================== | 
|  | 503 | FS-CACHE UTILITIES | 
|  | 504 | ================== | 
|  | 505 |  | 
|  | 506 | FS-Cache provides some utilities that a cache backend may make use of: | 
|  | 507 |  | 
|  | 508 | (*) Note occurrence of an I/O error in a cache: | 
|  | 509 |  | 
|  | 510 | void fscache_io_error(struct fscache_cache *cache) | 
|  | 511 |  | 
|  | 512 | This tells FS-Cache that an I/O error occurred in the cache.  After this | 
|  | 513 | has been called, only resource dissociation operations (object and page | 
|  | 514 | release) will be passed from the netfs to the cache backend for the | 
|  | 515 | specified cache. | 
|  | 516 |  | 
|  | 517 | This does not actually withdraw the cache.  That must be done separately. | 
|  | 518 |  | 
|  | 519 |  | 
|  | 520 | (*) Invoke the retrieval I/O completion function: | 
|  | 521 |  | 
|  | 522 | void fscache_end_io(struct fscache_retrieval *op, struct page *page, | 
|  | 523 | int error); | 
|  | 524 |  | 
|  | 525 | This is called to note the end of an attempt to retrieve a page.  The | 
|  | 526 | error value should be 0 if successful and an error otherwise. | 
|  | 527 |  | 
|  | 528 |  | 
|  | 529 | (*) Set highest store limit: | 
|  | 530 |  | 
|  | 531 | void fscache_set_store_limit(struct fscache_object *object, | 
|  | 532 | loff_t i_size); | 
|  | 533 |  | 
|  | 534 | This sets the limit FS-Cache imposes on the highest byte it's willing to | 
|  | 535 | try and store for a netfs.  Any page over this limit is automatically | 
|  | 536 | rejected by fscache_read_alloc_page() and co with -ENOBUFS. | 
|  | 537 |  | 
|  | 538 |  | 
|  | 539 | (*) Mark pages as being cached: | 
|  | 540 |  | 
|  | 541 | void fscache_mark_pages_cached(struct fscache_retrieval *op, | 
|  | 542 | struct pagevec *pagevec); | 
|  | 543 |  | 
|  | 544 | This marks a set of pages as being cached.  After this has been called, | 
|  | 545 | the netfs must call fscache_uncache_page() to unmark the pages. | 
|  | 546 |  | 
|  | 547 |  | 
|  | 548 | (*) Perform coherency check on an object: | 
|  | 549 |  | 
|  | 550 | enum fscache_checkaux fscache_check_aux(struct fscache_object *object, | 
|  | 551 | const void *data, | 
|  | 552 | uint16_t datalen); | 
|  | 553 |  | 
|  | 554 | This asks the netfs to perform a coherency check on an object that has | 
|  | 555 | just been looked up.  The cookie attached to the object will determine the | 
|  | 556 | netfs to use.  data and datalen should specify where the auxiliary data | 
|  | 557 | retrieved from the cache can be found. | 
|  | 558 |  | 
|  | 559 | One of three values will be returned: | 
|  | 560 |  | 
|  | 561 | (*) FSCACHE_CHECKAUX_OKAY | 
|  | 562 |  | 
|  | 563 | The coherency data indicates the object is valid as is. | 
|  | 564 |  | 
|  | 565 | (*) FSCACHE_CHECKAUX_NEEDS_UPDATE | 
|  | 566 |  | 
|  | 567 | The coherency data needs updating, but otherwise the object is | 
|  | 568 | valid. | 
|  | 569 |  | 
|  | 570 | (*) FSCACHE_CHECKAUX_OBSOLETE | 
|  | 571 |  | 
|  | 572 | The coherency data indicates that the object is obsolete and should | 
|  | 573 | be discarded. | 
|  | 574 |  | 
|  | 575 |  | 
|  | 576 | (*) Initialise a freshly allocated object: | 
|  | 577 |  | 
|  | 578 | void fscache_object_init(struct fscache_object *object); | 
|  | 579 |  | 
|  | 580 | This initialises all the fields in an object representation. | 
|  | 581 |  | 
|  | 582 |  | 
|  | 583 | (*) Indicate the destruction of an object: | 
|  | 584 |  | 
|  | 585 | void fscache_object_destroyed(struct fscache_cache *cache); | 
|  | 586 |  | 
|  | 587 | This must be called to inform FS-Cache that an object that belonged to a | 
|  | 588 | cache has been destroyed and deallocated.  This will allow continuation | 
|  | 589 | of the cache withdrawal process when it is stopped pending destruction of | 
|  | 590 | all the objects. | 
|  | 591 |  | 
|  | 592 |  | 
|  | 593 | (*) Indicate negative lookup on an object: | 
|  | 594 |  | 
|  | 595 | void fscache_object_lookup_negative(struct fscache_object *object); | 
|  | 596 |  | 
|  | 597 | This is called to indicate to FS-Cache that a lookup process for an object | 
|  | 598 | found a negative result. | 
|  | 599 |  | 
|  | 600 | This changes the state of an object to permit reads pending on lookup | 
|  | 601 | completion to go off and start fetching data from the netfs server as it's | 
|  | 602 | known at this point that there can't be any data in the cache. | 
|  | 603 |  | 
|  | 604 | This may be called multiple times on an object.  Only the first call is | 
|  | 605 | significant - all subsequent calls are ignored. | 
|  | 606 |  | 
|  | 607 |  | 
|  | 608 | (*) Indicate an object has been obtained: | 
|  | 609 |  | 
|  | 610 | void fscache_obtained_object(struct fscache_object *object); | 
|  | 611 |  | 
|  | 612 | This is called to indicate to FS-Cache that a lookup process for an object | 
|  | 613 | produced a positive result, or that an object was created.  This should | 
|  | 614 | only be called once for any particular object. | 
|  | 615 |  | 
|  | 616 | This changes the state of an object to indicate: | 
|  | 617 |  | 
|  | 618 | (1) if no call to fscache_object_lookup_negative() has been made on | 
|  | 619 | this object, that there may be data available, and that reads can | 
|  | 620 | now go and look for it; and | 
|  | 621 |  | 
|  | 622 | (2) that writes may now proceed against this object. | 
|  | 623 |  | 
|  | 624 |  | 
|  | 625 | (*) Indicate that object lookup failed: | 
|  | 626 |  | 
|  | 627 | void fscache_object_lookup_error(struct fscache_object *object); | 
|  | 628 |  | 
|  | 629 | This marks an object as having encountered a fatal error (usually EIO) | 
|  | 630 | and causes it to move into a state whereby it will be withdrawn as soon | 
|  | 631 | as possible. | 
|  | 632 |  | 
|  | 633 |  | 
|  | 634 | (*) Get and release references on a retrieval record: | 
|  | 635 |  | 
|  | 636 | void fscache_get_retrieval(struct fscache_retrieval *op); | 
|  | 637 | void fscache_put_retrieval(struct fscache_retrieval *op); | 
|  | 638 |  | 
|  | 639 | These two functions are used to retain a retrieval record whilst doing | 
|  | 640 | asynchronous data retrieval and block allocation. | 
|  | 641 |  | 
|  | 642 |  | 
|  | 643 | (*) Enqueue a retrieval record for processing. | 
|  | 644 |  | 
|  | 645 | void fscache_enqueue_retrieval(struct fscache_retrieval *op); | 
|  | 646 |  | 
|  | 647 | This enqueues a retrieval record for processing by the FS-Cache thread | 
|  | 648 | pool.  One of the threads in the pool will invoke the retrieval record's | 
|  | 649 | op->op.processor callback function.  This function may be called from | 
|  | 650 | within the callback function. | 
|  | 651 |  | 
|  | 652 |  | 
|  | 653 | (*) List of object state names: | 
|  | 654 |  | 
|  | 655 | const char *fscache_object_states[]; | 
|  | 656 |  | 
|  | 657 | For debugging purposes, this may be used to turn the state that an object | 
|  | 658 | is in into a text string for display purposes. |