From owner-freebsd-geom@FreeBSD.ORG Tue Apr 10 16:21:52 2007 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8549116A406 for ; Tue, 10 Apr 2007 16:21:52 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id C881513C4BE for ; Tue, 10 Apr 2007 16:21:51 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 69E2D487F0; Tue, 10 Apr 2007 18:21:50 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 2FFF048800; Tue, 10 Apr 2007 18:21:39 +0200 (CEST) Date: Tue, 10 Apr 2007 18:21:29 +0200 From: Pawel Jakub Dawidek To: "Rick C. Petty" Message-ID: <20070410162129.GI85578@garage.freebsd.pl> References: <20070409143818.GA86722@harmless.hu> <20070409152401.GG76673@garage.freebsd.pl> <20070409153203.GA88082@harmless.hu> <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> <20070410111957.GA85578@garage.freebsd.pl> <461B75B2.40201@fer.hr> <20070410114115.GB85578@garage.freebsd.pl> <20070410161445.GA18858@keira.kiwi-computer.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/D3X8sky0X3AmG5" Content-Disposition: inline In-Reply-To: <20070410161445.GA18858@keira.kiwi-computer.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-geom@FreeBSD.org Subject: Re: volume management X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 16:21:52 -0000 --W/D3X8sky0X3AmG5 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2007 at 11:14:45AM -0500, Rick C. Petty wrote: > On Tue, Apr 10, 2007 at 01:41:15PM +0200, Pawel Jakub Dawidek wrote: > > On Tue, Apr 10, 2007 at 01:32:02PM +0200, Ivan Voras wrote: > > > Pawel Jakub Dawidek wrote: > > >=20 > > > >1. Panic if there is no physical storage. This way you protect > > > > consistency. You already printed a warning that gvirstor is runni= ng > > > > out of physical storage, so administrator has a chance to do the = job. > > >=20 > > > I really don't want to do that :( > >=20 > > If you have important data, this is really not bad idea. I, for one, > > prefer my kernel to panic, so I can see what exactly went wrong, add > > another disk and reboot instead of allowing kernel goes into wild by > > returning an error which won't be handled properly. >=20 > It's a terrible idea! What happens to all uncommitted soft updates and > other unwritten cached blocks? Lost forever, which can have bad effects = on > file systems and at the very least require everything to be fsck'd and GE= OM > mirrored or raid objects to be resync'd. What's wrong with ENOSPC? Isn't > that the whole point of that error? Let the admin know that something > failed, don't panic and prevent any further operation period. >=20 > I know I don't want my fileserver to panic just because I accidently try = to > add 100 GB instead of 10 GB or some other simple miscalculation. We have > enough panics in the kernel already for cases that should be handled bett= er > in userland. The choice you have currently is to panic and lost few last seconds of your data, but keep file system in a consistent state, or to return ENOSPC which nobody is going to handle and which may at the end corrupt your file system to a state that fsck won't be able to fix it. This is not about simple write operation to the disk. Those operations are delayed anyway, your userland process will see the write operation succeeded. This is about kernel and file system consistency. It will be great to just fix everything in the kernel to handle errors properly, but good luck with that. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --W/D3X8sky0X3AmG5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGG7mIForvXbEpPzQRAu1yAJ93sEuXV520JrXUG2Xxrj1ONhM4OwCdFkP+ l/zzmy2ChRxfbwWKdYYBEyo= =24t9 -----END PGP SIGNATURE----- --W/D3X8sky0X3AmG5--