From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 19:56:32 2008 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 991F016A46B for ; Sun, 6 Jan 2008 19:56:32 +0000 (UTC) (envelope-from maciej@suszko.eu) Received: from 30.mail-out.ovh.net (30.mail-out.ovh.net [213.186.62.213]) by mx1.freebsd.org (Postfix) with SMTP id 1B41013C442 for ; Sun, 6 Jan 2008 19:56:31 +0000 (UTC) (envelope-from maciej@suszko.eu) Received: (qmail 31368 invoked by uid 503); 6 Jan 2008 19:56:50 -0000 Received: (QMFILT: 1.0); 06 Jan 2008 19:56:50 -0000 Received: from unknown (HELO mail139.ha.ovh.net) (213.186.33.59) by 30.mail-out.ovh.net with SMTP; 6 Jan 2008 19:56:50 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 6 Jan 2008 19:56:32 -0000 Received: from 217-153-241-141.zab.nat.hnet.pl (HELO arsenic) (maciej@suszko.eu@217.153.241.141) by ns0.ovh.net with SMTP; 6 Jan 2008 19:56:30 -0000 Date: Sun, 6 Jan 2008 20:56:23 +0100 From: Maciej Suszko To: freebsd-current@freebsd.org Message-Id: <20080106205623.d1024ae6.maciej@suszko.eu> In-Reply-To: <4781002F.5020708@FreeBSD.org> References: <20080104163352.GA42835@lor.one-eyed-alien.net> <9bbcef730801040958t36e48c9fjd0fbfabd49b08b97@mail.gmail.com> <200801061051.26817.peter.schuller@infidyne.com> <9bbcef730801060458k4bc9f2d6uc3f097d70e087b68@mail.gmail.com> <4780D289.7020509@FreeBSD.org> <20080106144627.a91a62c1.maciej@suszko.eu> <4780F7C0.5010101@FreeBSD.org> <20080106170544.93f7ab1b.maciej@suszko.eu> <4781002F.5020708@FreeBSD.org> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.3; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Ovh-Remote: 217.153.241.141 (217-153-241-141.zab.nat.hnet.pl) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|H 0.500019/N Subject: Re: When will ZFS become stable? 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: Sun, 06 Jan 2008 19:56:32 -0000 Kris Kennaway wrote: > Maciej Suszko wrote: > > Kris Kennaway wrote: > >> Maciej Suszko wrote: > >>> Kris Kennaway wrote: > >>>> Ivan Voras wrote: > >>>>> On 06/01/2008, Peter Schuller > >>>>> wrote: > >>>>>>> This number is not so large. It seems to be easily crashed by > >>>>>>> rsync, for example (speaking from my own experience, and also > >>>>>>> some of my colleagues). > >>>>>> I can definitely say this is not *generally* true, as I do a > >>>>>> lot of rsyncing/rdiff-backup:ing and similar stuff (with many > >>>>>> files / large files) on ZFS without any stability issues. > >>>>>> Problems for me have been limited to 32bit and the memory > >>>>>> exhaustion issue rather than "hard" issues. > >>>>> It's not generally true since kmem problems with rsync are often > >>>>> hard to repeat - I have them on one machine, but not on another, > >>>>> similar machine. This nonrepeatability is also a part of the > >>>>> problem. > >>>>> > >>>>>> But perhaps that's all you are referring to. > >>>>> Mostly. I did have a ZFS crash with rsync that wasn't kmem > >>>>> related, but only once. > >>>> kmem problems are just tuning. They are not indicative of > >>>> stability problems in ZFS. Please report any further non-kmem > >>>> panics you experience. > >>> I agree that ZFS is pretty stable itself. I use 32bit machine with > >>> 2gigs od RAM and all hang cases are kmem related, but the fact is > >>> that I haven't found any way of tuning to stop it crashing. When I > >>> do some rsyncing, especially beetwen different pools - it hangs or > >>> reboots - mostly on bigger files (i.e. rsyncing ports tree with > >>> distfiles). At the moment I patched the kernel with > >>> vm_kern.c.2.patch and it just stopped crashing, but from time to > >>> time the machine looks like beeing freezed for a second or two, > >>> after that it works normally. Have you got any similar experience? > >> That is expected. That patch makes the system do more work to try > >> and reclaim memory when it would previously have panicked from lack > >> of memory. However, the same advice applies as to Ivan: you should > >> try and tune the memory parameters better to avoid this last-ditch > >> sitation. > > > > As Ivan said - tuning kmem_size only delay the moment system crash, > > earlier or after it happens - that's my point of view. > > So the same question applies: exactly what steps did you take to tune > the memory parameters? Extracting this information from you guys > shouldn't be as hard as this :) I was playing around with kmem_max_size mainly. I suppose messing up with KVA_PAGES is not a good idea unless you exactly know how much memory you software consume... -- regards, Maciej Suszko.