Lines Matching +full:volume +full:- +full:keys +full:- +full:pins

1 .. SPDX-License-Identifier: GPL-2.0
16  (3) Cookies have keys that distinguish them from their peers.
30 	 (2) Volume registration
48 cookie, hereafter referred to as "volume cookies" and "cookies".
50 A network filesystem acquires a volume cookie for a volume using a volume key,
51 which represents all the information that defines that volume (e.g. cell name
52 or server address, volume ID or share name).  This must be rendered as a
58 A filesystem would typically have a volume cookie for each superblock.
60 The filesystem then acquires a cookie for each file within that volume using an
61 object key.  Object keys are binary blobs and only need to be unique within
62 their parent volume.  The cache backend is responsible for rendering the binary
83 extra pins into the cache to stop cache withdrawal from tearing down the
91 Volume Registration
94 The first step for a network filesystem is to acquire a volume cookie for the
95 volume it wants to access::
103 This function creates a volume cookie with the specified volume key as its name
106 The volume key must be a printable string with no '/' characters in it.  It
108 characters.  It should uniquely represent the volume and will be matched with
118 is provided.  If the coherency data doesn't match, the entire cache volume will
121 This function can return errors such as EBUSY if the volume key is already in
122 use by an acquired volume or ENOMEM if an allocation failure occurred.  It may
123 also return a NULL volume cookie if fscache is not enabled.  It is safe to
124 pass a NULL cookie to any function that takes a volume cookie.  This will
128 When the network filesystem has finished with a volume, it should relinquish it
131 	void fscache_relinquish_volume(struct fscache_volume *volume,
135 This will cause the volume to be committed or removed, and if sealed the
137 must match the length specified when the volume was acquired.  Note that all
138 data cookies obtained in this volume must be relinquished before the volume is
145 Once it has a volume cookie, a network filesystem can use it to acquire a
149 	fscache_acquire_cookie(struct fscache_volume *volume,
157 This creates the cookie in the volume using the specified index key.  The index
158 key is a binary blob of the given length and must be unique for the volume.
174 volume cookie and pass the NULL cookie returned to any function that takes it.
188 Marking A Cookie In-Use
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.
231 The caller must have first marked the cookie in-use.  The cookie and the new
233 be called from ``->setattr()`` inode operation under the inode lock.
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
307 of a remote third-party change - at which point the filesystem has to throw
320 reads to fail with -ESTALE, sets the coherency data and file size from the
328 Write-Back Resource Management
339    in-use is held on the cookie for this inode.  It can only be changed if the
379 (presumably due to an already in-progress operation).  This prevents multiple
452 .. kernel-doc:: include/linux/fscache.h