Date: Fri, 18 Mar 2005 19:46:44 +0000 From: Kris Kennaway <kris@FreeBSD.org> To: re@FreeBSD.org Cc: fs@FreeBSD.org Subject: Softupdates overflows, KSTACK_PAGES and lost+found overflows Message-ID: <20050318194644.GE40907@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
I have been running with KSTACK_PAGES=4 for a year or more to avoid
kstack overflows in the softupdates code. These can have very nasty
effects on the filesystem and require extraordinary effort to recover
from. In particular:
[...]
UNREF FILE I=2644995 OWNER=root MODE=100644
SIZE=68792 MTIME=Mar 18 16:14 2005
RECONNECT? yes
SORRY. NO SPACE IN lost+found DIRECTORY
UNEXPECTED SOFT UPDATE INCONSISTENCY
CLEAR? yes
[...]
CLEAR? yes
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes
SUMMARY INFORMATION BAD
SALVAGE? yes
BLK(S) MISSING IN BIT MAPS
SALVAGE? yes
1570569 files, 7143221 used, 5848860 free (440012 frags, 676106 blocks, 3.4% fragmentation)
***** FILE SYSTEM WAS MODIFIED *****
At this point the system allows me to mount the filesystem, even
though it is still corrupted.
In order to actually get a clean filesystem I have to move aside
lost+found and recreate it, and then rerun fsck. This needs to be
repeated up to a dozen times until all of the errors are repaired.
Recently I decreased KSTACK_PAGES to 3 to see if I could provoke the
bug again. I could :) This means that KSTACK_PAGES=4 is necessary to
provide reasonable protection against the problem. Please commit this
change for 5.4-R, because I'm sure other people in the real world will
be able to duplicate my disk load. Also, fsck needs to be fixed to
not pretend that the filesystem is clean when it knows it hasn't been
able to fix all of the problems because lost+found filled up.
Kris
--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <forsythe@alum.mit.edu>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050318194644.GE40907>