From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 16:06:01 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 4308A16A468 for ; Sun, 6 Jan 2008 16:05:59 +0000 (UTC) (envelope-from maciej@suszko.eu) Received: from 26.mail-out.ovh.net (26.mail-out.ovh.net [91.121.27.225]) by mx1.freebsd.org (Postfix) with SMTP id 5EB8813C45D for ; Sun, 6 Jan 2008 16:05:59 +0000 (UTC) (envelope-from maciej@suszko.eu) Received: (qmail 30736 invoked by uid 503); 6 Jan 2008 16:06:21 -0000 Received: (QMFILT: 1.0); 06 Jan 2008 16:06:21 -0000 Received: from unknown (HELO mail147.ha.ovh.net) (213.186.33.59) by 26.mail-out.ovh.net with SMTP; 6 Jan 2008 16:06:21 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 6 Jan 2008 16:05:55 -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 16:05:51 -0000 Date: Sun, 6 Jan 2008 17:05:44 +0100 From: Maciej Suszko To: freebsd-current@freebsd.org Message-Id: <20080106170544.93f7ab1b.maciej@suszko.eu> In-Reply-To: <4780F7C0.5010101@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> 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.500111/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 16:06:01 -0000 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. > P.S. It sounds like you do not have sufficient debugging configured > either: crashes should produce either a DDB prompt or a coredump so > they can be studied and understood. You're right - I turned debugging off, because it's not a production machine and I can afford such behaviour. Right now, using kernel with kmem patch applied it's ,,usable''. -- regards, Maciej Suszko.