36c9559022
Implement the cache object management state machine.
The following documentation is added to illuminate the working of this state
machine. It will also be added as:
Documentation/filesystems/caching/object.txt
====================================================
IN-KERNEL CACHE OBJECT REPRESENTATION AND MANAGEMENT
====================================================
==============
REPRESENTATION
==============
FS-Cache maintains an in-kernel representation of each object that a netfs is
currently interested in. Such objects are represented by the fscache_cookie
struct and are referred to as cookies.
FS-Cache also maintains a separate in-kernel representation of the objects that
a cache backend is currently actively caching. Such objects are represented by
the fscache_object struct. The cache backends allocate these upon request, and
are expected to embed them in their own representations. These are referred to
as objects.
There is a 1:N relationship between cookies and objects. A cookie may be
represented by multiple objects - an index may exist in more than one cache -
or even by no objects (it may not be cached).
Furthermore, both cookies and objects are hierarchical. The two hierarchies
correspond, but the cookies tree is a superset of the union of the object trees
of multiple caches:
NETFS INDEX TREE : CACHE 1 : CACHE 2
: :
: +-----------+ :
+----------->| IObject | :
+-----------+ | : +-----------+ :
| ICookie |-------+ : | :
+-----------+ | : | : +-----------+
| +------------------------------>| IObject |
| : | : +-----------+
| : V : |
| : +-----------+ : |
V +----------->| IObject | : |
+-----------+ | : +-----------+ : |
| ICookie |-------+ : | : V
+-----------+ | : | : +-----------+
| +------------------------------>| IObject |
+-----+-----+ : | : +-----------+
| | : | : |
V | : V : |
+-----------+ | : +-----------+ : |
| ICookie |------------------------->| IObject | : |
+-----------+ | : +-----------+ : |
| V : | : V
| +-----------+ : | : +-----------+
| | ICookie |-------------------------------->| IObject |
| +-----------+ : | : +-----------+
V | : V : |
+-----------+ | : +-----------+ : |
| DCookie |------------------------->| DObject | : |
+-----------+ | : +-----------+ : |
| : : |
+-------+-------+ : : |
| | : : |
V V : : V
+-----------+ +-----------+ : : +-----------+
| DCookie | | DCookie |------------------------>| DObject |
+-----------+ +-----------+ : : +-----------+
: :
In the above illustration, ICookie and IObject represent indices and DCookie
and DObject represent data storage objects. Indices may have representation in
multiple caches, but currently, non-index objects may not. Objects of any type
may also be entirely unrepresented.
As far as the netfs API goes, the netfs is only actually permitted to see
pointers to the cookies. The cookies themselves and any objects attached to
those cookies are hidden from it.
===============================
OBJECT MANAGEMENT STATE MACHINE
===============================
Within FS-Cache, each active object is managed by its own individual state
machine. The state for an object is kept in the fscache_object struct, in
object->state. A cookie may point to a set of objects that are in different
states.
Each state has an action associated with it that is invoked when the machine
wakes up in that state. There are four logical sets of states:
(1) Preparation: states that wait for the parent objects to become ready. The
representations are hierarchical, and it is expected that an object must
be created or accessed with respect to its parent object.
(2) Initialisation: states that perform lookups in the cache and validate
what's found and that create on disk any missing metadata.
(3) Normal running: states that allow netfs operations on objects to proceed
and that update the state of objects.
(4) Termination: states that detach objects from their netfs cookies, that
delete objects from disk, that handle disk and system errors and that free
up in-memory resources.
In most cases, transitioning between states is in response to signalled events.
When a state has finished processing, it will usually set the mask of events in
which it is interested (object->event_mask) and relinquish the worker thread.
Then when an event is raised (by calling fscache_raise_event()), if the event
is not masked, the object will be queued for processing (by calling
fscache_enqueue_object()).
PROVISION OF CPU TIME
---------------------
The work to be done by the various states is given CPU time by the threads of
the slow work facility (see Documentation/slow-work.txt). This is used in
preference to the workqueue facility because:
(1) Threads may be completely occupied for very long periods of time by a
particular work item. These state actions may be doing sequences of
synchronous, journalled disk accesses (lookup, mkdir, create, setxattr,
getxattr, truncate, unlink, rmdir, rename).
(2) Threads may do little actual work, but may rather spend a lot of time
sleeping on I/O. This means that single-threaded and 1-per-CPU-threaded
workqueues don't necessarily have the right numbers of threads.
LOCKING SIMPLIFICATION
----------------------
Because only one worker thread may be operating on any particular object's
state machine at once, this simplifies the locking, particularly with respect
to disconnecting the netfs's representation of a cache object (fscache_cookie)
from the cache backend's representation (fscache_object) - which may be
requested from either end.
=================
THE SET OF STATES
=================
The object state machine has a set of states that it can be in. There are
preparation states in which the object sets itself up and waits for its parent
object to transit to a state that allows access to its children:
(1) State FSCACHE_OBJECT_INIT.
Initialise the object and wait for the parent object to become active. In
the cache, it is expected that it will not be possible to look an object
up from the parent object, until that parent object itself has been looked
up.
There are initialisation states in which the object sets itself up and accesses
disk for the object metadata:
(2) State FSCACHE_OBJECT_LOOKING_UP.
Look up the object on disk, using the parent as a starting point.
FS-Cache expects the cache backend to probe the cache to see whether this
object is represented there, and if it is, to see if it's valid (coherency
management).
The cache should call fscache_object_lookup_negative() to indicate lookup
failure for whatever reason, and should call fscache_obtained_object() to
indicate success.
At the completion of lookup, FS-Cache will let the netfs go ahead with
read operations, no matter whether the file is yet cached. If not yet
cached, read operations will be immediately rejected with ENODATA until
the first known page is uncached - as to that point there can be no data
to be read out of the cache for that file that isn't currently also held
in the pagecache.
(3) State FSCACHE_OBJECT_CREATING.
Create an object on disk, using the parent as a starting point. This
happens if the lookup failed to find the object, or if the object's
coherency data indicated what's on disk is out of date. In this state,
FS-Cache expects the cache to create
The cache should call fscache_obtained_object() if creation completes
successfully, fscache_object_lookup_negative() otherwise.
At the completion of creation, FS-Cache will start processing write
operations the netfs has queued for an object. If creation failed, the
write ops will be transparently discarded, and nothing recorded in the
cache.
There are some normal running states in which the object spends its time
servicing netfs requests:
(4) State FSCACHE_OBJECT_AVAILABLE.
A transient state in which pending operations are started, child objects
are permitted to advance from FSCACHE_OBJECT_INIT state, and temporary
lookup data is freed.
(5) State FSCACHE_OBJECT_ACTIVE.
The normal running state. In this state, requests the netfs makes will be
passed on to the cache.
(6) State FSCACHE_OBJECT_UPDATING.
The state machine comes here to update the object in the cache from the
netfs's records. This involves updating the auxiliary data that is used
to maintain coherency.
And there are terminal states in which an object cleans itself up, deallocates
memory and potentially deletes stuff from disk:
(7) State FSCACHE_OBJECT_LC_DYING.
The object comes here if it is dying because of a lookup or creation
error. This would be due to a disk error or system error of some sort.
Temporary data is cleaned up, and the parent is released.
(8) State FSCACHE_OBJECT_DYING.
The object comes here if it is dying due to an error, because its parent
cookie has been relinquished by the netfs or because the cache is being
withdrawn.
Any child objects waiting on this one are given CPU time so that they too
can destroy themselves. This object waits for all its children to go away
before advancing to the next state.
(9) State FSCACHE_OBJECT_ABORT_INIT.
The object comes to this state if it was waiting on its parent in
FSCACHE_OBJECT_INIT, but its parent died. The object will destroy itself
so that the parent may proceed from the FSCACHE_OBJECT_DYING state.
(10) State FSCACHE_OBJECT_RELEASING.
(11) State FSCACHE_OBJECT_RECYCLING.
The object comes to one of these two states when dying once it is rid of
all its children, if it is dying because the netfs relinquished its
cookie. In the first state, the cached data is expected to persist, and
in the second it will be deleted.
(12) State FSCACHE_OBJECT_WITHDRAWING.
The object transits to this state if the cache decides it wants to
withdraw the object from service, perhaps to make space, but also due to
error or just because the whole cache is being withdrawn.
(13) State FSCACHE_OBJECT_DEAD.
The object transits to this state when the in-memory object record is
ready to be deleted. The object processor shouldn't ever see an object in
this state.
THE SET OF EVENTS
-----------------
There are a number of events that can be raised to an object state machine:
(*) FSCACHE_OBJECT_EV_UPDATE
The netfs requested that an object be updated. The state machine will ask
the cache backend to update the object, and the cache backend will ask the
netfs for details of the change through its cookie definition ops.
(*) FSCACHE_OBJECT_EV_CLEARED
This is signalled in two circumstances:
(a) when an object's last child object is dropped and
(b) when the last operation outstanding on an object is completed.
This is used to proceed from the dying state.
(*) FSCACHE_OBJECT_EV_ERROR
This is signalled when an I/O error occurs during the processing of some
object.
(*) FSCACHE_OBJECT_EV_RELEASE
(*) FSCACHE_OBJECT_EV_RETIRE
These are signalled when the netfs relinquishes a cookie it was using.
The event selected depends on whether the netfs asks for the backing
object to be retired (deleted) or retained.
(*) FSCACHE_OBJECT_EV_WITHDRAW
This is signalled when the cache backend wants to withdraw an object.
This means that the object will have to be detached from the netfs's
cookie.
Because the withdrawing releasing/retiring events are all handled by the object
state machine, it doesn't matter if there's a collision with both ends trying
to sever the connection at the same time. The state machine can just pick
which one it wants to honour, and that effects the other.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Steve Dickson <steved@redhat.com>
Acked-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Tested-by: Daire Byrne <Daire.Byrne@framestore.com>
334 lines
14 KiB
Plaintext
334 lines
14 KiB
Plaintext
==========================
|
|
General Filesystem Caching
|
|
==========================
|
|
|
|
========
|
|
OVERVIEW
|
|
========
|
|
|
|
This facility is a general purpose cache for network filesystems, though it
|
|
could be used for caching other things such as ISO9660 filesystems too.
|
|
|
|
FS-Cache mediates between cache backends (such as CacheFS) and network
|
|
filesystems:
|
|
|
|
+---------+
|
|
| | +--------------+
|
|
| NFS |--+ | |
|
|
| | | +-->| CacheFS |
|
|
+---------+ | +----------+ | | /dev/hda5 |
|
|
| | | | +--------------+
|
|
+---------+ +-->| | |
|
|
| | | |--+
|
|
| AFS |----->| FS-Cache |
|
|
| | | |--+
|
|
+---------+ +-->| | |
|
|
| | | | +--------------+
|
|
+---------+ | +----------+ | | |
|
|
| | | +-->| CacheFiles |
|
|
| ISOFS |--+ | /var/cache |
|
|
| | +--------------+
|
|
+---------+
|
|
|
|
Or to look at it another way, FS-Cache is a module that provides a caching
|
|
facility to a network filesystem such that the cache is transparent to the
|
|
user:
|
|
|
|
+---------+
|
|
| |
|
|
| Server |
|
|
| |
|
|
+---------+
|
|
| NETWORK
|
|
~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
| +----------+
|
|
V | |
|
|
+---------+ | |
|
|
| | | |
|
|
| NFS |----->| FS-Cache |
|
|
| | | |--+
|
|
+---------+ | | | +--------------+ +--------------+
|
|
| | | | | | | |
|
|
V +----------+ +-->| CacheFiles |-->| Ext3 |
|
|
+---------+ | /var/cache | | /dev/sda6 |
|
|
| | +--------------+ +--------------+
|
|
| VFS | ^ ^
|
|
| | | |
|
|
+---------+ +--------------+ |
|
|
| KERNEL SPACE | |
|
|
~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~|~~~~
|
|
| USER SPACE | |
|
|
V | |
|
|
+---------+ +--------------+
|
|
| | | |
|
|
| Process | | cachefilesd |
|
|
| | | |
|
|
+---------+ +--------------+
|
|
|
|
|
|
FS-Cache does not follow the idea of completely loading every netfs file
|
|
opened in its entirety into a cache before permitting it to be accessed and
|
|
then serving the pages out of that cache rather than the netfs inode because:
|
|
|
|
(1) It must be practical to operate without a cache.
|
|
|
|
(2) The size of any accessible file must not be limited to the size of the
|
|
cache.
|
|
|
|
(3) The combined size of all opened files (this includes mapped libraries)
|
|
must not be limited to the size of the cache.
|
|
|
|
(4) The user should not be forced to download an entire file just to do a
|
|
one-off access of a small portion of it (such as might be done with the
|
|
"file" program).
|
|
|
|
It instead serves the cache out in PAGE_SIZE chunks as and when requested by
|
|
the netfs('s) using it.
|
|
|
|
|
|
FS-Cache provides the following facilities:
|
|
|
|
(1) More than one cache can be used at once. Caches can be selected
|
|
explicitly by use of tags.
|
|
|
|
(2) Caches can be added / removed at any time.
|
|
|
|
(3) The netfs is provided with an interface that allows either party to
|
|
withdraw caching facilities from a file (required for (2)).
|
|
|
|
(4) The interface to the netfs returns as few errors as possible, preferring
|
|
rather to let the netfs remain oblivious.
|
|
|
|
(5) Cookies are used to represent indices, files and other objects to the
|
|
netfs. The simplest cookie is just a NULL pointer - indicating nothing
|
|
cached there.
|
|
|
|
(6) The netfs is allowed to propose - dynamically - any index hierarchy it
|
|
desires, though it must be aware that the index search function is
|
|
recursive, stack space is limited, and indices can only be children of
|
|
indices.
|
|
|
|
(7) Data I/O is done direct to and from the netfs's pages. The netfs
|
|
indicates that page A is at index B of the data-file represented by cookie
|
|
C, and that it should be read or written. The cache backend may or may
|
|
not start I/O on that page, but if it does, a netfs callback will be
|
|
invoked to indicate completion. The I/O may be either synchronous or
|
|
asynchronous.
|
|
|
|
(8) Cookies can be "retired" upon release. At this point FS-Cache will mark
|
|
them as obsolete and the index hierarchy rooted at that point will get
|
|
recycled.
|
|
|
|
(9) The netfs provides a "match" function for index searches. In addition to
|
|
saying whether a match was made or not, this can also specify that an
|
|
entry should be updated or deleted.
|
|
|
|
(10) As much as possible is done asynchronously.
|
|
|
|
|
|
FS-Cache maintains a virtual indexing tree in which all indices, files, objects
|
|
and pages are kept. Bits of this tree may actually reside in one or more
|
|
caches.
|
|
|
|
FSDEF
|
|
|
|
|
+------------------------------------+
|
|
| |
|
|
NFS AFS
|
|
| |
|
|
+--------------------------+ +-----------+
|
|
| | | |
|
|
homedir mirror afs.org redhat.com
|
|
| | |
|
|
+------------+ +---------------+ +----------+
|
|
| | | | | |
|
|
00001 00002 00007 00125 vol00001 vol00002
|
|
| | | | |
|
|
+---+---+ +-----+ +---+ +------+------+ +-----+----+
|
|
| | | | | | | | | | | | |
|
|
PG0 PG1 PG2 PG0 XATTR PG0 PG1 DIRENT DIRENT DIRENT R/W R/O Bak
|
|
| |
|
|
PG0 +-------+
|
|
| |
|
|
00001 00003
|
|
|
|
|
+---+---+
|
|
| | |
|
|
PG0 PG1 PG2
|
|
|
|
In the example above, you can see two netfs's being backed: NFS and AFS. These
|
|
have different index hierarchies:
|
|
|
|
(*) The NFS primary index contains per-server indices. Each server index is
|
|
indexed by NFS file handles to get data file objects. Each data file
|
|
objects can have an array of pages, but may also have further child
|
|
objects, such as extended attributes and directory entries. Extended
|
|
attribute objects themselves have page-array contents.
|
|
|
|
(*) The AFS primary index contains per-cell indices. Each cell index contains
|
|
per-logical-volume indices. Each of volume index contains up to three
|
|
indices for the read-write, read-only and backup mirrors of those volumes.
|
|
Each of these contains vnode data file objects, each of which contains an
|
|
array of pages.
|
|
|
|
The very top index is the FS-Cache master index in which individual netfs's
|
|
have entries.
|
|
|
|
Any index object may reside in more than one cache, provided it only has index
|
|
children. Any index with non-index object children will be assumed to only
|
|
reside in one cache.
|
|
|
|
|
|
The netfs API to FS-Cache can be found in:
|
|
|
|
Documentation/filesystems/caching/netfs-api.txt
|
|
|
|
The cache backend API to FS-Cache can be found in:
|
|
|
|
Documentation/filesystems/caching/backend-api.txt
|
|
|
|
A description of the internal representations and object state machine can be
|
|
found in:
|
|
|
|
Documentation/filesystems/caching/object.txt
|
|
|
|
|
|
=======================
|
|
STATISTICAL INFORMATION
|
|
=======================
|
|
|
|
If FS-Cache is compiled with the following options enabled:
|
|
|
|
CONFIG_FSCACHE_STATS=y
|
|
CONFIG_FSCACHE_HISTOGRAM=y
|
|
|
|
then it will gather certain statistics and display them through a number of
|
|
proc files.
|
|
|
|
(*) /proc/fs/fscache/stats
|
|
|
|
This shows counts of a number of events that can happen in FS-Cache:
|
|
|
|
CLASS EVENT MEANING
|
|
======= ======= =======================================================
|
|
Cookies idx=N Number of index cookies allocated
|
|
dat=N Number of data storage cookies allocated
|
|
spc=N Number of special cookies allocated
|
|
Objects alc=N Number of objects allocated
|
|
nal=N Number of object allocation failures
|
|
avl=N Number of objects that reached the available state
|
|
ded=N Number of objects that reached the dead state
|
|
ChkAux non=N Number of objects that didn't have a coherency check
|
|
ok=N Number of objects that passed a coherency check
|
|
upd=N Number of objects that needed a coherency data update
|
|
obs=N Number of objects that were declared obsolete
|
|
Pages mrk=N Number of pages marked as being cached
|
|
unc=N Number of uncache page requests seen
|
|
Acquire n=N Number of acquire cookie requests seen
|
|
nul=N Number of acq reqs given a NULL parent
|
|
noc=N Number of acq reqs rejected due to no cache available
|
|
ok=N Number of acq reqs succeeded
|
|
nbf=N Number of acq reqs rejected due to error
|
|
oom=N Number of acq reqs failed on ENOMEM
|
|
Lookups n=N Number of lookup calls made on cache backends
|
|
neg=N Number of negative lookups made
|
|
pos=N Number of positive lookups made
|
|
crt=N Number of objects created by lookup
|
|
Updates n=N Number of update cookie requests seen
|
|
nul=N Number of upd reqs given a NULL parent
|
|
run=N Number of upd reqs granted CPU time
|
|
Relinqs n=N Number of relinquish cookie requests seen
|
|
nul=N Number of rlq reqs given a NULL parent
|
|
wcr=N Number of rlq reqs waited on completion of creation
|
|
AttrChg n=N Number of attribute changed requests seen
|
|
ok=N Number of attr changed requests queued
|
|
nbf=N Number of attr changed rejected -ENOBUFS
|
|
oom=N Number of attr changed failed -ENOMEM
|
|
run=N Number of attr changed ops given CPU time
|
|
Allocs n=N Number of allocation requests seen
|
|
ok=N Number of successful alloc reqs
|
|
wt=N Number of alloc reqs that waited on lookup completion
|
|
nbf=N Number of alloc reqs rejected -ENOBUFS
|
|
ops=N Number of alloc reqs submitted
|
|
owt=N Number of alloc reqs waited for CPU time
|
|
Retrvls n=N Number of retrieval (read) requests seen
|
|
ok=N Number of successful retr reqs
|
|
wt=N Number of retr reqs that waited on lookup completion
|
|
nod=N Number of retr reqs returned -ENODATA
|
|
nbf=N Number of retr reqs rejected -ENOBUFS
|
|
int=N Number of retr reqs aborted -ERESTARTSYS
|
|
oom=N Number of retr reqs failed -ENOMEM
|
|
ops=N Number of retr reqs submitted
|
|
owt=N Number of retr reqs waited for CPU time
|
|
Stores n=N Number of storage (write) requests seen
|
|
ok=N Number of successful store reqs
|
|
agn=N Number of store reqs on a page already pending storage
|
|
nbf=N Number of store reqs rejected -ENOBUFS
|
|
oom=N Number of store reqs failed -ENOMEM
|
|
ops=N Number of store reqs submitted
|
|
run=N Number of store reqs granted CPU time
|
|
Ops pend=N Number of times async ops added to pending queues
|
|
run=N Number of times async ops given CPU time
|
|
enq=N Number of times async ops queued for processing
|
|
dfr=N Number of async ops queued for deferred release
|
|
rel=N Number of async ops released
|
|
gc=N Number of deferred-release async ops garbage collected
|
|
|
|
|
|
(*) /proc/fs/fscache/histogram
|
|
|
|
cat /proc/fs/fscache/histogram
|
|
JIFS SECS OBJ INST OP RUNS OBJ RUNS RETRV DLY RETRIEVLS
|
|
===== ===== ========= ========= ========= ========= =========
|
|
|
|
This shows the breakdown of the number of times each amount of time
|
|
between 0 jiffies and HZ-1 jiffies a variety of tasks took to run. The
|
|
columns are as follows:
|
|
|
|
COLUMN TIME MEASUREMENT
|
|
======= =======================================================
|
|
OBJ INST Length of time to instantiate an object
|
|
OP RUNS Length of time a call to process an operation took
|
|
OBJ RUNS Length of time a call to process an object event took
|
|
RETRV DLY Time between an requesting a read and lookup completing
|
|
RETRIEVLS Time between beginning and end of a retrieval
|
|
|
|
Each row shows the number of events that took a particular range of times.
|
|
Each step is 1 jiffy in size. The JIFS column indicates the particular
|
|
jiffy range covered, and the SECS field the equivalent number of seconds.
|
|
|
|
|
|
=========
|
|
DEBUGGING
|
|
=========
|
|
|
|
If CONFIG_FSCACHE_DEBUG is enabled, the FS-Cache facility can have runtime
|
|
debugging enabled by adjusting the value in:
|
|
|
|
/sys/module/fscache/parameters/debug
|
|
|
|
This is a bitmask of debugging streams to enable:
|
|
|
|
BIT VALUE STREAM POINT
|
|
======= ======= =============================== =======================
|
|
0 1 Cache management Function entry trace
|
|
1 2 Function exit trace
|
|
2 4 General
|
|
3 8 Cookie management Function entry trace
|
|
4 16 Function exit trace
|
|
5 32 General
|
|
6 64 Page handling Function entry trace
|
|
7 128 Function exit trace
|
|
8 256 General
|
|
9 512 Operation management Function entry trace
|
|
10 1024 Function exit trace
|
|
11 2048 General
|
|
|
|
The appropriate set of values should be OR'd together and the result written to
|
|
the control file. For example:
|
|
|
|
echo $((1|8|64)) >/sys/module/fscache/parameters/debug
|
|
|
|
will turn on all function entry debugging.
|