]> git.kernelconcepts.de Git - karo-tx-linux.git/blob - Documentation/filesystems/caching/backend-api.txt
FS-Cache: Fix operation state management and accounting
[karo-tx-linux.git] / Documentation / filesystems / caching / backend-api.txt
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
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      fscache_put_retrieval() should be called after a page or pages are dealt
425      with.  This will complete the operation when all pages are dealt with.
426
427
428  (*) Request pages be read from cache [mandatory]:
429
430         int (*read_or_alloc_pages)(struct fscache_retrieval *op,
431                                    struct list_head *pages,
432                                    unsigned *nr_pages,
433                                    gfp_t gfp)
434
435      This is like the read_or_alloc_page() method, except it is handed a list
436      of pages instead of one page.  Any pages on which a read operation is
437      started must be added to the page cache for the specified mapping and also
438      to the LRU.  Such pages must also be removed from the pages list and
439      *nr_pages decremented per page.
440
441      If there was an error such as -ENOMEM, then that should be returned; else
442      if one or more pages couldn't be read or allocated, then -ENOBUFS should
443      be returned; else if one or more pages couldn't be read, then -ENODATA
444      should be returned.  If all the pages are dispatched then 0 should be
445      returned.
446
447
448  (*) Request page be allocated in the cache [mandatory]:
449
450         int (*allocate_page)(struct fscache_retrieval *op,
451                              struct page *page,
452                              gfp_t gfp)
453
454      This is like the read_or_alloc_page() method, except that it shouldn't
455      read from the cache, even if there's data there that could be retrieved.
456      It should, however, set up any internal metadata required such that
457      the write_page() method can write to the cache.
458
459      If there's no backing block available, then -ENOBUFS should be returned
460      (or -ENOMEM if there were other problems).  If a block is successfully
461      allocated, then the netfs page should be marked and 0 returned.
462
463
464  (*) Request pages be allocated in the cache [mandatory]:
465
466         int (*allocate_pages)(struct fscache_retrieval *op,
467                               struct list_head *pages,
468                               unsigned *nr_pages,
469                               gfp_t gfp)
470
471      This is an multiple page version of the allocate_page() method.  pages and
472      nr_pages should be treated as for the read_or_alloc_pages() method.
473
474
475  (*) Request page be written to cache [mandatory]:
476
477         int (*write_page)(struct fscache_storage *op,
478                           struct page *page);
479
480      This is called to write from a page on which there was a previously
481      successful read_or_alloc_page() call or similar.  FS-Cache filters out
482      pages that don't have mappings.
483
484      This method is called asynchronously from the FS-Cache thread pool.  It is
485      not required to actually store anything, provided -ENODATA is then
486      returned to the next read of this page.
487
488      If an error occurred, then a negative error code should be returned,
489      otherwise zero should be returned.  FS-Cache will take appropriate action
490      in response to an error, such as withdrawing this object.
491
492      If this method returns success then FS-Cache will inform the netfs
493      appropriately.
494
495
496  (*) Discard retained per-page metadata [mandatory]:
497
498         void (*uncache_page)(struct fscache_object *object, struct page *page)
499
500      This is called when a netfs page is being evicted from the pagecache.  The
501      cache backend should tear down any internal representation or tracking it
502      maintains for this page.
503
504
505 ==================
506 FS-CACHE UTILITIES
507 ==================
508
509 FS-Cache provides some utilities that a cache backend may make use of:
510
511  (*) Note occurrence of an I/O error in a cache:
512
513         void fscache_io_error(struct fscache_cache *cache)
514
515      This tells FS-Cache that an I/O error occurred in the cache.  After this
516      has been called, only resource dissociation operations (object and page
517      release) will be passed from the netfs to the cache backend for the
518      specified cache.
519
520      This does not actually withdraw the cache.  That must be done separately.
521
522
523  (*) Invoke the retrieval I/O completion function:
524
525         void fscache_end_io(struct fscache_retrieval *op, struct page *page,
526                             int error);
527
528      This is called to note the end of an attempt to retrieve a page.  The
529      error value should be 0 if successful and an error otherwise.
530
531
532  (*) Record that one or more pages being retrieved or allocated have been dealt
533      with:
534
535         void fscache_retrieval_complete(struct fscache_retrieval *op,
536                                         int n_pages);
537
538      This is called to record the fact that one or more pages have been dealt
539      with and are no longer the concern of this operation.  When the number of
540      pages remaining in the operation reaches 0, the operation will be
541      completed.
542
543
544  (*) Record operation completion:
545
546         void fscache_op_complete(struct fscache_operation *op);
547
548      This is called to record the completion of an operation.  This deducts
549      this operation from the parent object's run state, potentially permitting
550      one or more pending operations to start running.
551
552
553  (*) Set highest store limit:
554
555         void fscache_set_store_limit(struct fscache_object *object,
556                                      loff_t i_size);
557
558      This sets the limit FS-Cache imposes on the highest byte it's willing to
559      try and store for a netfs.  Any page over this limit is automatically
560      rejected by fscache_read_alloc_page() and co with -ENOBUFS.
561
562
563  (*) Mark pages as being cached:
564
565         void fscache_mark_pages_cached(struct fscache_retrieval *op,
566                                        struct pagevec *pagevec);
567
568      This marks a set of pages as being cached.  After this has been called,
569      the netfs must call fscache_uncache_page() to unmark the pages.
570
571
572  (*) Perform coherency check on an object:
573
574         enum fscache_checkaux fscache_check_aux(struct fscache_object *object,
575                                                 const void *data,
576                                                 uint16_t datalen);
577
578      This asks the netfs to perform a coherency check on an object that has
579      just been looked up.  The cookie attached to the object will determine the
580      netfs to use.  data and datalen should specify where the auxiliary data
581      retrieved from the cache can be found.
582
583      One of three values will be returned:
584
585         (*) FSCACHE_CHECKAUX_OKAY
586
587             The coherency data indicates the object is valid as is.
588
589         (*) FSCACHE_CHECKAUX_NEEDS_UPDATE
590
591             The coherency data needs updating, but otherwise the object is
592             valid.
593
594         (*) FSCACHE_CHECKAUX_OBSOLETE
595
596             The coherency data indicates that the object is obsolete and should
597             be discarded.
598
599
600  (*) Initialise a freshly allocated object:
601
602         void fscache_object_init(struct fscache_object *object);
603
604      This initialises all the fields in an object representation.
605
606
607  (*) Indicate the destruction of an object:
608
609         void fscache_object_destroyed(struct fscache_cache *cache);
610
611      This must be called to inform FS-Cache that an object that belonged to a
612      cache has been destroyed and deallocated.  This will allow continuation
613      of the cache withdrawal process when it is stopped pending destruction of
614      all the objects.
615
616
617  (*) Indicate negative lookup on an object:
618
619         void fscache_object_lookup_negative(struct fscache_object *object);
620
621      This is called to indicate to FS-Cache that a lookup process for an object
622      found a negative result.
623
624      This changes the state of an object to permit reads pending on lookup
625      completion to go off and start fetching data from the netfs server as it's
626      known at this point that there can't be any data in the cache.
627
628      This may be called multiple times on an object.  Only the first call is
629      significant - all subsequent calls are ignored.
630
631
632  (*) Indicate an object has been obtained:
633
634         void fscache_obtained_object(struct fscache_object *object);
635
636      This is called to indicate to FS-Cache that a lookup process for an object
637      produced a positive result, or that an object was created.  This should
638      only be called once for any particular object.
639
640      This changes the state of an object to indicate:
641
642         (1) if no call to fscache_object_lookup_negative() has been made on
643             this object, that there may be data available, and that reads can
644             now go and look for it; and
645
646         (2) that writes may now proceed against this object.
647
648
649  (*) Indicate that object lookup failed:
650
651         void fscache_object_lookup_error(struct fscache_object *object);
652
653      This marks an object as having encountered a fatal error (usually EIO)
654      and causes it to move into a state whereby it will be withdrawn as soon
655      as possible.
656
657
658  (*) Get and release references on a retrieval record:
659
660         void fscache_get_retrieval(struct fscache_retrieval *op);
661         void fscache_put_retrieval(struct fscache_retrieval *op);
662
663      These two functions are used to retain a retrieval record whilst doing
664      asynchronous data retrieval and block allocation.
665
666
667  (*) Enqueue a retrieval record for processing.
668
669         void fscache_enqueue_retrieval(struct fscache_retrieval *op);
670
671      This enqueues a retrieval record for processing by the FS-Cache thread
672      pool.  One of the threads in the pool will invoke the retrieval record's
673      op->op.processor callback function.  This function may be called from
674      within the callback function.
675
676
677  (*) List of object state names:
678
679         const char *fscache_object_states[];
680
681      For debugging purposes, this may be used to turn the state that an object
682      is in into a text string for display purposes.