From owner-freebsd-current@FreeBSD.ORG Tue Oct 9 20:13:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED0C316A418 for ; Tue, 9 Oct 2007 20:13:30 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from conducive.net (conducive.net [203.194.153.81]) by mx1.freebsd.org (Postfix) with ESMTP id B26FD13C474 for ; Tue, 9 Oct 2007 20:13:30 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from cm218-253-81-177.hkcable.com.hk ([218.253.81.177]:60857 helo=pb.local) by conducive.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IfLSL-0006ty-7J for freebsd-current@freebsd.org; Tue, 09 Oct 2007 20:13:29 +0000 Message-ID: <470BE0E8.5020705@conducive.net> Date: Tue, 09 Oct 2007 16:13:28 -0400 From: =?UTF-8?B?6Z+T5a625qiZIEJpbGwgSGFja2Vy?= User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20071005000046.GC92272@garage.freebsd.pl> <20071008121523.GM2327@garage.freebsd.pl> <470BD961.4000407@freebsd.org> In-Reply-To: <470BD961.4000407@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ZFS kmem_map too small. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2007 20:13:31 -0000 Darren Reed wrote: > Pawel Jakub Dawidek wrote: >> Here are some updates: >> >> I was able to reproduce the panic by rsyncing big files and trying >> bonnie++ test suggested in this thread. >> >> Can you guys retry with this patch: >> >> http://people.freebsd.org/~pjd/patches/vm_kern.c.2.patch >> > > So, I have a question... > What happens if the "for (i = 0..)" is changed to "while(1)" and > the "panic" is subsequently removed? > > > It appears like the code changes the meaning of "WAIT" to "wait > for 4 seconds" then panic if it won't work. Previously, "WAIT" was > not waiting at all...whch could be described as a bug! > > If I recall correctly, ZFS caches writes and doe them in spurts and > that those spurts are spaced out more than 4 seconds. (For the > curious, do "zpool status" and observe the gap in time between > write activity.) > > If you start a large amount of I/O, it is possible that all the KVA will > be used up and ZFS will not get a chance to flush its buffers before > the 4s timer here expires. Does that sound plausible? > > Would doubling the 8 to (say) 16 be beneficial here, to at least make > the waiting span one ZFS flush out to disk? > > Darren "devil's Advocate" hat on here ... But 4 *seconds* is an entire ice-age in machine cycle terms, so.. A) I hope you are wrong about that part [1]... ;-) B) But if not... Would it not make [ equal | better | optional ] sense to look into shortening that time period? By a factor of ten comes to my mind. At least. Grant - that may mean a performance hit, hence I'd vote for 'optional' - but it should also greatly reduce, not only the likelihood of using up the alloted RAM, but of losing (quite as much of) the contents of those buffers if/as/when disaster strikes. - As it too often does, in one form or another. JM2CW Bill Hacker [1] 4 seconds 'regardless' makes more sense. i.e. flush 'em periodically just in case, even if no *known* alterations have been detected, ELSE more often depending on [ many factors ]. > > _______________________________________________ > 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"