Date: Tue, 10 Apr 2007 19:45:01 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: "Rick C. Petty" <rick-freebsd@kiwi-computer.com> Cc: freebsd-geom@FreeBSD.org Subject: Re: volume management Message-ID: <20070410174501.GA90135@garage.freebsd.pl> In-Reply-To: <20070410172604.GA21036@keira.kiwi-computer.com> References: <20070409153203.GA88082@harmless.hu> <461A5EC6.8010000@freebsd.org> <20070409154407.GA88621@harmless.hu> <evfqtt$n23$1@sea.gmane.org> <20070410111957.GA85578@garage.freebsd.pl> <461B75B2.40201@fer.hr> <20070410114115.GB85578@garage.freebsd.pl> <20070410161445.GA18858@keira.kiwi-computer.com> <20070410162129.GI85578@garage.freebsd.pl> <20070410172604.GA21036@keira.kiwi-computer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2007 at 12:26:04PM -0500, Rick C. Petty wrote: > On Tue, Apr 10, 2007 at 06:21:29PM +0200, Pawel Jakub Dawidek wrote: > >=20 > > 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 >=20 > How can you guarantee the FS is consistent at that point? [...] Because writing data order wasn't messed up. > > It will be > > great to just fix everything in the kernel to handle errors properly, > > but good luck with that. >=20 > That's a worthy goal and something we should be pursuing. After all, > FreeBSD used to be noted for its stability. I wouldn't call panics a sign > of stability.. You're better off invalidating all the geom consumers and > leaving the rest of the system up so an admin can try to recover critical > data, or so the remaining geom providers can continue to function. You don't understand. Do you think that adding 'return' in panic(9) will improve stability of your system? The point I'm trying to make here is that when some random write was lost, your file system is in undefined state and don't worry, it will panic your kernel at some point, but then you won't be able to tell why exactly. Your file system also can be corrupted because of this. UFS probably handle well situations when there is a problem writing data, but there are many places in the code (mostly for metadata) where return value is not checked. Error recovery is hard, even finding all those places, doesn't mean you will be able to do anything useful with those errors without reconstrucing the code. For example ZFS automatically panics when it can't write some important metadata - it doesn't even try to pass the error to userland, because it's simply not that easy. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGG80dForvXbEpPzQRAgRMAKCtchJfr7iX4Xb5GTNLlxYG/7QtIQCfX5PN mJ4jNQHMW9+KRWFTBjq7Jp8= =hpUu -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070410174501.GA90135>