Date: Wed, 11 Jul 2007 22:36:53 -0700 From: "Kip Macy" <kip.macy@gmail.com> To: "Simon Dircks" <enderbsd@gmail.com> Cc: Pawel Jakub Dawidek <pjd@freebsd.org>, current@freebsd.org Subject: Re: ZFS leaking vnodes (sort of) Message-ID: <b1fa29170707112236x57172c72h959be16b6a3cf308@mail.gmail.com> In-Reply-To: <15d429c0707111724w76d47529v4c5fad6ac7892875@mail.gmail.com> References: <200707071426.18202.dfr@rabson.org> <20070709000918.GD1208@garage.freebsd.pl> <46922D75.4010006@gddsn.org.cn> <15d429c0707111724w76d47529v4c5fad6ac7892875@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
That looks more like bad disk than a file system bug. On 7/11/07, Simon Dircks <enderbsd@gmail.com> wrote: > On 7/9/07, Huang wen hui <huang@gddsn.org.cn> wrote: > > > > Pawel Jakub Dawidek $B<LF;(B: > > > On Sat, Jul 07, 2007 at 02:26:17PM +0100, Doug Rabson wrote: > > > > > >> I've been testing ZFS recently and I noticed some performance issues > > >> while doing large-scale port builds on a ZFS mounted /usr/ports tree. > > >> Eventually I realised that virtually nothing ever ended up on the vnode > > >> free list. This meant that when the system reached its maximum vnode > > >> limit, it had to resort to reclaiming vnodes from the various > > >> filesystem's active vnode lists (via vlrureclaim). Since those lists > > >> are not sorted in LRU order, this led to pessimal cache performance > > >> after the system got into that state. > > >> > > >> I looked a bit closer at the ZFS code and poked around with DDB and I > > >> think the problem was caused by a couple of extraneous calls to vhold > > >> when creating a new ZFS vnode. On FreeBSD, getnewvnode returns a vnode > > >> which is already held (not on the free list) so there is no need to > > >> call vhold again. > > >> > > > > > > Whoa! Nice catch... The patch works here - I did some pretty heavy > > > tests, so please commit it ASAP. > > > > > > I also wonder if this can help with some of those 'kmem_map too small' > > > panics. I was observing that ARC cannot reclaim memory and this may be > > > because all vnodes and thus associated data are beeing held. > > > > > > To ZFS users having problems with performance and/or stability of ZFS: > > > Can you test the patch and see if it helps? > > > > > my T60p notebook, -CURRENT amd64: > > buildworld time before patch: 58xx second. > > buildworld time after path: 28xx second. > > > > Thanks! > > > > With this patch i am still able to reproduce my ZFS crash. > > controllera# uname -a > FreeBSD controllera.storage.ksdhost.com 7.0-CURRENT FreeBSD 7.0-CURRENT #0: > Thu Jul 12 02:28:52 UTC 2007 > graff@controllera.storage.ksdhost.com:/usr/obj/usr/src/sys/CONTROLLERA > amd64 > > > panic: ZFS: bad checksum (read on <unknown> off 0: zio 0xffffff001d729810 > [LO SP > A space map] 1000L/800P DVA[0]=<0:1600421800:800> DVA[1]=<0:2c000f7000:800> > DVA[ > 2]=<0:4200013800:800> fletcher4 lzjb LE contiguous birth=566 fill=1 > chsum=5d3276 > 7b98:635ff7022f8b:4251 > cpuid = 0 > KDB: enter: panic > [thread pid 802 tid 100066 ] > stopped at kdb_enter+0x31: leave > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1fa29170707112236x57172c72h959be16b6a3cf308>