On Wed, 2005-09-07 at 21:30 -0500, Les Mikesell wrote: > The reiserfsck runs seemed to work OK so my only complaint > about that part is the oddball syntax needed to actually > make it fix anything. Well, you've had good luck then. > I'm just wondering why it is so likely to need the fsck at > all (maybe 50% of my crashes when busy) On all filesystems? Or just 50% chance that one filesystem will need a fsck? [ SIDE NOTE from a previous thread: Another reason to segment your filesystems is not only to "localize" any fsck, but segmentation actually _reduces_ the risk of needed a fsck because commits are more localized/contained (especially to /tmp, /var, etc...). ] > and if xfs would be better about that. Hmmm, not sure "better" is a good word. As much as I love XFS and have _rarely_ had to run "xfs_repair" and the fact that it does do "on-line" journal replays, that doesn't necessarily mean it's "better." In fact, I still do _not_ trust anything but SGI's specific XFS build. I do not trust the kernel 2.4 backport, and I'm still testing the kernel 2.6 integration. > I thought it was supposed to know what was committed to disk and never > leave it in an inconsistent state. Nope. You through incorrectly. The _only_ purpose of journaling is to _reduce_ the time it takes to make the filesystem consistent. That assumes the journaling is good and/or the journal replay/unplay works. There is absolutely _no_ way to guarantee a commit, although full data journaling with a NVRAM board comes close. -- Bryan J. Smith b.j.smith at ieee.org http://thebs413.blogspot.com ---------------------------------------------------------------------- The best things in life are NOT free - which is why life is easiest if you save all the bills until you can share them with the perfect woman