Hi Peter, Peter Ross wrote:
The fsck looks more magic than everything else to me (because it has to catch "the unexpected") and if you try "magic" on something that is not fully understood yet.. good luck with that.
Yes, I do agree with that.
At the moment I go for plan B first (backup/failover) instead of praying that magic helps me if it goes pear-shaped.
Correct, but we need to be able to move data faster b/w disks -- restores can take too long with most of the disks we have today, bring on the faster storage ASAP.... do I hear "racetrack ;-)" or fast and cheap SSDs. Yeah, back on that point, we'll have 10GE cards one day as normal instead of just GE -- another one for Russell to pick over ;-)
In that sense it may be a waste of time to write a fsck. However, I can imagine that it helps you to improve the original code. If you write fsck you have to think about "what can go wrong" - and then you are half-way through to fix it (and not relying on fsck).
Yes, absolutely.
I always avoid software that needs "repair tools" in production. E.g. I hated to work with MySQL 3 and having to fix MyISAM tables and indexes if something went wrong.
Fortunately I never used MySQL that long ago .... I use it now, but I also use Oracle plenty. I think that Postgresql is the way to go longer term though, but I haven't even done anything with it yet.
It took me a while until I wanted to touch MySQL again.. These days I do not even remember what the repair tools look like, and I hope I never have to google for it.
;-) At least we have Google and many, many reference points these days when things do go wrong and we need them. You don't always get the answers, but it is far easier today to find the same problems experienced by others as so many people are using the tools. Cheers -- Kind Regards AndrewM Andrew McGlashan