I took note of this, only because I run a high-availability linux system
(24x7) in a medical environment, and just installed 2.0.36. When I rebooted
to 2.0.36, from 2.0.34, fsck was forced on all filesystems because the
time-since-last-check was exceeded (about 160 days since last reboot). And
what I found was filesystem corruption. When the 2.0.34 kernel shut down, it
noted some stuck dquots as it was turning off quotas.
Then as 2.0.36 booted and fsck ran, it reported quite a number of inodes with
zero dtime, and a few dozen block-bitmap differences - usually what I would
expect to see if fscking on an improperly shut down filesys, excepting that
no unexpected crashes had occurred. The system also has a 3c509. Anyhow,
FYI.
-- Kristofer Karas * Senior systems engineer/SysAdmin AMA/CCS DoD RF900RR HawkGT !car * BI Deaconess Medical Center, Boston "Build a system that even a fool can use, * http://ktk.bidmc.harvard.edu/~ktk/ and only a fool will want to use it." * Will design LISP machines for food
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/