Lines Matching full:it
63 blob into something it can use and may employ hash tables, trees or whatever to
67 A filesystem would typically have a cookie for each inode, and would acquire it
68 in iget and relinquish it when evicting the cookie.
70 Once it has a cookie, the filesystem needs to mark the cookie as being in use.
76 unuse it in file release and it needs to use the cookie around calls to
77 truncate the cookie locally. It *also* needs to use the cookie when the
78 pagecache becomes dirty and unuse it when writeback is complete. This is
79 slightly tricky, and provision is made for it.
88 actually required and it can use the fscache I/O API directly.
95 volume it wants to access::
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
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.
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
128 When the network filesystem has finished with a volume, it should relinquish it
145 Once it has a volume cookie, a network filesystem can use it to acquire a
164 of size aux_data_len will be allocated and the coherency data copied in. It is
172 This function never returns an error, though it may return a NULL cookie on
173 allocation failure or if fscache is not enabled. It is safe to pass in a NULL
174 volume cookie and pass the NULL cookie returned to any function that takes it.
178 When the network filesystem has finished with a cookie, it should relinquish it
185 delete it.
192 tell fscache when it intends to use the cookie (typically done on file open)
193 and should say when it has finished with it (typically on file close)::
201 The *use* function tells fscache that it will use the cookie and, additionally,
203 done, this will trigger the cache backend to go and gather the resources it
208 It optionally updates the stored coherency data and object size and then
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
219 in-use, it must be unused.
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
266 The read function also takes a parameter to indicate how it should handle a
268 it, skip over an initial hole and place zeros in the buffer or give an error.
279 operation will be run synchronously. Note that in the asynchronous case, it is
305 Sometimes it will be necessary to invalidate an object that contains data.
308 away the state and cached data that it had for an file and reload from the
324 Invalidation runs asynchronously in a worker thread so that it doesn't block
333 instance when the page is marked dirty) as it's not possible to open a file in
339 in-use is held on the cookie for this inode. It can only be changed if the
359 set, it sets that flag and increments the use count on the cookie (the caller
363 ``write_inode`` superblock operation. It cleans up after writing by unusing
367 superblock operation. It must be called *after*
369 up any hanging ``I_PINNING_FSCACHE_WB``. It also allows the coherency data to
376 If a network filesystem has locally modified data that it wants to write to the
377 cache, it needs to mark the pages to indicate that a write is in progress, and
378 if the mark is already present, it needs to wait for it to be removed first
413 going to be written (it doesn't have to align to page boundaries necessarily,
414 but it does have to align to DIO boundaries on the backing filesystem). The
431 object we've just created. It knows it doesn't have to do any reading until it
432 has done a write and then the page it wrote from has been released by the VM,
433 after which it *has* to look in the cache.