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@xxxxxxxx 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
