Date: Fri, 18 Jan 2008 16:06:21 -0500 From: Jan Harkes <jaharkes@cs.cmu.edu> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-fs@freebsd.org Subject: Re: Coda on FreeBSD problem reports? Message-ID: <20080118210621.GF7898@cs.cmu.edu> In-Reply-To: <20080118103952.D18977@fledge.watson.org> References: <18CC5A4A2AC36D7FF57615EE@ganymede.hub.org> <478AF6BC.8050604@highperformance.net> <20080114142124.Y55696@fledge.watson.org> <20080116085630.GA32361@pappardelle.tekno.chalmers.se> <20080117080359.U51764@fledge.watson.org> <20080118073445.GA30721@pappardelle.tekno.chalmers.se> <20080118095652.GC30721@pappardelle.tekno.chalmers.se> <20080118103952.D18977@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 18, 2008 at 11:10:26AM +0000, Robert Watson wrote: > This is likely a VM interaction involving either an improperly managed or > unmanaged VM object for Coda vnodes. That sounds right. I haven't looked at vobjects and how they are manager, didn't even know FreeBSD had these. It sounds a lot like the i_mapping/address_space in the Linux kernel and if these are even slightly similar, we would want to share the vobject between the Coda vnode and the cache/container vnode. > loosely guess the former if cache vnodes are reused between Coda vnodes. Cache vnodes are reused, but under very specific conditions, and for other reasons we are going to switch to unlinking / recreating them. > However, sharing makes more sense in other ways, as it means there won't > be data cache coherency problems between the Coda and cache VM objects if > both are written too simultaneously (or even not simultaneously, given > that when there's little memory pressure, pages hang around for a long > time). We never write simultaneously because of the session semantics + whole file caching. When we get an open the Coda using application is blocked until we know that all data has been copied to the cache file before we hand the reference to the cache file back to the kernel. But we don't actually sync the dirty pages to disk so if the Coda vnode uses it's own vobject it would miss the few dirty pages that are still associated with the cache vnode's vobject. It is also a huge performance benefit for a lot of short lived files which are unlinked before their dirty pages have even hit the disk. So sharing these definitely seems like the cleaner solution. >> 2. Killing venus for the first time and restarting is fine, for the >> second time kill <venus-pid> causes "panic: lockmgr: locking against >> myself". That can possibly depend on some locks not being properly >> released when Venus dies? > > Sounds likely -- presumably a lock on a vnode is not being properly > released on some path. Jan may be able to offer some more insight. I don't know, don't trust that control vnode (coda_ctlvp) but I don't know enough about it to be sure. Jan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080118210621.GF7898>