Date: Tue, 22 Jun 2010 12:20:38 +0300 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: soc-status@freebsd.org Cc: Konstantin Belousov <kib@FreeBSD.org> Subject: Namecache status report #4 Message-ID: <20100622092038.GA2620@tops>
next in thread | raw e-mail | index | archive | help
Dircache has undergone considerable change last week. First of all after trying to make pefs dircache-friendly I've decided to drop dircache_*update() API. Its original purpose was to populate cache during VOP_LOOKUP and/or VOP_READDIR, so that upper layer (stacked filesystem) could check cache instead of calling lower layer. Keeping directory cache 'complete' was too hard and race-prone, besides I didn't find a good way to use it in pefs. Dropping update() helped with getting rid of sleeping in dircache and notion of 'partial/complete' directory cache which further simplified things. I've also removed directory offsets and filesystem private data from cache entries, as they are now useless. To facilitate use within stacked filesystems API for getting name (one of the names if there are several) and generation number for a vnode was added. Cache generation number reflects changes in directory (add, remove, rename) and similar to va_seq in OpenSolaris (va_gen in our ZFS port). Dircache is now granularly locked. I'm working on improving reference counting and adding queue for unused entries. Caching algorithm is to be used to control queue size and to decide which entries to free. 2Q algorithm looks very promising. Races in VOP_RENAME() still remain the biggest obstacle. Most filesystems unlock vnodes and do relookup() later during rename() (e.g. ext2). Others exclusively lock all vnodes (UFS) or perform 'name locking' (ZFS). dircache_rename() expects nodes with given names don't change during call. Both UFS and ZFS are fine, but even tmpfs has issues. Thanks, Gleb.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100622092038.GA2620>