Date: Fri, 5 Feb 2021 23:40:23 GMT From: Mateusz Guzik <mjg@FreeBSD.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: git: 2f8a84463531 - main - cache: remove the largely obsolete general description Message-ID: <202102052340.115NeNTi079166@gitrepo.freebsd.org>
next in thread | raw e-mail | index | archive | help
The branch main has been updated by mjg: URL: https://cgit.FreeBSD.org/src/commit/?id=2f8a844635312b0f25028a87459fdd2d2a1cbfd6 commit 2f8a844635312b0f25028a87459fdd2d2a1cbfd6 Author: Mateusz Guzik <mjg@FreeBSD.org> AuthorDate: 2021-02-05 23:16:55 +0000 Commit: Mateusz Guzik <mjg@FreeBSD.org> CommitDate: 2021-02-05 23:28:40 +0000 cache: remove the largely obsolete general description Examples of inconsistencies with the current state: - references LRU of all entries, removed years ago - references a non-existent lock (neglist) - claims negative entries have a NULL target It will be replaced with a more accurate and more informative description. In the meantime take it out so it stops misleading. --- sys/kern/vfs_cache.c | 46 ---------------------------------------------- 1 file changed, 46 deletions(-) diff --git a/sys/kern/vfs_cache.c b/sys/kern/vfs_cache.c index 50ec6face6ac..21eb436681fc 100644 --- a/sys/kern/vfs_cache.c +++ b/sys/kern/vfs_cache.c @@ -276,52 +276,6 @@ cache_ncp_invalidate(struct namecache *ncp) __predict_true((_nc_flag & (NCF_INVALID | NCF_WIP | NCF_WHITE)) == 0); \ }) -/* - * Name caching works as follows: - * - * Names found by directory scans are retained in a cache - * for future reference. It is managed LRU, so frequently - * used names will hang around. Cache is indexed by hash value - * obtained from (dvp, name) where dvp refers to the directory - * containing name. - * - * If it is a "negative" entry, (i.e. for a name that is known NOT to - * exist) the vnode pointer will be NULL. - * - * Upon reaching the last segment of a path, if the reference - * is for DELETE, or NOCACHE is set (rewrite), and the - * name is located in the cache, it will be dropped. - * - * These locks are used (in the order in which they can be taken): - * NAME TYPE ROLE - * vnodelock mtx vnode lists and v_cache_dd field protection - * bucketlock mtx for access to given set of hash buckets - * neglist mtx negative entry LRU management - * - * It is legal to take multiple vnodelock and bucketlock locks. The locking - * order is lower address first. Both are recursive. - * - * "." lookups are lockless. - * - * ".." and vnode -> name lookups require vnodelock. - * - * name -> vnode lookup requires the relevant bucketlock to be held for reading. - * - * Insertions and removals of entries require involved vnodes and bucketlocks - * to be locked to provide safe operation against other threads modifying the - * cache. - * - * Some lookups result in removal of the found entry (e.g. getting rid of a - * negative entry with the intent to create a positive one), which poses a - * problem when multiple threads reach the state. Similarly, two different - * threads can purge two different vnodes and try to remove the same name. - * - * If the already held vnode lock is lower than the second required lock, we - * can just take the other lock. However, in the opposite case, this could - * deadlock. As such, this is resolved by trylocking and if that fails unlocking - * the first node, locking everything in order and revalidating the state. - */ - VFS_SMR_DECLARE; static SYSCTL_NODE(_vfs_cache, OID_AUTO, param, CTLFLAG_RW | CTLFLAG_MPSAFE, 0,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202102052340.115NeNTi079166>