From owner-freebsd-questions@FreeBSD.ORG Sun Jul 28 14:47:12 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6C3B86ED for ; Sun, 28 Jul 2013 14:47:12 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF0EC2EF6 for ; Sun, 28 Jul 2013 14:47:11 +0000 (UTC) Received: by mail-ea0-f178.google.com with SMTP id a11so1092211eae.23 for ; Sun, 28 Jul 2013 07:47:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=r/8QxeRpRT7cxrTpNYzw772+OrCSmSszdJx/uTmu1Iw=; b=ka9ZmFHPIVngp4u6+BEmOVYgzJ7xv8tzpC9AB0vtnk0azoB9P743xGKrGLCzgk8zZt rixEeAjfL5URVEv+pZYmOzX3KcAL8SYJ3BR3911XWEgcDoIgdnJv/ePgimeHHsJJ+zrh 3mLhQ2Ua57DUpsI+ZSfAN9oExKTDMw+kHHTQ35CH2uDq65Y1904kg5+LkcUjGh5oBg/j BInZsjZ63/8z6FiGLejR0ioAVk0h0QlmFAkOVB/4TVl3bGvhK76d4Mk7nsfQOdalHxH2 Nyj4BvWzgGHM3++OguoFYu+L5UT9c1f5fWiqI1EhSD+Ypofkq/zwWxcDzRDqYhqjCddl r4+w== X-Received: by 10.14.198.73 with SMTP id u49mr55827544een.19.1375022824164; Sun, 28 Jul 2013 07:47:04 -0700 (PDT) Received: from phenom.cordula.ws (p5DDDB75D.dip0.t-ipconnect.de. [93.221.183.93]) by mx.google.com with ESMTPSA id r54sm95438641eev.8.2013.07.28.07.47.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jul 2013 07:47:03 -0700 (PDT) Message-ID: <51F52EE5.2020604@cordula.ws> Date: Sun, 28 Jul 2013 16:47:01 +0200 From: cpghost User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130711 Thunderbird/17.0.7 MIME-Version: 1.0 To: David.I.Noel@gmail.com Subject: Re: Delete a directory, crash the system References: <51F3F290.9020004@cordula.ws> <51F41BAF.8070506@cordula.ws> In-Reply-To: <51F41BAF.8070506@cordula.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn8Nvcg2SBB2WeNpc3HVsecXvIfM+4Y9cRT4S+Ho3xKVeWPpKNZGanUGjURwmbd4HeN/nlg Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 14:47:12 -0000 On 07/27/13 21:12, cpghost wrote: > A more robust file system would halt all processes, and perform > an in-kernel fsck on the filesystem and its internal (in-memory) > structures to repair the damage... and THEN resume the processes. > > However, this is a major project, and we don't have a self-healing > filesystem / kernel (... yet). ;-) > > -cpghost. If we think this further, we may as well start introducing some elements of self-healing or at least self-inspecting in the kernel. How about, for example, a kernel thread that wakes up periodically, walks through VFS structures, and checks their integrity? Perhaps also verifying the underlying inodes as well? Think background fsck, but within the kernel and for kernel structures themselves. Others parts of the kernel could as well self-inspect for consistency with a periodic kernel thread. Some parts are easier than others, so I don't think we could also walk the VM structures (if those are corrupt, even the repair-thread will be running amok). But save for that, most parts of the kernel could use some periodic consistency checking. Make that checking optional via a sysctl(8), and it won't even cost performance. -cpghost. -- Cordula's Web. http://www.cordula.ws/