)]}' { "log": [ { "commit": "49a3df804bec09b8ee8196f79b81757e95cc6de4", "tree": "864bdee072cc48320a394d1acbc3cda5e08b6c98", "parents": [ "ab0cfb928a3839e21942a28a86ad88e56ea3b136" ], "author": { "name": "Suresh Jayaraman", "email": "sjayaraman@suse.de", "time": "Tue Jul 06 18:29:45 2010 +0530" }, "committer": { "name": "Jiri Kosina", "email": "jkosina@suse.cz", "time": "Sun Jul 11 22:22:23 2010 +0200" }, "message": "fscache: fix missing kerneldoc annotation\n\n.. and make kerneldoc scripts happy.\n\nSigned-off-by: Suresh Jayaraman \u003csjayaraman@suse.de\u003e\nAcked-by: David Howells \u003cdhowells@redhat.com\u003e\nSigned-off-by: Jiri Kosina \u003cjkosina@suse.cz\u003e\n" }, { "commit": "ab0cfb928a3839e21942a28a86ad88e56ea3b136", "tree": "f5c5d81ae16e2d863dc430eaefcf9ebe30920150", "parents": [ "fa964e1aab51178d690d1c58d8b831eac434912f" ], "author": { "name": "Suresh Jayaraman", "email": "sjayaraman@suse.de", "time": "Tue Jul 06 18:12:39 2010 +0530" }, "committer": { "name": "Jiri Kosina", "email": "jkosina@suse.cz", "time": "Sun Jul 11 22:21:26 2010 +0200" }, "message": "fscache: fix a trivial typo in the comment\n\nSigned-off-by: Suresh Jayaraman \u003csjayaraman@suse.de\u003e\nAcked-by: David Howells \u003cdhowells@redhat.com\u003e\nSigned-off-by: Jiri Kosina \u003cjkosina@suse.cz\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": "b510882281d56873e1194021643b7c325336f84f", "tree": "86cd206b0d2b55dc355833ca238d46488161b64c", "parents": [ "952efe7b7840e1c726ae88222245e4efe6bd88f3" ], "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: Implement data I/O part of netfs API\n\nImplement the data I/O part of the FS-Cache netfs API. The documentation and\nAPI header file were added in a previous patch.\n\nThis patch implements the following functions for the netfs to call:\n\n (*) fscache_attr_changed().\n\n Indicate that the object has changed its attributes. The only attribute\n currently recorded is the file size. Only pages within the set file size\n will be stored in the cache.\n\n This operation is submitted for asynchronous processing, and will return\n immediately. It will return -ENOMEM if an out of memory error is\n encountered, -ENOBUFS if the object is not actually cached, or 0 if the\n operation is successfully queued.\n\n (*) fscache_read_or_alloc_page().\n (*) fscache_read_or_alloc_pages().\n\n Request data be fetched from the disk, and allocate internal metadata to\n track the netfs pages and reserve disk space for unknown pages.\n\n These operations perform semi-asynchronous data reads. Upon returning\n they will indicate which pages they think can be retrieved from disk, and\n will have set in progress attempts to retrieve those pages.\n\n These will return, in order of preference, -ENOMEM on memory allocation\n error, -ERESTARTSYS if a signal interrupted proceedings, -ENODATA if one\n or more requested pages are not yet cached, -ENOBUFS if the object is not\n actually cached or if there isn\u0027t space for future pages to be cached on\n this object, or 0 if successful.\n\n In the case of the multipage function, the pages for which reads are set\n in progress will be removed from the list and the page count decreased\n appropriately.\n\n If any read operations should fail, the completion function will be given\n an error, and will also be passed contextual information to allow the\n netfs to fall back to querying the server for the absent pages.\n\n For each successful read, the page completion function will also be\n called.\n\n Any pages subsequently tracked by the cache will have PG_fscache set upon\n them on return. fscache_uncache_page() must be called for such pages.\n\n If supplied by the netfs, the mark_pages_cached() cookie op will be\n invoked for any pages now tracked.\n\n (*) fscache_alloc_page().\n\n Allocate internal metadata to track a netfs page and reserve disk space.\n\n This will return -ENOMEM on memory allocation error, -ERESTARTSYS on\n signal, -ENOBUFS if the object isn\u0027t cached, or there isn\u0027t enough space\n in the cache, or 0 if successful.\n\n Any pages subsequently tracked by the cache will have PG_fscache set upon\n them on return. fscache_uncache_page() must be called for such pages.\n\n If supplied by the netfs, the mark_pages_cached() cookie op will be\n invoked for any pages now tracked.\n\n (*) fscache_write_page().\n\n Request data be stored to disk. This may only be called on pages that\n have been read or alloc\u0027d by the above three functions and have not yet\n been uncached.\n\n This will return -ENOMEM on memory allocation error, -ERESTARTSYS on\n signal, -ENOBUFS if the object isn\u0027t cached, or there isn\u0027t immediately\n enough space in the cache, or 0 if successful.\n\n On a successful return, this operation will have queued the page for\n asynchronous writing to the cache. The page will be returned with\n PG_fscache_write set until the write completes one way or another. The\n caller will not be notified if the write fails due to an I/O error. If\n that happens, the object will become available and all pending writes will\n be aborted.\n\n Note that the cache may batch up page writes, and so it may take a while\n to get around to writing them out.\n\n The caller must assume that until PG_fscache_write is cleared the page is\n use by the cache. Any changes made to the page may be reflected on disk.\n The page may even be under DMA.\n\n (*) fscache_uncache_page().\n\n Indicate that the cache should stop tracking a page previously read or\n alloc\u0027d from the cache. If the page was alloc\u0027d only, but unwritten, it\n will not appear on disk.\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": "ccc4fc3d11e91477036d1f82bfa2d442f6ce77f0", "tree": "c3ead4b385f9efce6e2688832dfb76391e18345d", "parents": [ "36c9559022850f919269564a74bf17fdabf4bb30" ], "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: Implement the cookie management part of the netfs API\n\nImplement the cookie management part of the FS-Cache netfs client API. The\ndocumentation and API header file were added in a previous patch.\n\nThis patch implements the following three functions:\n\n (1) fscache_acquire_cookie().\n\n Acquire a cookie to represent an object to the netfs. If the object in\n question is a non-index object, then that object and its parent indices\n will be created on disk at this point if they don\u0027t already exist. Index\n creation is deferred because an index may reside in multiple caches.\n\n (2) fscache_relinquish_cookie().\n\n Retire or release a cookie previously acquired. At this point, the\n object on disk may be destroyed.\n\n (3) fscache_update_cookie().\n\n Update the in-cache representation of a cookie. This is used to update\n the auxiliary data for coherency management purposes.\n\nWith this patch it is possible to have a netfs instruct a cache backend to\nlook up, validate and create metadata on disk and to destroy it again.\nThe ability to actually store and retrieve data in the objects so created is\nadded in later patches.\n\nNote that these functions will never return an error. _All_ errors are\nhandled internally to FS-Cache.\n\nThe worst that can happen is that fscache_acquire_cookie() may return a NULL\npointer - which is considered a negative cookie pointer and can be passed back\nto any function that takes a cookie without harm. A negative cookie pointer\nmerely suppresses caching at that level.\n\nThe stub in linux/fscache.h will detect inline the negative cookie pointer and\nabort the operation as fast as possible. This means that the compiler doesn\u0027t\nhave to set up for a call in that case.\n\nSee the documentation in Documentation/filesystems/caching/netfs-api.txt for\nmore information.\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": "726dd7ff10c217dd74329c94643dc8ebea27334b", "tree": "9bd5b011f945fca4f1b057f7e7750414b1fd9fbd", "parents": [ "955d00917f0c094e0f2fb88df967e980ab66b8ca" ], "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: Add netfs registration\n\nAdd functions to register and unregister a network filesystem or other client\nof the FS-Cache service. This allocates and releases the cookie representing\nthe top-level index for a netfs, and makes it available to the netfs.\n\nIf the FS-Cache facility is disabled, then the calls are optimised away at\ncompile time.\n\nNote that whilst this patch may appear to work with FS-Cache enabled and a\nnetfs attempting to use it, it will leak the cookie it allocates for the netfs\nas fscache_relinquish_cookie() is implemented in a later patch. This will\ncause the slab code to emit a warning when the module is removed.\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": "0e04d4cefcf4d8fbbdb2c50e93ad541582933fd2", "tree": "97c4cda6a2c246660e6a5c718a9272375cdb259c", "parents": [ "a6891645cf2ddd4778096848a864580e7258faba" ], "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 cache tag handling\n\nImplement two features of FS-Cache:\n\n (1) The ability to request and release cache tags - names by which a cache may\n be known to a netfs, and thus selected for use.\n\n (2) An internal function by which a cache is selected by consulting the netfs,\n if the netfs wishes to be consulted.\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" } ] }