Date: Fri, 27 Aug 2004 15:36:05 -0400 From: Ken Smith <kensmith@cse.Buffalo.EDU> To: Pavel Merdine <fbsdlist@merdin.com> Cc: freebsd-stable@freebsd.org Subject: Re: ffs_alloc panic patch Message-ID: <20040827193605.GC28442@electra.cse.Buffalo.EDU> In-Reply-To: <1076237332.20040827215245@kaluga.ru> References: <1076237332.20040827215245@kaluga.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 27, 2004 at 09:52:45PM +0400, Pavel Merdine wrote:
> Panic is VERY undesirable situation. And I'm in doubt why those people
> who wrote ffs like panics so devotedly:
>
> # grep -c "panic" ffs_alloc.c ffs_softdep.c
> ffs_alloc.c:37
> ffs_softdep.c:108
>
> I think such things are not acceptable in production environment. Why
> those functions cannot just return a failure state and leave system
> working?
Actually it's checks like this and calls to panic that make the system
acceptable in a production environment.
A couple of examples:
- Suppose the code is checking a reference counter, and that
counter has become zero for a file object that the kernel
believes is still in use. This should never happen,
it is an indication that somewhere else there was a programming
bug. Furthermore, that other piece of the system where the
bug lies may have started to use pieces of that file object
for *other* purposes. If you just continue on pretending
nothing happened you wind up with filesystem corruption,
what's on the disk is not necessarily correct. Better to
have the machine crash and reboot than write bad data to
the disk.
- Suppose you have a disk drive that's dying and now what you
write to it isn't necessarily what you read back because it's
dying. Again, much better to panic the machine than to continue
on pretending nothing is wrong. You would not likely have the
ffs code panic the machine for data inside of files for this
sort of situation but if the machine reads data in from the
data structures on the disk that keep track of what files are
inside of which directories, who owns those files, what the
permissions are, what disk blocks the files are actually
sitting on (this is generally known as "metadata") then the
ffs code will typically panic the machine.
- Suppose you as a sys-admin make a mistake, and somehow manage
to set up two disk partitions that partially overlap (don't
laugh, I've seen it happen...). Here you again wind up in a
situation where the filesystem data structures on the disk can
become corrupted. Typically at some point the ffs code will
recognize that the metadata is incorrect and again a panic is
better than trying to carry on pretending nothing is wrong.
None of these things should happen. But they *can* happen and not all
of them are "system bugs" - the second example is out of anyone's control
and the third example is "pilot error". The consequences of not panic-ing
in these situations is having corrupted data on the disks.
--
Ken Smith
- From there to here, from here to | kensmith@cse.buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040827193605.GC28442>