Lines Matching +full:cache +full:- +full:block

1 .. SPDX-License-Identifier: GPL-2.0
10  (1) A cache is logically organised into volumes and data storage objects
18  (4) Cookies have coherency data that allows a cache to determine if the
55 maximum size of a filename component (allowing the cache backend one char for
62 their parent volume.  The cache backend is responsible for rendering the binary
71 This causes fscache to send the cache backend off to look up/create resources
83 extra pins into the cache to stop cache withdrawal from tearing down the
87 The filesystem is expected to use netfslib to access the cache, but that's not
109 what's stored in the cache.
111 The caller may also specify the name of the cache to use.  If specified,
112 fscache will look up or create a cache cookie of that name and will use a cache
113 of that name if it is online or comes online.  If no cache name is specified,
114 it will use the first cache that comes to hand and set the name to that.
118 is provided.  If the coherency data doesn't match, the entire cache volume will
166 check the validity of data in the cache.  Functions are provided by which the
188 Marking A Cookie In-Use
203 done, this will trigger the cache backend to go and gather the resources it
204 needs to access/store data in the cache.  This is done in the background, and
209 decreases the in-use counter.  When the last user unuses the cookie, it is
213 A cookie must be marked in-use before it can be accessed for read, write or
214 resize - and an in-use mark must be kept whilst there is dirty data in the
218 Note that in-use marks are cumulative.  For each time a cookie is marked
219 in-use, it must be unused.
226 should be called to notify the cache::
231 The caller must have first marked the cookie in-use.  The cookie and the new
232 size are passed in and the cache is synchronously resized.  This is expected to
233 be called from ``->setattr()`` inode operation under the inode lock.
257 the cache resources block from the cookie.  Assuming it doesn't return an error
258 (for instance, it will return -ENOBUFS if given a NULL cookie, but otherwise do
261 The *read* and *write* functions initiate a direct-IO operation.  Both take the
262 previously set up cache resources block, an indication of the start file
307 of a remote third-party change - at which point the filesystem has to throw
311 To indicate that a cache object should be invalidated, the following should be
320 reads to fail with -ESTALE, sets the coherency data and file size from the
321 information supplied, blocks new I/O on the cookie and dispatches the cache to
324 Invalidation runs asynchronously in a worker thread so that it doesn't block
328 Write-Back Resource Management
331 To write data to the cache from network filesystem writeback, the cache
339    in-use is held on the cookie for this inode.  It can only be changed if the
377 cache, it needs to mark the pages to indicate that a write is in progress, and
379 (presumably due to an already in-progress operation).  This prevents multiple
380 competing DIO writes to the same storage in the cache.
419 the cache object to be written to, i_size indicates the size of the netfs file
430 Fscache keeps track of whether we have any data in the cache yet for a cache
433 after which it *has* to look in the cache.
435 To inform fscache that a page might now be in the cache, the following function
452 .. kernel-doc:: include/linux/fscache.h