mm-only debug patch...
[mmotm.git] / Documentation / filesystems / caching / backend-api.txt
blob382d52cdaf2da374061764865fa04db2c73fa072
1                           ==========================
2                           FS-CACHE CACHE BACKEND API
3                           ==========================
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.
9 This API is declared in <linux/fscache-cache.h>.
12 ====================================
13 INITIALISING AND REGISTERING A CACHE
14 ====================================
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.
20 The cache definition (struct fscache_cache) should be initialised by calling:
22         void fscache_init_cache(struct fscache_cache *cache,
23                                 struct fscache_cache_ops *ops,
24                                 const char *idfmt,
25                                 ...);
27 Where:
29  (*) "cache" is a pointer to the cache definition;
31  (*) "ops" is a pointer to the table of operations that the backend supports on
32      this cache; and
34  (*) "idfmt" is a format and printf-style arguments for constructing a label
35      for the cache.
38 The cache should then be registered with FS-Cache by passing a pointer to the
39 previously initialised cache definition to:
41         int fscache_add_cache(struct fscache_cache *cache,
42                               struct fscache_object *fsdef,
43                               const char *tagname);
45 Two extra arguments should also be supplied:
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.
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.
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.
61 =====================
62 UNREGISTERING A CACHE
63 =====================
65 A cache can be withdrawn from the system by calling this function with a
66 pointer to the cache definition:
68         void fscache_withdraw_cache(struct fscache_cache *cache);
70 In CacheFS's case, this is called by put_super().
73 ========
74 SECURITY
75 ========
77 The cache methods are executed one of two contexts:
79  (1) that of the userspace process that issued the netfs operation that caused
80      the cache method to be invoked, or
82  (2) that of one of the processes in the FS-Cache thread pool.
84 In either case, this may not be an appropriate context in which to access the
85 cache.
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.
92 ===================================
93 CONTROL AND STATISTICS PRESENTATION
94 ===================================
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.
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.
104 ========================
105 RELEVANT DATA STRUCTURES
106 ========================
108  (*) Index/Data file FS-Cache representation cookie:
110         struct fscache_cookie {
111                 struct fscache_object_def       *def;
112                 struct fscache_netfs            *netfs;
113                 void                            *netfs_data;
114                 ...
115         };
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.
124  (*) In-cache object representation:
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         };
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.
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.
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).
153  (*) FS-Cache operation record:
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         };
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.
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.
176  (*) FS-Cache retrieval operation record:
178         struct fscache_retrieval {
179                 struct fscache_operation op;
180                 struct address_space    *mapping;
181                 struct list_head        *to_do;
182                 ...
183         };
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().
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.
197      The to_do field is an empty list available for the cache backend to use as
198      it sees fit.
201  (*) FS-Cache storage operation record:
203         struct fscache_storage {
204                 struct fscache_operation op;
205                 pgoff_t                 store_limit;
206                 ...
207         };
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.
215 ================
216 CACHE OPERATIONS
217 ================
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:
222         struct fscache_cache_ops
224  (*) Name of cache provider [mandatory]:
226         const char *name
228      This isn't strictly an operation, but should be pointed at a string naming
229      the backend.
232  (*) Allocate a new object [mandatory]:
234         struct fscache_object *(*alloc_object)(struct fscache_cache *cache,
235                                                struct fscache_cookie *cookie)
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.
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.
247  (*) Look up and create object [mandatory]:
249         void (*lookup_object)(struct fscache_object *object)
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.
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.
262      If a lookup error occurs, fscache_object_lookup_error() should be called
263      to abort the lookup of that object.
266  (*) Release lookup data [mandatory]:
268         void (*lookup_complete)(struct fscache_object *object)
270      This method is called to ask the cache to release any resources it was
271      using to perform a lookup.
274  (*) Increment object refcount [mandatory]:
276         struct fscache_object *(*grab_object)(struct fscache_object *object)
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.
283  (*) Lock/Unlock object [mandatory]:
285         void (*lock_object)(struct fscache_object *object)
286         void (*unlock_object)(struct fscache_object *object)
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.
292  (*) Pin/Unpin object [optional]:
294         int (*pin_object)(struct fscache_object *object)
295         void (*unpin_object)(struct fscache_object *object)
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.
302  (*) Update object [mandatory]:
304         int (*update_object)(struct fscache_object *object)
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().
311  (*) Discard object [mandatory]:
313         void (*drop_object)(struct fscache_object *object)
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.
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.
323  (*) Release object reference [mandatory]:
325         void (*put_object)(struct fscache_object *object)
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.
331  (*) Synchronise a cache [mandatory]:
333         void (*sync)(struct fscache_cache *cache)
335      This is called to ask the backend to synchronise a cache with its backing
336      device.
339  (*) Dissociate a cache [mandatory]:
341         void (*dissociate_pages)(struct fscache_cache *cache)
343      This is called to ask a cache to perform any page dissociations as part of
344      cache withdrawal.
347  (*) Notification that the attributes on a netfs file changed [mandatory]:
349         int (*attr_changed)(struct fscache_object *object);
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.
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.
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.
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.
368  (*) Reserve cache space for an object's data [optional]:
370         int (*reserve_space)(struct fscache_object *object, loff_t size);
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.
376      This should return 0 if successful, -ENOSPC if there isn't enough space
377      available, or -ENOMEM or -EIO on other errors.
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.
386  (*) Request page be read from cache [mandatory]:
388         int (*read_or_alloc_page)(struct fscache_retrieval *op,
389                                   struct page *page,
390                                   gfp_t gfp)
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.
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.
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.
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.
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.
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.
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..
425  (*) Request pages be read from cache [mandatory]:
427         int (*read_or_alloc_pages)(struct fscache_retrieval *op,
428                                    struct list_head *pages,
429                                    unsigned *nr_pages,
430                                    gfp_t gfp)
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.
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.
445  (*) Request page be allocated in the cache [mandatory]:
447         int (*allocate_page)(struct fscache_retrieval *op,
448                              struct page *page,
449                              gfp_t gfp)
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.
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.
461  (*) Request pages be allocated in the cache [mandatory]:
463         int (*allocate_pages)(struct fscache_retrieval *op,
464                               struct list_head *pages,
465                               unsigned *nr_pages,
466                               gfp_t gfp)
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.
472  (*) Request page be written to cache [mandatory]:
474         int (*write_page)(struct fscache_storage *op,
475                           struct page *page);
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.
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.
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.
489      If this method returns success then FS-Cache will inform the netfs
490      appropriately.
493  (*) Discard retained per-page metadata [mandatory]:
495         void (*uncache_page)(struct fscache_object *object, struct page *page)
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.
502 ==================
503 FS-CACHE UTILITIES
504 ==================
506 FS-Cache provides some utilities that a cache backend may make use of:
508  (*) Note occurrence of an I/O error in a cache:
510         void fscache_io_error(struct fscache_cache *cache)
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.
517      This does not actually withdraw the cache.  That must be done separately.
520  (*) Invoke the retrieval I/O completion function:
522         void fscache_end_io(struct fscache_retrieval *op, struct page *page,
523                             int error);
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.
529  (*) Set highest store limit:
531         void fscache_set_store_limit(struct fscache_object *object,
532                                      loff_t i_size);
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.
539  (*) Mark pages as being cached:
541         void fscache_mark_pages_cached(struct fscache_retrieval *op,
542                                        struct pagevec *pagevec);
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.
548  (*) Perform coherency check on an object:
550         enum fscache_checkaux fscache_check_aux(struct fscache_object *object,
551                                                 const void *data,
552                                                 uint16_t datalen);
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.
559      One of three values will be returned:
561         (*) FSCACHE_CHECKAUX_OKAY
563             The coherency data indicates the object is valid as is.
565         (*) FSCACHE_CHECKAUX_NEEDS_UPDATE
567             The coherency data needs updating, but otherwise the object is
568             valid.
570         (*) FSCACHE_CHECKAUX_OBSOLETE
572             The coherency data indicates that the object is obsolete and should
573             be discarded.
576  (*) Initialise a freshly allocated object:
578         void fscache_object_init(struct fscache_object *object);
580      This initialises all the fields in an object representation.
583  (*) Indicate the destruction of an object:
585         void fscache_object_destroyed(struct fscache_cache *cache);
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.
593  (*) Indicate negative lookup on an object:
595         void fscache_object_lookup_negative(struct fscache_object *object);
597      This is called to indicate to FS-Cache that a lookup process for an object
598      found a negative result.
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.
604      This may be called multiple times on an object.  Only the first call is
605      significant - all subsequent calls are ignored.
608  (*) Indicate an object has been obtained:
610         void fscache_obtained_object(struct fscache_object *object);
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.
616      This changes the state of an object to indicate:
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
622         (2) that writes may now proceed against this object.
625  (*) Indicate that object lookup failed:
627         void fscache_object_lookup_error(struct fscache_object *object);
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.
634  (*) Get and release references on a retrieval record:
636         void fscache_get_retrieval(struct fscache_retrieval *op);
637         void fscache_put_retrieval(struct fscache_retrieval *op);
639      These two functions are used to retain a retrieval record whilst doing
640      asynchronous data retrieval and block allocation.
643  (*) Enqueue a retrieval record for processing.
645         void fscache_enqueue_retrieval(struct fscache_retrieval *op);
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.
653  (*) List of object state names:
655         const char *fscache_object_states[];
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.