Pawel Jakub Dawidek
pjd at FreeBSD.org
Tue Apr 10 16:21:52 UTC 2007
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:
> > >
> > > >1. Panic if there is no physical storage. This way you protect
> > > > consistency. You already printed a warning that gvirstor is running
> > > > out of physical storage, so administrator has a chance to do the job.
> > >
> > > I really don't want to do that :(
> > 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.
> 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 GEOM
> 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.
> 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 better
> 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.
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
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20070410/0105e6dd/attachment.pgp
More information about the freebsd-geom