volume management

[Pawel Jakub Dawidek]

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:
> > 
> > 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
> 
> 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.
> 
> 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.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20070410/8746504a/attachment.pgp