From owner-freebsd-stable@FreeBSD.ORG Tue Jul 2 06:00:39 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1137CA46 for ; Tue, 2 Jul 2013 06:00:39 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5633917C5 for ; Tue, 2 Jul 2013 06:00:37 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA11095; Tue, 02 Jul 2013 09:00:33 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Uttdg-0004DF-JX; Tue, 02 Jul 2013 09:00:32 +0300 Message-ID: <51D26C5C.4000107@FreeBSD.org> Date: Tue, 02 Jul 2013 08:59:56 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: ZFS Panic after freebsd-update References: <20130701154925.GA64899@icarus.home.lan> <20130701170422.GA65858@icarus.home.lan> <51D1C625.1030401@FreeBSD.org> <20130701185033.GB67450@icarus.home.lan> In-Reply-To: <20130701185033.GB67450@icarus.home.lan> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable List , Scott Sipe , Paul Mather X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 06:00:39 -0000 on 01/07/2013 21:50 Jeremy Chadwick said the following: > The issue is that ZFS on FreeBSD is still young compared to other > filesystems (specifically UFS). That's a fact. > Nothing is perfect, but FFS/UFS tends > to have a significantly larger number of bugs worked out of it to the > point where people can use it without losing sleep (barring the SUJ > stuff, don't get me started). That's subjective. > I have the same concerns over other > things, like ext2fs and fusefs for that matter -- but this thread is > about a ZFS-related crash, and that's why I'm "over-focused" on it. I have an impression that you seem to state your (negative) opinion of ZFS in every other thread about ZFS problems. > A heterogeneous (UFS+ZFS) setup, rather than homogeneous (ZFS-only), > results in a system where an admin can upgrade + boot into single-user > and perform some tasks to test/troubleshoot; if the ZFS layer is > broken, it doesn't mean an essentially useless box. That isn't FUD, > that's just the stage we're at right now. I'm aware lots of people have > working ZFS-exclusive setups; like I said, "works great until it > doesn't". Yeah, a heterogeneous setup can have its benefits, but it can have its drawbacks too. This is true for heterogeneous vs monoculture in general. But the sword cuts both ways: what if something is broken in "UFS layer" or god forbid in VFS layer and you have only UFS? Besides, without mentioning specific classes of problems "ZFS layer is broken" is too vague. > So, how do you kernel guys debug a problem in this environment: > > - ZFS-only > - Running -RELEASE (i.e. no source, thus a kernel cannot be rebuilt > with added debugging features, etc.) > - No swap configured > - No serial console I use boot environments and boot to a previous / known-good environment if I hit a loader bug, a kernel bug or a major userland problem in a new environment. I also use a mirrored setup and keep two copies of earlier boot chains. I am also not shy of live media in the case everything else fails. Now I wonder how you deal with the same kind of UFS-only environment. -- Andriy Gapon