Re: ffs_alloc panic patch

From: Ken Smith (kensmith_at_cse.Buffalo.EDU)
Date: 08/27/04

  • Next message: Ken Smith: "Re: ffs_alloc panic patch" 
    Date: Fri, 27 Aug 2004 15:36:05 -0400
To: Pavel Merdine <fbsdlist@merdin.com>

    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 |
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
  • Next message: Ken Smith: "Re: ffs_alloc panic patch"

    Relevant Pages

    • Re: ffs_alloc panic patch
      ... > who wrote ffs like panics so devotedly: ... mechanism -- if something goes awry in the filesystem code, ... Rather than take that chance, the system panics, which attempts to ...
      (freebsd-stable)
    • ffs_alloc panic patch
      ... I'd like to propose the following patch: ... It should solve the problem of "panic: integer divide fault" on the ... who wrote ffs like panics so devotedly: ...
      (freebsd-stable)