)]}' { "log": [ { "commit": "8b8edefa2fffbff97f9eec8b70e78ae23abad1a0", "tree": "7f0efac8adb9c9ed7be8af63e51510954f1c51dc", "parents": [ "e120153ddf8620fd0a194d301e9c5a8b28483bb5" ], "author": { "name": "Tejun Heo", "email": "tj@kernel.org", "time": "Tue Jul 20 22:09:01 2010 +0200" }, "committer": { "name": "Tejun Heo", "email": "tj@kernel.org", "time": "Thu Jul 22 22:58:34 2010 +0200" }, "message": "fscache: convert object to use workqueue instead of slow-work\n\nMake fscache object state transition callbacks use workqueue instead\nof slow-work. New dedicated unbound CPU workqueue fscache_object_wq\nis created. get/put callbacks are renamed and modified to take\n@object and called directly from the enqueue wrapper and the work\nfunction. While at it, make all open coded instances of get/put to\nuse fscache_get/put_object().\n\n* Unbound workqueue is used.\n\n* work_busy() output is printed instead of slow-work flags in object\n debugging outputs. They mean basically the same thing bit-for-bit.\n\n* sysctl fscache.object_max_active added to control concurrency. The\n default value is nr_cpus clamped between 4 and\n WQ_UNBOUND_MAX_ACTIVE.\n\n* slow_work_sleep_till_thread_needed() is replaced with fscache\n private implementation fscache_object_sleep_till_congested() which\n waits on fscache_object_wq congestion.\n\n* debugfs support is dropped for now. Tracing API based debug\n facility is planned to be added.\n\nSigned-off-by: Tejun Heo \u003ctj@kernel.org\u003e\nAcked-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "fee096deb4f33897937b974cb2c5168bab7935be", "tree": "c86e5ed5b3435ff0f0266f343b19f8cc7be63340", "parents": [ "d0e27b7808dc667f3015be0b6888f6d680e222c8" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:12:05 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:12:05 2009 +0000" }, "message": "CacheFiles: Catch an overly long wait for an old active object\n\nCatch an overly long wait for an old, dying active object when we want to\nreplace it with a new one. The probability is that all the slow-work threads\nare hogged, and the delete can\u0027t get a look in.\n\nWhat we do instead is:\n\n (1) if there\u0027s nothing in the slow work queue, we sleep until either the dying\n object has finished dying or there is something in the slow work queue\n behind which we can queue our object.\n\n (2) if there is something in the slow work queue, we return ETIMEDOUT to\n fscache_lookup_object(), which then puts us back on the slow work queue,\n presumably behind the deletion that we\u0027re blocked by. We are then\n deferred for a while until we work our way back through the queue -\n without blocking a slow-work thread unnecessarily.\n\nA backtrace similar to the following may appear in the log without this patch:\n\n\tINFO: task kslowd004:5711 blocked for more than 120 seconds.\n\t\"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n\tkslowd004 D 0000000000000000 0 5711 2 0x00000080\n\t ffff88000340bb80 0000000000000046 ffff88002550d000 0000000000000000\n\t ffff88002550d000 0000000000000007 ffff88000340bfd8 ffff88002550d2a8\n\t 000000000000ddf0 00000000000118c0 00000000000118c0 ffff88002550d2a8\n\tCall Trace:\n\t [\u003cffffffff81058e21\u003e] ? trace_hardirqs_on+0xd/0xf\n\t [\u003cffffffffa011c4d8\u003e] ? cachefiles_wait_bit+0x0/0xd [cachefiles]\n\t [\u003cffffffffa011c4e1\u003e] cachefiles_wait_bit+0x9/0xd [cachefiles]\n\t [\u003cffffffff81353153\u003e] __wait_on_bit+0x43/0x76\n\t [\u003cffffffff8111ae39\u003e] ? ext3_xattr_get+0x1ec/0x270\n\t [\u003cffffffff813531ef\u003e] out_of_line_wait_on_bit+0x69/0x74\n\t [\u003cffffffffa011c4d8\u003e] ? cachefiles_wait_bit+0x0/0xd [cachefiles]\n\t [\u003cffffffff8104c125\u003e] ? wake_bit_function+0x0/0x2e\n\t [\u003cffffffffa011bc79\u003e] cachefiles_mark_object_active+0x203/0x23b [cachefiles]\n\t [\u003cffffffffa011c209\u003e] cachefiles_walk_to_object+0x558/0x827 [cachefiles]\n\t [\u003cffffffffa011a429\u003e] cachefiles_lookup_object+0xac/0x12a [cachefiles]\n\t [\u003cffffffffa00aa1e9\u003e] fscache_lookup_object+0x1c7/0x214 [fscache]\n\t [\u003cffffffffa00aafc5\u003e] fscache_object_state_machine+0xa5/0x52d [fscache]\n\t [\u003cffffffffa00ab4ac\u003e] fscache_object_slow_work_execute+0x5f/0xa0 [fscache]\n\t [\u003cffffffff81082093\u003e] slow_work_execute+0x18f/0x2d1\n\t [\u003cffffffff8108239a\u003e] slow_work_thread+0x1c5/0x308\n\t [\u003cffffffff8104c0f1\u003e] ? autoremove_wake_function+0x0/0x34\n\t [\u003cffffffff810821d5\u003e] ? slow_work_thread+0x0/0x308\n\t [\u003cffffffff8104be91\u003e] kthread+0x7a/0x82\n\t [\u003cffffffff8100beda\u003e] child_rip+0xa/0x20\n\t [\u003cffffffff8100b87c\u003e] ? restore_args+0x0/0x30\n\t [\u003cffffffff8104be17\u003e] ? kthread+0x0/0x82\n\t [\u003cffffffff8100bed0\u003e] ? child_rip+0x0/0x20\n\t1 lock held by kslowd004/5711:\n\t #0: (\u0026sb-\u003es_type-\u003ei_mutex_key#7/1){+.+.+.}, at: [\u003cffffffffa011be64\u003e] cachefiles_walk_to_object+0x1b3/0x827 [cachefiles]\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "60d543ca724be155c2b6166e36a00c80b21bd810", "tree": "90ec6edd77ddb7666dbf7069aa2e001f155cea49", "parents": [ "d461d26dde901b0523c46b0317e7fccf574a3933" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:45 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:45 2009 +0000" }, "message": "FS-Cache: Start processing an object\u0027s operations on that object\u0027s death\n\nStart processing an object\u0027s operations when that object moves into the DYING\nstate as the object cannot be destroyed until all its outstanding operations\nhave completed.\n\nFurthermore, make sure that read and allocation operations handle being woken\nup on a dead object. Such events are recorded in the Allocs.abt and\nRetrvls.abt statistics as viewable through /proc/fs/fscache/stats.\n\nThe code for waiting for object activation for the read and allocation\noperations is also extracted into its own function as it is much the same in\nall cases, differing only in the stats incremented.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "201a15428bd54f83eccec8b7c64a04b8f9431204", "tree": "326fcce64ce96657253fd141a3f4a767ac95418a", "parents": [ "e3d4d28b1c8cc7c26536a50b43d86ccd39878550" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:35 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:35 2009 +0000" }, "message": "FS-Cache: Handle pages pending storage that get evicted under OOM conditions\n\nHandle netfs pages that the vmscan algorithm wants to evict from the pagecache\nunder OOM conditions, but that are waiting for write to the cache. Under these\nconditions, vmscan calls the releasepage() function of the netfs, asking if a\npage can be discarded.\n\nThe problem is typified by the following trace of a stuck process:\n\n\tkslowd005 D 0000000000000000 0 4253 2 0x00000080\n\t ffff88001b14f370 0000000000000046 ffff880020d0d000 0000000000000007\n\t 0000000000000006 0000000000000001 ffff88001b14ffd8 ffff880020d0d2a8\n\t 000000000000ddf0 00000000000118c0 00000000000118c0 ffff880020d0d2a8\n\tCall Trace:\n\t [\u003cffffffffa00782d8\u003e] __fscache_wait_on_page_write+0x8b/0xa7 [fscache]\n\t [\u003cffffffff8104c0f1\u003e] ? autoremove_wake_function+0x0/0x34\n\t [\u003cffffffffa0078240\u003e] ? __fscache_check_page_write+0x63/0x70 [fscache]\n\t [\u003cffffffffa00b671d\u003e] nfs_fscache_release_page+0x4e/0xc4 [nfs]\n\t [\u003cffffffffa00927f0\u003e] nfs_release_page+0x3c/0x41 [nfs]\n\t [\u003cffffffff810885d3\u003e] try_to_release_page+0x32/0x3b\n\t [\u003cffffffff81093203\u003e] shrink_page_list+0x316/0x4ac\n\t [\u003cffffffff8109372b\u003e] shrink_inactive_list+0x392/0x67c\n\t [\u003cffffffff813532fa\u003e] ? __mutex_unlock_slowpath+0x100/0x10b\n\t [\u003cffffffff81058df0\u003e] ? trace_hardirqs_on_caller+0x10c/0x130\n\t [\u003cffffffff8135330e\u003e] ? mutex_unlock+0x9/0xb\n\t [\u003cffffffff81093aa2\u003e] shrink_list+0x8d/0x8f\n\t [\u003cffffffff81093d1c\u003e] shrink_zone+0x278/0x33c\n\t [\u003cffffffff81052d6c\u003e] ? ktime_get_ts+0xad/0xba\n\t [\u003cffffffff81094b13\u003e] try_to_free_pages+0x22e/0x392\n\t [\u003cffffffff81091e24\u003e] ? isolate_pages_global+0x0/0x212\n\t [\u003cffffffff8108e743\u003e] __alloc_pages_nodemask+0x3dc/0x5cf\n\t [\u003cffffffff81089529\u003e] grab_cache_page_write_begin+0x65/0xaa\n\t [\u003cffffffff8110f8c0\u003e] ext3_write_begin+0x78/0x1eb\n\t [\u003cffffffff81089ec5\u003e] generic_file_buffered_write+0x109/0x28c\n\t [\u003cffffffff8103cb69\u003e] ? current_fs_time+0x22/0x29\n\t [\u003cffffffff8108a509\u003e] __generic_file_aio_write+0x350/0x385\n\t [\u003cffffffff8108a588\u003e] ? generic_file_aio_write+0x4a/0xae\n\t [\u003cffffffff8108a59e\u003e] generic_file_aio_write+0x60/0xae\n\t [\u003cffffffff810b2e82\u003e] do_sync_write+0xe3/0x120\n\t [\u003cffffffff8104c0f1\u003e] ? autoremove_wake_function+0x0/0x34\n\t [\u003cffffffff810b18e1\u003e] ? __dentry_open+0x1a5/0x2b8\n\t [\u003cffffffff810b1a76\u003e] ? dentry_open+0x82/0x89\n\t [\u003cffffffffa00e693c\u003e] cachefiles_write_page+0x298/0x335 [cachefiles]\n\t [\u003cffffffffa0077147\u003e] fscache_write_op+0x178/0x2c2 [fscache]\n\t [\u003cffffffffa0075656\u003e] fscache_op_execute+0x7a/0xd1 [fscache]\n\t [\u003cffffffff81082093\u003e] slow_work_execute+0x18f/0x2d1\n\t [\u003cffffffff8108239a\u003e] slow_work_thread+0x1c5/0x308\n\t [\u003cffffffff8104c0f1\u003e] ? autoremove_wake_function+0x0/0x34\n\t [\u003cffffffff810821d5\u003e] ? slow_work_thread+0x0/0x308\n\t [\u003cffffffff8104be91\u003e] kthread+0x7a/0x82\n\t [\u003cffffffff8100beda\u003e] child_rip+0xa/0x20\n\t [\u003cffffffff8100b87c\u003e] ? restore_args+0x0/0x30\n\t [\u003cffffffff8102ef83\u003e] ? tg_shares_up+0x171/0x227\n\t [\u003cffffffff8104be17\u003e] ? kthread+0x0/0x82\n\t [\u003cffffffff8100bed0\u003e] ? child_rip+0x0/0x20\n\nIn the above backtrace, the following is happening:\n\n (1) A page storage operation is being executed by a slow-work thread\n (fscache_write_op()).\n\n (2) FS-Cache farms the operation out to the cache to perform\n (cachefiles_write_page()).\n\n (3) CacheFiles is then calling Ext3 to perform the actual write, using Ext3\u0027s\n standard write (do_sync_write()) under KERNEL_DS directly from the netfs\n page.\n\n (4) However, for Ext3 to perform the write, it must allocate some memory, in\n particular, it must allocate at least one page cache page into which it\n can copy the data from the netfs page.\n\n (5) Under OOM conditions, the memory allocator can\u0027t immediately come up with\n a page, so it uses vmscan to find something to discard\n (try_to_free_pages()).\n\n (6) vmscan finds a clean netfs page it might be able to discard (possibly the\n one it\u0027s trying to write out).\n\n (7) The netfs is called to throw the page away (nfs_release_page()) - but it\u0027s\n called with __GFP_WAIT, so the netfs decides to wait for the store to\n complete (__fscache_wait_on_page_write()).\n\n (8) This blocks a slow-work processing thread - possibly against itself.\n\nThe system ends up stuck because it can\u0027t write out any netfs pages to the\ncache without allocating more memory.\n\nTo avoid this, we make FS-Cache cancel some writes that aren\u0027t in the middle of\nactually being performed. This means that some data won\u0027t make it into the\ncache this time. To support this, a new FS-Cache function is added\nfscache_maybe_release_page() that replaces what the netfs releasepage()\nfunctions used to do with respect to the cache.\n\nThe decisions fscache_maybe_release_page() makes are counted and displayed\nthrough /proc/fs/fscache/stats on a line labelled \"VmScan\". There are four\ncounters provided: \"nos\u003dN\" - pages that weren\u0027t pending storage; \"gon\u003dN\" -\npages that were pending storage when we first looked, but weren\u0027t by the time\nwe got the object lock; \"bsy\u003dN\" - pages that we ignored as they were actively\nbeing written when we looked; and \"can\u003dN\" - pages that we cancelled the storage\nof.\n\nWhat I\u0027d really like to do is alter the behaviour of the cancellation\nheuristics, depending on how necessary it is to expel pages. If there are\nplenty of other pages that aren\u0027t waiting to be written to the cache that\ncould be ejected first, then it would be nice to hold up on immediate\ncancellation of cache writes - but I don\u0027t see a way of doing that.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "e3d4d28b1c8cc7c26536a50b43d86ccd39878550", "tree": "23f6dacd5ffdf6c6d01c411517855a41405381b9", "parents": [ "285e728b0ac55b53a673114096168d6f74930167" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:32 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:32 2009 +0000" }, "message": "FS-Cache: Handle read request vs lookup, creation or other cache failure\n\nFS-Cache doesn\u0027t correctly handle the netfs requesting a read from the cache\non an object that failed or was withdrawn by the cache. A trace similar to\nthe following might be seen:\n\n\tCacheFiles: Lookup failed error -105\n\t[exe ] unexpected submission OP165afe [OBJ6cac OBJECT_LC_DYING]\n\t[exe ] objstate\u003dOBJECT_LC_DYING [OBJECT_LC_DYING]\n\t[exe ] objflags\u003d0\n\t[exe ] objevent\u003d9 [fffffffffffffffb]\n\t[exe ] ops\u003d0 inp\u003d0 exc\u003d0\n\tPid: 6970, comm: exe Not tainted 2.6.32-rc6-cachefs #50\n\tCall Trace:\n\t [\u003cffffffffa0076477\u003e] fscache_submit_op+0x3ff/0x45a [fscache]\n\t [\u003cffffffffa0077997\u003e] __fscache_read_or_alloc_pages+0x187/0x3c4 [fscache]\n\t [\u003cffffffffa00b6480\u003e] ? nfs_readpage_from_fscache_complete+0x0/0x66 [nfs]\n\t [\u003cffffffffa00b6388\u003e] __nfs_readpages_from_fscache+0x7e/0x176 [nfs]\n\t [\u003cffffffff8108e483\u003e] ? __alloc_pages_nodemask+0x11c/0x5cf\n\t [\u003cffffffffa009d796\u003e] nfs_readpages+0x114/0x1d7 [nfs]\n\t [\u003cffffffff81090314\u003e] __do_page_cache_readahead+0x15f/0x1ec\n\t [\u003cffffffff81090228\u003e] ? __do_page_cache_readahead+0x73/0x1ec\n\t [\u003cffffffff810903bd\u003e] ra_submit+0x1c/0x20\n\t [\u003cffffffff810906bb\u003e] ondemand_readahead+0x227/0x23a\n\t [\u003cffffffff81090762\u003e] page_cache_sync_readahead+0x17/0x19\n\t [\u003cffffffff8108a99e\u003e] generic_file_aio_read+0x236/0x5a0\n\t [\u003cffffffffa00937bd\u003e] nfs_file_read+0xe4/0xf3 [nfs]\n\t [\u003cffffffff810b2fa2\u003e] do_sync_read+0xe3/0x120\n\t [\u003cffffffff81354cc3\u003e] ? _spin_unlock_irq+0x2b/0x31\n\t [\u003cffffffff8104c0f1\u003e] ? autoremove_wake_function+0x0/0x34\n\t [\u003cffffffff811848e5\u003e] ? selinux_file_permission+0x5d/0x10f\n\t [\u003cffffffff81352bdb\u003e] ? thread_return+0x3e/0x101\n\t [\u003cffffffff8117d7b0\u003e] ? security_file_permission+0x11/0x13\n\t [\u003cffffffff810b3b06\u003e] vfs_read+0xaa/0x16f\n\t [\u003cffffffff81058df0\u003e] ? trace_hardirqs_on_caller+0x10c/0x130\n\t [\u003cffffffff810b3c84\u003e] sys_read+0x45/0x6c\n\t [\u003cffffffff8100ae2b\u003e] system_call_fastpath+0x16/0x1b\n\nThe object state might also be OBJECT_DYING or OBJECT_WITHDRAWING.\n\nThis should be handled by simply rejecting the new operation with ENOBUFS.\nThere\u0027s no need to log an error for it. Events of this type now appear in the\nstats file under Ops:rej.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "1bccf513ac49d44604ba1cddcc29f5886e70f1b6", "tree": "096ba75a3d02018c5f6e1857aaf1d41471733850", "parents": [ "6897e3df8fc37bd4a58bbcdef8306da7fc175584" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:25 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:25 2009 +0000" }, "message": "FS-Cache: Fix lock misorder in fscache_write_op()\n\nFS-Cache has two structs internally for keeping track of the internal state of\na cached file: the fscache_cookie struct, which represents the netfs\u0027s state,\nand fscache_object struct, which represents the cache\u0027s state. Each has a\npointer that points to the other (when both are in existence), and each has a\nspinlock for pointer maintenance.\n\nSince netfs operations approach these structures from the cookie side, they get\nthe cookie lock first, then the object lock. Cache operations, on the other\nhand, approach from the object side, and get the object lock first. It is not\nthen permitted for a cache operation to get the cookie lock whilst it is\nholding the object lock lest deadlock occur; instead, it must do one of two\nthings:\n\n (1) increment the cookie usage counter, drop the object lock and then get both\n locks in order, or\n\n (2) simply hold the object lock as certain parts of the cookie may not be\n altered whilst the object lock is held.\n\nIt is also not permitted to follow either pointer without holding the lock at\nthe end you start with. To break the pointers between the cookie and the\nobject, both locks must be held.\n\nfscache_write_op(), however, violates the locking rules: It attempts to get the\ncookie lock without (a) checking that the cookie pointer is a valid pointer,\nand (b) holding the object lock to protect the cookie pointer whilst it follows\nit. This is so that it can access the pending page store tree without\ninterference from __fscache_write_page().\n\nThis is fixed by splitting the cookie lock, such that the page store tracking\ntree is protected by its own lock, and checking that the cookie pointer is\nnon-NULL before we attempt to follow it whilst holding the object lock.\n\nThe new lock is subordinate to both the cookie lock and the object lock, and so\nshould be taken after those.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "5753c441889253e4323eee85f791a1d64cf08196", "tree": "55a0de053d0593d96e99710f978277df668412d1", "parents": [ "b34df792b4e9e311db47fad27949095d0629c197" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:19 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:19 2009 +0000" }, "message": "FS-Cache: Permit cache retrieval ops to be interrupted in the initial wait phase\n\nPermit the operations to retrieve data from the cache or to allocate space in\nthe cache for future writes to be interrupted whilst they\u0027re waiting for\npermission for the operation to proceed. Typically this wait occurs whilst the\ncache object is being looked up on disk in the background.\n\nIf an interruption occurs, and the operation has not yet been given the\ngo-ahead to run, the operation is dequeued and cancelled, and control returns\nto the read operation of the netfs routine with none of the requested pages\nhaving been read or in any way marked as known by the cache.\n\nThis means that the initial wait is done interruptibly rather than\nuninterruptibly.\n\nIn addition, extra stats values are made available to show the number of ops\ncancelled and the number of cache space allocations interrupted.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "52bd75fdb135d6133d878ae60c6e7e3f4ebc1cfc", "tree": "4fad4fa37ce533c520a4575e5b7df90e19c6a666", "parents": [ "4fbf4291aa15926cd4fdca0ffe9122e89d0459db" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:08 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:08 2009 +0000" }, "message": "FS-Cache: Add counters for entry/exit to/from cache operation functions\n\nCount entries to and exits from cache operation table functions. Maintain\nthese as a single counter that\u0027s added to or removed from as appropriate.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "4fbf4291aa15926cd4fdca0ffe9122e89d0459db", "tree": "ec2195c39ef8117acea598af4a5c20c77f67aa0b", "parents": [ "440f0affe247e9990c8f8778f1861da4fd7d5e50" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:04 2009 +0000" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Thu Nov 19 18:11:04 2009 +0000" }, "message": "FS-Cache: Allow the current state of all objects to be dumped\n\nAllow the current state of all fscache objects to be dumped by doing:\n\n\tcat /proc/fs/fscache/objects\n\nBy default, all objects and all fields will be shown. This can be restricted\nby adding a suitable key to one of the caller\u0027s keyrings (such as the session\nkeyring):\n\n\tkeyctl add user fscache:objlist \"\u003crestrictions\u003e\" @s\n\nThe \u003crestrictions\u003e are:\n\n\tK\tShow hexdump of object key (don\u0027t show if not given)\n\tA\tShow hexdump of object aux data (don\u0027t show if not given)\n\nAnd paired restrictions:\n\n\tC\tShow objects that have a cookie\n\tc\tShow objects that don\u0027t have a cookie\n\tB\tShow objects that are busy\n\tb\tShow objects that aren\u0027t busy\n\tW\tShow objects that have pending writes\n\tw\tShow objects that don\u0027t have pending writes\n\tR\tShow objects that have outstanding reads\n\tr\tShow objects that don\u0027t have outstanding reads\n\tS\tShow objects that have slow work queued\n\ts\tShow objects that don\u0027t have slow work queued\n\nIf neither side of a restriction pair is given, then both are implied. For\nexample:\n\n\tkeyctl add user fscache:objlist KB @s\n\nshows objects that are busy, and lists their object keys, but does not dump\ntheir auxiliary data. It also implies \"CcWwRrSs\", but as \u0027B\u0027 is given, \u0027b\u0027 is\nnot implied.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\n" }, { "commit": "19f594600110377ec4037fdf7fb93a25ec516212", "tree": "bf88707b65f0138b754d896300976e474098a50d", "parents": [ "19af5cdb7c79ff5ec96a99893ffb7f894f4a3dc1" ], "author": { "name": "Matt LaPlante", "email": "kernel1@cyberdogtech.com", "time": "Mon Apr 27 15:06:31 2009 +0200" }, "committer": { "name": "Jiri Kosina", "email": "jkosina@suse.cz", "time": "Fri Jun 12 18:01:47 2009 +0200" }, "message": "trivial: Miscellaneous documentation typo fixes\n\nFix various typos in documentation txts.\n\nSigned-off-by: Matt LaPlante \u003ckernel1@cyberdogtech.com\u003e\nSigned-off-by: Jiri Kosina \u003cjkosina@suse.cz\u003e\n" }, { "commit": "91ac033d8377552d3654501a105ab55bf546940e", "tree": "b3757b6b5f2180edb94049971850f76355abaa19", "parents": [ "e5b89542ea18020961882228c26db3ba87f6e608" ], "author": { "name": "Marc Dionne", "email": "marc.c.dionne@gmail.com", "time": "Thu Apr 23 11:21:55 2009 +0100" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@linux-foundation.org", "time": "Fri Apr 24 13:28:30 2009 -0700" }, "message": "CacheFiles: Fix the documentation to use the correct credential pointer names\n\nAdjust the CacheFiles documentation to use the correct names of the credential\npointers in task_struct.\n\nThe documentation was using names from the old versions of the credentials\npatches.\n\nSigned-off-by: Marc Dionne \u003cmarc.c.dionne@gmail.com\u003e\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n" }, { "commit": "9ae326a69004dea8af2dae4fde58de27db700a8d", "tree": "3a1d88a6e297989bfbd17648b398c7aa5ef9bf30", "parents": [ "800a964787faef3509d194fa33268628c3d1daa9" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Fri Apr 03 16:42:41 2009 +0100" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Fri Apr 03 16:42:41 2009 +0100" }, "message": "CacheFiles: A cache that backs onto a mounted filesystem\n\nAdd an FS-Cache cache-backend that permits a mounted filesystem to be used as a\nbacking store for the cache.\n\nCacheFiles uses a userspace daemon to do some of the cache management - such as\nreaping stale nodes and culling. This is called cachefilesd and lives in\n/sbin. The source for the daemon can be downloaded from:\n\n\thttp://people.redhat.com/~dhowells/cachefs/cachefilesd.c\n\nAnd an example configuration from:\n\n\thttp://people.redhat.com/~dhowells/cachefs/cachefilesd.conf\n\nThe filesystem and data integrity of the cache are only as good as those of the\nfilesystem providing the backing services. Note that CacheFiles does not\nattempt to journal anything since the journalling interfaces of the various\nfilesystems are very specific in nature.\n\nCacheFiles creates a misc character device - \"/dev/cachefiles\" - that is used\nto communication with the daemon. Only one thing may have this open at once,\nand whilst it is open, a cache is at least partially in existence. The daemon\nopens this and sends commands down it to control the cache.\n\nCacheFiles is currently limited to a single cache.\n\nCacheFiles attempts to maintain at least a certain percentage of free space on\nthe filesystem, shrinking the cache by culling the objects it contains to make\nspace if necessary - see the \"Cache Culling\" section. This means it can be\nplaced on the same medium as a live set of data, and will expand to make use of\nspare space and automatically contract when the set of data requires more\nspace.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nREQUIREMENTS\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nThe use of CacheFiles and its daemon requires the following features to be\navailable in the system and in the cache filesystem:\n\n\t- dnotify.\n\n\t- extended attributes (xattrs).\n\n\t- openat() and friends.\n\n\t- bmap() support on files in the filesystem (FIBMAP ioctl).\n\n\t- The use of bmap() to detect a partial page at the end of the file.\n\nIt is strongly recommended that the \"dir_index\" option is enabled on Ext3\nfilesystems being used as a cache.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nCONFIGURATION\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nThe cache is configured by a script in /etc/cachefilesd.conf. These commands\nset up cache ready for use. The following script commands are available:\n\n (*) brun \u003cN\u003e%\n (*) bcull \u003cN\u003e%\n (*) bstop \u003cN\u003e%\n (*) frun \u003cN\u003e%\n (*) fcull \u003cN\u003e%\n (*) fstop \u003cN\u003e%\n\n\tConfigure the culling limits. Optional. See the section on culling\n\tThe defaults are 7% (run), 5% (cull) and 1% (stop) respectively.\n\n\tThe commands beginning with a \u0027b\u0027 are file space (block) limits, those\n\tbeginning with an \u0027f\u0027 are file count limits.\n\n (*) dir \u003cpath\u003e\n\n\tSpecify the directory containing the root of the cache. Mandatory.\n\n (*) tag \u003cname\u003e\n\n\tSpecify a tag to FS-Cache to use in distinguishing multiple caches.\n\tOptional. The default is \"CacheFiles\".\n\n (*) debug \u003cmask\u003e\n\n\tSpecify a numeric bitmask to control debugging in the kernel module.\n\tOptional. The default is zero (all off). The following values can be\n\tOR\u0027d into the mask to collect various information:\n\n\t\t1\tTurn on trace of function entry (_enter() macros)\n\t\t2\tTurn on trace of function exit (_leave() macros)\n\t\t4\tTurn on trace of internal debug points (_debug())\n\n\tThis mask can also be set through sysfs, eg:\n\n\t\techo 5 \u003e/sys/modules/cachefiles/parameters/debug\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nSTARTING THE CACHE\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nThe cache is started by running the daemon. The daemon opens the cache device,\nconfigures the cache and tells it to begin caching. At that point the cache\nbinds to fscache and the cache becomes live.\n\nThe daemon is run as follows:\n\n\t/sbin/cachefilesd [-d]* [-s] [-n] [-f \u003cconfigfile\u003e]\n\nThe flags are:\n\n (*) -d\n\n\tIncrease the debugging level. This can be specified multiple times and\n\tis cumulative with itself.\n\n (*) -s\n\n\tSend messages to stderr instead of syslog.\n\n (*) -n\n\n\tDon\u0027t daemonise and go into background.\n\n (*) -f \u003cconfigfile\u003e\n\n\tUse an alternative configuration file rather than the default one.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nTHINGS TO AVOID\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nDo not mount other things within the cache as this will cause problems. The\nkernel module contains its own very cut-down path walking facility that ignores\nmountpoints, but the daemon can\u0027t avoid them.\n\nDo not create, rename or unlink files and directories in the cache whilst the\ncache is active, as this may cause the state to become uncertain.\n\nRenaming files in the cache might make objects appear to be other objects (the\nfilename is part of the lookup key).\n\nDo not change or remove the extended attributes attached to cache files by the\ncache as this will cause the cache state management to get confused.\n\nDo not create files or directories in the cache, lest the cache get confused or\nserve incorrect data.\n\nDo not chmod files in the cache. The module creates things with minimal\npermissions to prevent random users being able to access them directly.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nCACHE CULLING\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nThe cache may need culling occasionally to make space. This involves\ndiscarding objects from the cache that have been used less recently than\nanything else. Culling is based on the access time of data objects. Empty\ndirectories are culled if not in use.\n\nCache culling is done on the basis of the percentage of blocks and the\npercentage of files available in the underlying filesystem. There are six\n\"limits\":\n\n (*) brun\n (*) frun\n\n If the amount of free space and the number of available files in the cache\n rises above both these limits, then culling is turned off.\n\n (*) bcull\n (*) fcull\n\n If the amount of available space or the number of available files in the\n cache falls below either of these limits, then culling is started.\n\n (*) bstop\n (*) fstop\n\n If the amount of available space or the number of available files in the\n cache falls below either of these limits, then no further allocation of\n disk space or files is permitted until culling has raised things above\n these limits again.\n\nThese must be configured thusly:\n\n\t0 \u003c\u003d bstop \u003c bcull \u003c brun \u003c 100\n\t0 \u003c\u003d fstop \u003c fcull \u003c frun \u003c 100\n\nNote that these are percentages of available space and available files, and do\n_not_ appear as 100 minus the percentage displayed by the \"df\" program.\n\nThe userspace daemon scans the cache to build up a table of cullable objects.\nThese are then culled in least recently used order. A new scan of the cache is\nstarted as soon as space is made in the table. Objects will be skipped if\ntheir atimes have changed or if the kernel module says it is still using them.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nCACHE STRUCTURE\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nThe CacheFiles module will create two directories in the directory it was\ngiven:\n\n (*) cache/\n\n (*) graveyard/\n\nThe active cache objects all reside in the first directory. The CacheFiles\nkernel module moves any retired or culled objects that it can\u0027t simply unlink\nto the graveyard from which the daemon will actually delete them.\n\nThe daemon uses dnotify to monitor the graveyard directory, and will delete\nanything that appears therein.\n\nThe module represents index objects as directories with the filename \"I...\" or\n\"J...\". Note that the \"cache/\" directory is itself a special index.\n\nData objects are represented as files if they have no children, or directories\nif they do. Their filenames all begin \"D...\" or \"E...\". If represented as a\ndirectory, data objects will have a file in the directory called \"data\" that\nactually holds the data.\n\nSpecial objects are similar to data objects, except their filenames begin\n\"S...\" or \"T...\".\n\nIf an object has children, then it will be represented as a directory.\nImmediately in the representative directory are a collection of directories\nnamed for hash values of the child object keys with an \u0027@\u0027 prepended. Into\nthis directory, if possible, will be placed the representations of the child\nobjects:\n\n\tINDEX INDEX INDEX DATA FILES\n\t\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\tcache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400\n\tcache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400/@75/Es0g000w...DB1ry\n\tcache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400/@75/Es0g000w...N22ry\n\tcache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400/@75/Es0g000w...FP1ry\n\nIf the key is so long that it exceeds NAME_MAX with the decorations added on to\nit, then it will be cut into pieces, the first few of which will be used to\nmake a nest of directories, and the last one of which will be the objects\ninside the last directory. The names of the intermediate directories will have\n\u0027+\u0027 prepended:\n\n\tJ1223/@23/+xy...z/+kl...m/Epqr\n\nNote that keys are raw data, and not only may they exceed NAME_MAX in size,\nthey may also contain things like \u0027/\u0027 and NUL characters, and so they may not\nbe suitable for turning directly into a filename.\n\nTo handle this, CacheFiles will use a suitably printable filename directly and\n\"base-64\" encode ones that aren\u0027t directly suitable. The two versions of\nobject filenames indicate the encoding:\n\n\tOBJECT TYPE\tPRINTABLE\tENCODED\n\t\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\t\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\t\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\tIndex\t\t\"I...\"\t\t\"J...\"\n\tData\t\t\"D...\"\t\t\"E...\"\n\tSpecial\t\t\"S...\"\t\t\"T...\"\n\nIntermediate directories are always \"@\" or \"+\" as appropriate.\n\nEach object in the cache has an extended attribute label that holds the object\ntype ID (required to distinguish special objects) and the auxiliary data from\nthe netfs. The latter is used to detect stale objects in the cache and update\nor retire them.\n\nNote that CacheFiles will erase from the cache any file it doesn\u0027t recognise or\nany file of an incorrect type (such as a FIFO file or a device file).\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nSECURITY MODEL AND SELINUX\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nCacheFiles is implemented to deal properly with the LSM security features of\nthe Linux kernel and the SELinux facility.\n\nOne of the problems that CacheFiles faces is that it is generally acting on\nbehalf of a process, and running in that process\u0027s context, and that includes a\nsecurity context that is not appropriate for accessing the cache - either\nbecause the files in the cache are inaccessible to that process, or because if\nthe process creates a file in the cache, that file may be inaccessible to other\nprocesses.\n\nThe way CacheFiles works is to temporarily change the security context (fsuid,\nfsgid and actor security label) that the process acts as - without changing the\nsecurity context of the process when it the target of an operation performed by\nsome other process (so signalling and suchlike still work correctly).\n\nWhen the CacheFiles module is asked to bind to its cache, it:\n\n (1) Finds the security label attached to the root cache directory and uses\n that as the security label with which it will create files. By default,\n this is:\n\n\tcachefiles_var_t\n\n (2) Finds the security label of the process which issued the bind request\n (presumed to be the cachefilesd daemon), which by default will be:\n\n\tcachefilesd_t\n\n and asks LSM to supply a security ID as which it should act given the\n daemon\u0027s label. By default, this will be:\n\n\tcachefiles_kernel_t\n\n SELinux transitions the daemon\u0027s security ID to the module\u0027s security ID\n based on a rule of this form in the policy.\n\n\ttype_transition \u003cdaemon\u0027s-ID\u003e kernel_t : process \u003cmodule\u0027s-ID\u003e;\n\n For instance:\n\n\ttype_transition cachefilesd_t kernel_t : process cachefiles_kernel_t;\n\nThe module\u0027s security ID gives it permission to create, move and remove files\nand directories in the cache, to find and access directories and files in the\ncache, to set and access extended attributes on cache objects, and to read and\nwrite files in the cache.\n\nThe daemon\u0027s security ID gives it only a very restricted set of permissions: it\nmay scan directories, stat files and erase files and directories. It may\nnot read or write files in the cache, and so it is precluded from accessing the\ndata cached therein; nor is it permitted to create new files in the cache.\n\nThere are policy source files available in:\n\n\thttp://people.redhat.com/~dhowells/fscache/cachefilesd-0.8.tar.bz2\n\nand later versions. In that tarball, see the files:\n\n\tcachefilesd.te\n\tcachefilesd.fc\n\tcachefilesd.if\n\nThey are built and installed directly by the RPM.\n\nIf a non-RPM based system is being used, then copy the above files to their own\ndirectory and run:\n\n\tmake -f /usr/share/selinux/devel/Makefile\n\tsemodule -i cachefilesd.pp\n\nYou will need checkpolicy and selinux-policy-devel installed prior to the\nbuild.\n\nBy default, the cache is located in /var/fscache, but if it is desirable that\nit should be elsewhere, than either the above policy files must be altered, or\nan auxiliary policy must be installed to label the alternate location of the\ncache.\n\nFor instructions on how to add an auxiliary policy to enable the cache to be\nlocated elsewhere when SELinux is in enforcing mode, please see:\n\n\t/usr/share/doc/cachefilesd-*/move-cache.txt\n\nWhen the cachefilesd rpm is installed; alternatively, the document can be found\nin the sources.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nA NOTE ON SECURITY\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nCacheFiles makes use of the split security in the task_struct. It allocates\nits own task_security structure, and redirects current-\u003eact_as to point to it\nwhen it acts on behalf of another process, in that process\u0027s context.\n\nThe reason it does this is that it calls vfs_mkdir() and suchlike rather than\nbypassing security and calling inode ops directly. Therefore the VFS and LSM\nmay deny the CacheFiles access to the cache data because under some\ncircumstances the caching code is running in the security context of whatever\nprocess issued the original syscall on the netfs.\n\nFurthermore, should CacheFiles create a file or directory, the security\nparameters with that object is created (UID, GID, security label) would be\nderived from that process that issued the system call, thus potentially\npreventing other processes from accessing the cache - including CacheFiles\u0027s\ncache management daemon (cachefilesd).\n\nWhat is required is to temporarily override the security of the process that\nissued the system call. We can\u0027t, however, just do an in-place change of the\nsecurity data as that affects the process as an object, not just as a subject.\nThis means it may lose signals or ptrace events for example, and affects what\nthe process looks like in /proc.\n\nSo CacheFiles makes use of a logical split in the security between the\nobjective security (task-\u003esec) and the subjective security (task-\u003eact_as). The\nobjective security holds the intrinsic security properties of a process and is\nnever overridden. This is what appears in /proc, and is what is used when a\nprocess is the target of an operation by some other process (SIGKILL for\nexample).\n\nThe subjective security holds the active security properties of a process, and\nmay be overridden. This is not seen externally, and is used whan a process\nacts upon another object, for example SIGKILLing another process or opening a\nfile.\n\nLSM hooks exist that allow SELinux (or Smack or whatever) to reject a request\nfor CacheFiles to run in a context of a specific security label, or to create\nfiles and directories with another security label.\n\nThis documentation is added by the patch to:\n\n\tDocumentation/filesystems/caching/cachefiles.txt\n\nSigned-Off-By: David Howells \u003cdhowells@redhat.com\u003e\nAcked-by: Steve Dickson \u003csteved@redhat.com\u003e\nAcked-by: Trond Myklebust \u003cTrond.Myklebust@netapp.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nTested-by: Daire Byrne \u003cDaire.Byrne@framestore.com\u003e\n" }, { "commit": "952efe7b7840e1c726ae88222245e4efe6bd88f3", "tree": "fed43da6709707d0eb51b8695b6b382a221e99bd", "parents": [ "ccc4fc3d11e91477036d1f82bfa2d442f6ce77f0" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Fri Apr 03 16:42:39 2009 +0100" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Fri Apr 03 16:42:39 2009 +0100" }, "message": "FS-Cache: Add and document asynchronous operation handling\n\nAdd and document asynchronous operation handling for use by FS-Cache\u0027s data\nstorage and retrieval routines.\n\nThe following documentation is added to:\n\n\tDocumentation/filesystems/caching/operations.txt\n\n\t\t \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\t\t ASYNCHRONOUS OPERATIONS HANDLING\n\t\t \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nOVERVIEW\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nFS-Cache has an asynchronous operations handling facility that it uses for its\ndata storage and retrieval routines. Its operations are represented by\nfscache_operation structs, though these are usually embedded into some other\nstructure.\n\nThis facility is available to and expected to be be used by the cache backends,\nand FS-Cache will create operations and pass them off to the appropriate cache\nbackend for completion.\n\nTo make use of this facility, \u003clinux/fscache-cache.h\u003e should be #included.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nOPERATION RECORD INITIALISATION\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nAn operation is recorded in an fscache_operation struct:\n\n\tstruct fscache_operation {\n\t\tunion {\n\t\t\tstruct work_struct fast_work;\n\t\t\tstruct slow_work slow_work;\n\t\t};\n\t\tunsigned long\t\tflags;\n\t\tfscache_operation_processor_t processor;\n\t\t...\n\t};\n\nSomeone wanting to issue an operation should allocate something with this\nstruct embedded in it. They should initialise it by calling:\n\n\tvoid fscache_operation_init(struct fscache_operation *op,\n\t\t\t\t fscache_operation_release_t release);\n\nwith the operation to be initialised and the release function to use.\n\nThe op-\u003eflags parameter should be set to indicate the CPU time provision and\nthe exclusivity (see the Parameters section).\n\nThe op-\u003efast_work, op-\u003eslow_work and op-\u003eprocessor flags should be set as\nappropriate for the CPU time provision (see the Parameters section).\n\nFSCACHE_OP_WAITING may be set in op-\u003eflags prior to each submission of the\noperation and waited for afterwards.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nPARAMETERS\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nThere are a number of parameters that can be set in the operation record\u0027s flag\nparameter. There are three options for the provision of CPU time in these\noperations:\n\n (1) The operation may be done synchronously (FSCACHE_OP_MYTHREAD). A thread\n may decide it wants to handle an operation itself without deferring it to\n another thread.\n\n This is, for example, used in read operations for calling readpages() on\n the backing filesystem in CacheFiles. Although readpages() does an\n asynchronous data fetch, the determination of whether pages exist is done\n synchronously - and the netfs does not proceed until this has been\n determined.\n\n If this option is to be used, FSCACHE_OP_WAITING must be set in op-\u003eflags\n before submitting the operation, and the operating thread must wait for it\n to be cleared before proceeding:\n\n\t\twait_on_bit(\u0026op-\u003eflags, FSCACHE_OP_WAITING,\n\t\t\t fscache_wait_bit, TASK_UNINTERRUPTIBLE);\n\n (2) The operation may be fast asynchronous (FSCACHE_OP_FAST), in which case it\n will be given to keventd to process. Such an operation is not permitted\n to sleep on I/O.\n\n This is, for example, used by CacheFiles to copy data from a backing fs\n page to a netfs page after the backing fs has read the page in.\n\n If this option is used, op-\u003efast_work and op-\u003eprocessor must be\n initialised before submitting the operation:\n\n\t\tINIT_WORK(\u0026op-\u003efast_work, do_some_work);\n\n (3) The operation may be slow asynchronous (FSCACHE_OP_SLOW), in which case it\n will be given to the slow work facility to process. Such an operation is\n permitted to sleep on I/O.\n\n This is, for example, used by FS-Cache to handle background writes of\n pages that have just been fetched from a remote server.\n\n If this option is used, op-\u003eslow_work and op-\u003eprocessor must be\n initialised before submitting the operation:\n\n\t\tfscache_operation_init_slow(op, processor)\n\nFurthermore, operations may be one of two types:\n\n (1) Exclusive (FSCACHE_OP_EXCLUSIVE). Operations of this type may not run in\n conjunction with any other operation on the object being operated upon.\n\n An example of this is the attribute change operation, in which the file\n being written to may need truncation.\n\n (2) Shareable. Operations of this type may be running simultaneously. It\u0027s\n up to the operation implementation to prevent interference between other\n operations running at the same time.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nPROCEDURE\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nOperations are used through the following procedure:\n\n (1) The submitting thread must allocate the operation and initialise it\n itself. Normally this would be part of a more specific structure with the\n generic op embedded within.\n\n (2) The submitting thread must then submit the operation for processing using\n one of the following two functions:\n\n\tint fscache_submit_op(struct fscache_object *object,\n\t\t\t struct fscache_operation *op);\n\n\tint fscache_submit_exclusive_op(struct fscache_object *object,\n\t\t\t\t\tstruct fscache_operation *op);\n\n The first function should be used to submit non-exclusive ops and the\n second to submit exclusive ones. The caller must still set the\n FSCACHE_OP_EXCLUSIVE flag.\n\n If successful, both functions will assign the operation to the specified\n object and return 0. -ENOBUFS will be returned if the object specified is\n permanently unavailable.\n\n The operation manager will defer operations on an object that is still\n undergoing lookup or creation. The operation will also be deferred if an\n operation of conflicting exclusivity is in progress on the object.\n\n If the operation is asynchronous, the manager will retain a reference to\n it, so the caller should put their reference to it by passing it to:\n\n\tvoid fscache_put_operation(struct fscache_operation *op);\n\n (3) If the submitting thread wants to do the work itself, and has marked the\n operation with FSCACHE_OP_MYTHREAD, then it should monitor\n FSCACHE_OP_WAITING as described above and check the state of the object if\n necessary (the object might have died whilst the thread was waiting).\n\n When it has finished doing its processing, it should call\n fscache_put_operation() on it.\n\n (4) The operation holds an effective lock upon the object, preventing other\n exclusive ops conflicting until it is released. The operation can be\n enqueued for further immediate asynchronous processing by adjusting the\n CPU time provisioning option if necessary, eg:\n\n\top-\u003eflags \u0026\u003d ~FSCACHE_OP_TYPE;\n\top-\u003eflags |\u003d ~FSCACHE_OP_FAST;\n\n and calling:\n\n\tvoid fscache_enqueue_operation(struct fscache_operation *op)\n\n This can be used to allow other things to have use of the worker thread\n pools.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nASYNCHRONOUS CALLBACK\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nWhen used in asynchronous mode, the worker thread pool will invoke the\nprocessor method with a pointer to the operation. This should then get at the\ncontainer struct by using container_of():\n\n\tstatic void fscache_write_op(struct fscache_operation *_op)\n\t{\n\t\tstruct fscache_storage *op \u003d\n\t\t\tcontainer_of(_op, struct fscache_storage, op);\n\t...\n\t}\n\nThe caller holds a reference on the operation, and will invoke\nfscache_put_operation() when the processor function returns. The processor\nfunction is at liberty to call fscache_enqueue_operation() or to take extra\nreferences.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\nAcked-by: Steve Dickson \u003csteved@redhat.com\u003e\nAcked-by: Trond Myklebust \u003cTrond.Myklebust@netapp.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nTested-by: Daire Byrne \u003cDaire.Byrne@framestore.com\u003e\n" }, { "commit": "36c9559022850f919269564a74bf17fdabf4bb30", "tree": "f163afcf8f8a9eb1a5d63fd6198fcb3e29564493", "parents": [ "2868cbea72dc89ae0eb17693596b1dedaafff1c5" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Fri Apr 03 16:42:38 2009 +0100" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Fri Apr 03 16:42:38 2009 +0100" }, "message": "FS-Cache: Object management state machine\n\nImplement the cache object management state machine.\n\nThe following documentation is added to illuminate the working of this state\nmachine. It will also be added as:\n\n\tDocumentation/filesystems/caching/object.txt\n\n\t \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\t IN-KERNEL CACHE OBJECT REPRESENTATION AND MANAGEMENT\n\t \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nREPRESENTATION\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nFS-Cache maintains an in-kernel representation of each object that a netfs is\ncurrently interested in. Such objects are represented by the fscache_cookie\nstruct and are referred to as cookies.\n\nFS-Cache also maintains a separate in-kernel representation of the objects that\na cache backend is currently actively caching. Such objects are represented by\nthe fscache_object struct. The cache backends allocate these upon request, and\nare expected to embed them in their own representations. These are referred to\nas objects.\n\nThere is a 1:N relationship between cookies and objects. A cookie may be\nrepresented by multiple objects - an index may exist in more than one cache -\nor even by no objects (it may not be cached).\n\nFurthermore, both cookies and objects are hierarchical. The two hierarchies\ncorrespond, but the cookies tree is a superset of the union of the object trees\nof multiple caches:\n\n\t NETFS INDEX TREE : CACHE 1 : CACHE 2\n\t : :\n\t : +-----------+ :\n\t +-----------\u003e| IObject | :\n\t +-----------+ | : +-----------+ :\n\t | ICookie |-------+ : | :\n\t +-----------+ | : | : +-----------+\n\t | +------------------------------\u003e| IObject |\n\t | : | : +-----------+\n\t | : V : |\n\t | : +-----------+ : |\n\t V +-----------\u003e| IObject | : |\n\t +-----------+ | : +-----------+ : |\n\t | ICookie |-------+ : | : V\n\t +-----------+ | : | : +-----------+\n\t | +------------------------------\u003e| IObject |\n\t +-----+-----+ : | : +-----------+\n\t | | : | : |\n\t V | : V : |\n\t+-----------+ | : +-----------+ : |\n\t| ICookie |-------------------------\u003e| IObject | : |\n\t+-----------+ | : +-----------+ : |\n\t | V : | : V\n\t | +-----------+ : | : +-----------+\n\t | | ICookie |--------------------------------\u003e| IObject |\n\t | +-----------+ : | : +-----------+\n\t V | : V : |\n\t+-----------+ | : +-----------+ : |\n\t| DCookie |-------------------------\u003e| DObject | : |\n\t+-----------+ | : +-----------+ : |\n\t | : : |\n\t +-------+-------+ : : |\n\t | | : : |\n\t V V : : V\n\t +-----------+ +-----------+ : : +-----------+\n\t | DCookie | | DCookie |------------------------\u003e| DObject |\n\t +-----------+ +-----------+ : : +-----------+\n\t : :\n\nIn the above illustration, ICookie and IObject represent indices and DCookie\nand DObject represent data storage objects. Indices may have representation in\nmultiple caches, but currently, non-index objects may not. Objects of any type\nmay also be entirely unrepresented.\n\nAs far as the netfs API goes, the netfs is only actually permitted to see\npointers to the cookies. The cookies themselves and any objects attached to\nthose cookies are hidden from it.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nOBJECT MANAGEMENT STATE MACHINE\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nWithin FS-Cache, each active object is managed by its own individual state\nmachine. The state for an object is kept in the fscache_object struct, in\nobject-\u003estate. A cookie may point to a set of objects that are in different\nstates.\n\nEach state has an action associated with it that is invoked when the machine\nwakes up in that state. There are four logical sets of states:\n\n (1) Preparation: states that wait for the parent objects to become ready. The\n representations are hierarchical, and it is expected that an object must\n be created or accessed with respect to its parent object.\n\n (2) Initialisation: states that perform lookups in the cache and validate\n what\u0027s found and that create on disk any missing metadata.\n\n (3) Normal running: states that allow netfs operations on objects to proceed\n and that update the state of objects.\n\n (4) Termination: states that detach objects from their netfs cookies, that\n delete objects from disk, that handle disk and system errors and that free\n up in-memory resources.\n\nIn most cases, transitioning between states is in response to signalled events.\nWhen a state has finished processing, it will usually set the mask of events in\nwhich it is interested (object-\u003eevent_mask) and relinquish the worker thread.\nThen when an event is raised (by calling fscache_raise_event()), if the event\nis not masked, the object will be queued for processing (by calling\nfscache_enqueue_object()).\n\nPROVISION OF CPU TIME\n---------------------\n\nThe work to be done by the various states is given CPU time by the threads of\nthe slow work facility (see Documentation/slow-work.txt). This is used in\npreference to the workqueue facility because:\n\n (1) Threads may be completely occupied for very long periods of time by a\n particular work item. These state actions may be doing sequences of\n synchronous, journalled disk accesses (lookup, mkdir, create, setxattr,\n getxattr, truncate, unlink, rmdir, rename).\n\n (2) Threads may do little actual work, but may rather spend a lot of time\n sleeping on I/O. This means that single-threaded and 1-per-CPU-threaded\n workqueues don\u0027t necessarily have the right numbers of threads.\n\nLOCKING SIMPLIFICATION\n----------------------\n\nBecause only one worker thread may be operating on any particular object\u0027s\nstate machine at once, this simplifies the locking, particularly with respect\nto disconnecting the netfs\u0027s representation of a cache object (fscache_cookie)\nfrom the cache backend\u0027s representation (fscache_object) - which may be\nrequested from either end.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nTHE SET OF STATES\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nThe object state machine has a set of states that it can be in. There are\npreparation states in which the object sets itself up and waits for its parent\nobject to transit to a state that allows access to its children:\n\n (1) State FSCACHE_OBJECT_INIT.\n\n Initialise the object and wait for the parent object to become active. In\n the cache, it is expected that it will not be possible to look an object\n up from the parent object, until that parent object itself has been looked\n up.\n\nThere are initialisation states in which the object sets itself up and accesses\ndisk for the object metadata:\n\n (2) State FSCACHE_OBJECT_LOOKING_UP.\n\n Look up the object on disk, using the parent as a starting point.\n FS-Cache expects the cache backend to probe the cache to see whether this\n object is represented there, and if it is, to see if it\u0027s valid (coherency\n management).\n\n The cache should call fscache_object_lookup_negative() to indicate lookup\n failure for whatever reason, and should call fscache_obtained_object() to\n indicate success.\n\n At the completion of lookup, FS-Cache will let the netfs go ahead with\n read operations, no matter whether the file is yet cached. If not yet\n cached, read operations will be immediately rejected with ENODATA until\n the first known page is uncached - as to that point there can be no data\n to be read out of the cache for that file that isn\u0027t currently also held\n in the pagecache.\n\n (3) State FSCACHE_OBJECT_CREATING.\n\n Create an object on disk, using the parent as a starting point. This\n happens if the lookup failed to find the object, or if the object\u0027s\n coherency data indicated what\u0027s on disk is out of date. In this state,\n FS-Cache expects the cache to create\n\n The cache should call fscache_obtained_object() if creation completes\n successfully, fscache_object_lookup_negative() otherwise.\n\n At the completion of creation, FS-Cache will start processing write\n operations the netfs has queued for an object. If creation failed, the\n write ops will be transparently discarded, and nothing recorded in the\n cache.\n\nThere are some normal running states in which the object spends its time\nservicing netfs requests:\n\n (4) State FSCACHE_OBJECT_AVAILABLE.\n\n A transient state in which pending operations are started, child objects\n are permitted to advance from FSCACHE_OBJECT_INIT state, and temporary\n lookup data is freed.\n\n (5) State FSCACHE_OBJECT_ACTIVE.\n\n The normal running state. In this state, requests the netfs makes will be\n passed on to the cache.\n\n (6) State FSCACHE_OBJECT_UPDATING.\n\n The state machine comes here to update the object in the cache from the\n netfs\u0027s records. This involves updating the auxiliary data that is used\n to maintain coherency.\n\nAnd there are terminal states in which an object cleans itself up, deallocates\nmemory and potentially deletes stuff from disk:\n\n (7) State FSCACHE_OBJECT_LC_DYING.\n\n The object comes here if it is dying because of a lookup or creation\n error. This would be due to a disk error or system error of some sort.\n Temporary data is cleaned up, and the parent is released.\n\n (8) State FSCACHE_OBJECT_DYING.\n\n The object comes here if it is dying due to an error, because its parent\n cookie has been relinquished by the netfs or because the cache is being\n withdrawn.\n\n Any child objects waiting on this one are given CPU time so that they too\n can destroy themselves. This object waits for all its children to go away\n before advancing to the next state.\n\n (9) State FSCACHE_OBJECT_ABORT_INIT.\n\n The object comes to this state if it was waiting on its parent in\n FSCACHE_OBJECT_INIT, but its parent died. The object will destroy itself\n so that the parent may proceed from the FSCACHE_OBJECT_DYING state.\n\n(10) State FSCACHE_OBJECT_RELEASING.\n(11) State FSCACHE_OBJECT_RECYCLING.\n\n The object comes to one of these two states when dying once it is rid of\n all its children, if it is dying because the netfs relinquished its\n cookie. In the first state, the cached data is expected to persist, and\n in the second it will be deleted.\n\n(12) State FSCACHE_OBJECT_WITHDRAWING.\n\n The object transits to this state if the cache decides it wants to\n withdraw the object from service, perhaps to make space, but also due to\n error or just because the whole cache is being withdrawn.\n\n(13) State FSCACHE_OBJECT_DEAD.\n\n The object transits to this state when the in-memory object record is\n ready to be deleted. The object processor shouldn\u0027t ever see an object in\n this state.\n\nTHE SET OF EVENTS\n-----------------\n\nThere are a number of events that can be raised to an object state machine:\n\n (*) FSCACHE_OBJECT_EV_UPDATE\n\n The netfs requested that an object be updated. The state machine will ask\n the cache backend to update the object, and the cache backend will ask the\n netfs for details of the change through its cookie definition ops.\n\n (*) FSCACHE_OBJECT_EV_CLEARED\n\n This is signalled in two circumstances:\n\n (a) when an object\u0027s last child object is dropped and\n\n (b) when the last operation outstanding on an object is completed.\n\n This is used to proceed from the dying state.\n\n (*) FSCACHE_OBJECT_EV_ERROR\n\n This is signalled when an I/O error occurs during the processing of some\n object.\n\n (*) FSCACHE_OBJECT_EV_RELEASE\n (*) FSCACHE_OBJECT_EV_RETIRE\n\n These are signalled when the netfs relinquishes a cookie it was using.\n The event selected depends on whether the netfs asks for the backing\n object to be retired (deleted) or retained.\n\n (*) FSCACHE_OBJECT_EV_WITHDRAW\n\n This is signalled when the cache backend wants to withdraw an object.\n This means that the object will have to be detached from the netfs\u0027s\n cookie.\n\nBecause the withdrawing releasing/retiring events are all handled by the object\nstate machine, it doesn\u0027t matter if there\u0027s a collision with both ends trying\nto sever the connection at the same time. The state machine can just pick\nwhich one it wants to honour, and that effects the other.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\nAcked-by: Steve Dickson \u003csteved@redhat.com\u003e\nAcked-by: Trond Myklebust \u003cTrond.Myklebust@netapp.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nTested-by: Daire Byrne \u003cDaire.Byrne@framestore.com\u003e\n" }, { "commit": "7394daa8c61dfda4baa687f133748fa0b599b017", "tree": "32d2c55ed60596918ec62ce6ecca186337bf4660", "parents": [ "06b3db1b9bccdc8c2c743122a89745279e5ecc46" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Fri Apr 03 16:42:37 2009 +0100" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Fri Apr 03 16:42:37 2009 +0100" }, "message": "FS-Cache: Add use of /proc and presentation of statistics\n\nMake FS-Cache create its /proc interface and present various statistical\ninformation through it. Also provide the functions for updating this\ninformation.\n\nThese features are enabled by:\n\n\tCONFIG_FSCACHE_PROC\n\tCONFIG_FSCACHE_STATS\n\tCONFIG_FSCACHE_HISTOGRAM\n\nThe /proc directory for FS-Cache is also exported so that caching modules can\nadd their own statistics there too.\n\nThe FS-Cache module is loadable at this point, and the statistics files can be\nexamined by userspace:\n\n\tcat /proc/fs/fscache/stats\n\tcat /proc/fs/fscache/histogram\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\nAcked-by: Steve Dickson \u003csteved@redhat.com\u003e\nAcked-by: Trond Myklebust \u003cTrond.Myklebust@netapp.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nTested-by: Daire Byrne \u003cDaire.Byrne@framestore.com\u003e\n" }, { "commit": "0dfc41d1efcc4180abfd32f68f0ade540e636ff6", "tree": "f066d08e2c33d2b475e55c5b18e4e4bff537ee75", "parents": [ "2d6fff637037395cc946ef910a880b5fa67b5370" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Fri Apr 03 16:42:36 2009 +0100" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Fri Apr 03 16:42:36 2009 +0100" }, "message": "FS-Cache: Add the FS-Cache cache backend API and documentation\n\nAdd the API for a generic facility (FS-Cache) by which caches may declare them\nselves open for business, and may obtain work to be done from network\nfilesystems. The header file is included by:\n\n\t#include \u003clinux/fscache-cache.h\u003e\n\nDocumentation for the API is also added to:\n\n\tDocumentation/filesystems/caching/backend-api.txt\n\nThis API is not usable without the implementation of the utility functions\nwhich will be added in further patches.\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\nAcked-by: Steve Dickson \u003csteved@redhat.com\u003e\nAcked-by: Trond Myklebust \u003cTrond.Myklebust@netapp.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nTested-by: Daire Byrne \u003cDaire.Byrne@framestore.com\u003e\n" }, { "commit": "2d6fff637037395cc946ef910a880b5fa67b5370", "tree": "a369011a976d5faf4fe45cf237503078cbbfb9b4", "parents": [ "266cf658efcf6ac33541a46740f74f50c79d2b6b" ], "author": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Fri Apr 03 16:42:36 2009 +0100" }, "committer": { "name": "David Howells", "email": "dhowells@redhat.com", "time": "Fri Apr 03 16:42:36 2009 +0100" }, "message": "FS-Cache: Add the FS-Cache netfs API and documentation\n\nAdd the API for a generic facility (FS-Cache) by which filesystems (such as AFS\nor NFS) may call on local caching capabilities without having to know anything\nabout how the cache works, or even if there is a cache:\n\n\t+---------+\n\t| | +--------------+\n\t| NFS |--+ | |\n\t| | | +--\u003e| CacheFS |\n\t+---------+ | +----------+ | | /dev/hda5 |\n\t | | | | +--------------+\n\t+---------+ +--\u003e| | |\n\t| | | |--+\n\t| AFS |-----\u003e| FS-Cache |\n\t| | | |--+\n\t+---------+ +--\u003e| | |\n\t | | | | +--------------+\n\t+---------+ | +----------+ | | |\n\t| | | +--\u003e| CacheFiles |\n\t| ISOFS |--+ | /var/cache |\n\t| | +--------------+\n\t+---------+\n\nGeneral documentation and documentation of the netfs specific API are provided\nin addition to the header files.\n\nAs this patch stands, it is possible to build a filesystem against the facility\nand attempt to use it. All that will happen is that all requests will be\nimmediately denied as if no cache is present.\n\nFurther patches will implement the core of the facility. The facility will\ntransfer requests from networking filesystems to appropriate caches if\npossible, or else gracefully deny them.\n\nIf this facility is disabled in the kernel configuration, then all its\noperations will trivially reduce to nothing during compilation.\n\nWHY NOT I_MAPPING?\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nI have added my own API to implement caching rather than using i_mapping to do\nthis for a number of reasons. These have been discussed a lot on the LKML and\nCacheFS mailing lists, but to summarise the basics:\n\n (1) Most filesystems don\u0027t do hole reportage. Holes in files are treated as\n blocks of zeros and can\u0027t be distinguished otherwise, making it difficult\n to distinguish blocks that have been read from the network and cached from\n those that haven\u0027t.\n\n (2) The backing inode must be fully populated before being exposed to\n userspace through the main inode because the VM/VFS goes directly to the\n backing inode and does not interrogate the front inode\u0027s VM ops.\n\n Therefore:\n\n (a) The backing inode must fit entirely within the cache.\n\n (b) All backed files currently open must fit entirely within the cache at\n \t the same time.\n\n (c) A working set of files in total larger than the cache may not be\n \t cached.\n\n (d) A file may not grow larger than the available space in the cache.\n\n (e) A file that\u0027s open and cached, and remotely grows larger than the\n \t cache is potentially stuffed.\n\n (3) Writes go to the backing filesystem, and can only be transferred to the\n network when the file is closed.\n\n (4) There\u0027s no record of what changes have been made, so the whole file must\n be written back.\n\n (5) The pages belong to the backing filesystem, and all metadata associated\n with that page are relevant only to the backing filesystem, and not\n anything stacked atop it.\n\nOVERVIEW\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nFS-Cache provides (or will provide) the following facilities:\n\n (1) Caches can be added / removed at any time, even whilst in use.\n\n (2) Adds a facility by which tags can be used to refer to caches, even if\n they\u0027re not available yet.\n\n (3) More than one cache can be used at once. Caches can be selected\n explicitly by use of tags.\n\n (4) The netfs is provided with an interface that allows either party to\n withdraw caching facilities from a file (required for (1)).\n\n (5) A netfs may annotate cache objects that belongs to it. This permits the\n storage of coherency maintenance data.\n\n (6) Cache objects will be pinnable and space reservations will be possible.\n\n (7) The interface to the netfs returns as few errors as possible, preferring\n rather to let the netfs remain oblivious.\n\n (8) Cookies are used to represent indices, files and other objects to the\n netfs. The simplest cookie is just a NULL pointer - indicating nothing\n cached there.\n\n (9) The netfs is allowed to propose - dynamically - any index hierarchy it\n desires, though it must be aware that the index search function is\n recursive, stack space is limited, and indices can only be children of\n indices.\n\n(10) Indices can be used to group files together to reduce key size and to make\n group invalidation easier. The use of indices may make lookup quicker,\n but that\u0027s cache dependent.\n\n(11) Data I/O is effectively done directly to and from the netfs\u0027s pages. The\n netfs indicates that page A is at index B of the data-file represented by\n cookie C, and that it should be read or written. The cache backend may or\n may not start I/O on that page, but if it does, a netfs callback will be\n invoked to indicate completion. The I/O may be either synchronous or\n asynchronous.\n\n(12) Cookies can be \"retired\" upon release. At this point FS-Cache will mark\n them as obsolete and the index hierarchy rooted at that point will get\n recycled.\n\n(13) The netfs provides a \"match\" function for index searches. In addition to\n saying whether a match was made or not, this can also specify that an\n entry should be updated or deleted.\n\nFS-Cache maintains a virtual index tree in which all indices, files, objects\nand pages are kept. Bits of this tree may actually reside in one or more\ncaches.\n\n FSDEF\n |\n +------------------------------------+\n | |\n NFS AFS\n | |\n +--------------------------+ +-----------+\n | | | |\n homedir mirror afs.org redhat.com\n | | |\n +------------+ +---------------+ +----------+\n | | | | | |\n 00001 00002 00007 00125 vol00001 vol00002\n | | | | |\n +---+---+ +-----+ +---+ +------+------+ +-----+----+\n | | | | | | | | | | | | |\nPG0 PG1 PG2 PG0 XATTR PG0 PG1 DIRENT DIRENT DIRENT R/W R/O Bak\n | |\n PG0 +-------+\n | |\n 00001 00003\n |\n +---+---+\n | | |\n PG0 PG1 PG2\n\nIn the example above, two netfs\u0027s can be seen to be backed: NFS and AFS. These\nhave different index hierarchies:\n\n (*) The NFS primary index will probably contain per-server indices. Each\n server index is indexed by NFS file handles to get data file objects.\n Each data file objects can have an array of pages, but may also have\n further child objects, such as extended attributes and directory entries.\n Extended attribute objects themselves have page-array contents.\n\n (*) The AFS primary index contains per-cell indices. Each cell index contains\n per-logical-volume indices. Each of volume index contains up to three\n indices for the read-write, read-only and backup mirrors of those volumes.\n Each of these contains vnode data file objects, each of which contains an\n array of pages.\n\nThe very top index is the FS-Cache master index in which individual netfs\u0027s\nhave entries.\n\nAny index object may reside in more than one cache, provided it only has index\nchildren. Any index with non-index object children will be assumed to only\nreside in one cache.\n\nThe FS-Cache overview can be found in:\n\n\tDocumentation/filesystems/caching/fscache.txt\n\nThe netfs API to FS-Cache can be found in:\n\n\tDocumentation/filesystems/caching/netfs-api.txt\n\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\nAcked-by: Steve Dickson \u003csteved@redhat.com\u003e\nAcked-by: Trond Myklebust \u003cTrond.Myklebust@netapp.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nTested-by: Daire Byrne \u003cDaire.Byrne@framestore.com\u003e\n" } ] }