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.