This thread is quite interesting. I think it comes to the following
questions:
- Is the reiserfs stable enough?
- Is the overhead of reiserfs acceptable?
- Is the time to 'fsck' valuable enough to justify the cost?
- Is the reiserfs stable enough?
For all I heard, the answer is more likely to be YES. However, I do
agree that 'only the paranoid survives'. If one has any worry, no risk
is worth taking when there is an alternative.
- Is the overhead of reiserfs acceptable?
Many responded to this thread said NO. But then there is at one said it
is not only acceptable, but it make things faster! The same is
mentioned in the reiserfs web page. My experience in reiserfs is too
limited to comment. But for those who said no, have you tried the
latest version of reiserfs? Is that only bad memory of some early
versions?
- Is the time to 'fsck' valuable enough to justify the cost?
Well, it depends on what your system does. On some systems, occasional
reboots are required. When these happen in the busy hours, every minute
counts. It is worse when you do not know what made the system reboot.
And that will be extremely frustrating to know that you have to wait for
minutes, if not hours, to find out. So for those system, I would say
YES. Put the reiserfs on. If performance is an issue, spend a little
bit to improve it. Right hardware are cheap. CPU cycles cost almost
nothing.
Dave Ihnat wrote:
>
> On Mon, Jan 29, 2001 at 07:53:17PM -0500, Chris Colomb wrote:
> > If you're in that percentage that's small comfort.
>
> Quite true. The choice is, however, to determine what recovery costs are
> acceptable. It may be acceptable to simply tolerate a long fsck, since it's
> a once-in-a-blue-moon event. Or to recover from backup tape. OR, if none
> of the other options are acceptable, to implement a journaling filesystem.
>
> > There was a hardware failure in the device that switches to battery.
> > But that's not really the point.
>
> Oh, but that very much IS the point--there should never be a single point-of-
> failure in such a system! The tell-tale phrase above is "the device"--it
> clearly wasn't redundant, and provided a single point of failure. (Who made
> this system? I want to avoid it.)
>
> > As you put earlier...gently, gently.
>
> Yes; you're quite right. I apologize.
>
> > Right. And that's why Linux isn't being used for any of our large data
> > mission critical applications. It doesn't take a catastrophic failure to
> > put one in such a situation. And it doesn't have to be about a UPS...you
> > get the same issues if, say, the kernel panics. Or if someone kicks a cord
> > by mistake. Stuff happens, despite one's best efforts to the contrary.
>
> Well, perhaps. I see about the same level of kernel panics, driver errors,
> etc. on current commercial Linux distributions as I've had to live with in
> commercial Unix systems over the last 20 years.
>
> And while I've been through cord-kicking, too, I always have to look at that
> as cockpit error--there shouldn't BE a cord to kick in a mission-critical
> installation.
>
> > They were. However the automatic fsck halted, as it should, because the
> > damage was too extensive. Which is when manual intervention was required.
>
> Hmm. Yes, that's a bad situation. I'd be even more ticked at whoever
> designed the UPS.
>
> > The point being, with IBM AIX, SGI, Sun none of that was necessary as it
> > never came to that in the first place.
>
> Well, I certainly have had those problems with all those platforms
> at one time or another in the past. Believe me, it's not a matter of
> orders-of-magnitude any more.
>
> > Journaling hardly has to be a universal solution to be extremely valuable
> > and very much worth implementing. The 3/4 of the life of Unix argument is
> > interesting in that it leads into what I think is really the issue at
> > hand, one of best practices.
>
> Yes. And incidentally, I thoroughly agree that one problem we're going to
> continue to see in Linux is that the "non-sexy" features will be slow in
> coming--or won't come, and will be commercial extensions.
>
> > Best practices is all about using the tools available to you in the most
> > advantageous way possible, given the state of the technology you're
> > working with. What is best practice changes over time...what could have
> > been considered acceptable a couple of years ago can be an unecessary risk
> > today.
>
> Yes; most certainly agreed.
>
> > What I don't think you're acknowledging in your statements is that, um,
> > stuff happens. Despite all one's best attempts at planning etc.
>
> No--I've said all along it's a matter of probability and cost/benefit analysis.
> That pretty explicitly assumes there's always risk. The important point is
> that there *are* silly things that most certainly can be prevented--and those
> live squarely under the rubric of "best practices".
>
> > Some things you can't really plan for, like say a meteor hits your
> > machine room (though some folks actually do plan for things like this)
> > but are pretty remote possibilities.
>
> I'm *so* glad you added that--I'm one of those folks. I've planned both
> wholly-owned and leased off-site replacement facilities. I've written
> plans to totally reconstruct an installation, up to and including
> having to go out and buy new but compatible hardware and restoring
> from vault tapes. There are people out here who make a living out of
> being paranoid; the only real question, as that old joke goes, is are
> we paranoid _enough_.
>
> > Most management I've worked with/for understands that stuff beyond your
> > control happens, and you won't get fired for that. What *will* get you
> > fired is if there was a prevalent industry practice that you could have
> > been implementing to prevent the problem in the first place, and you
> > weren't doing it.
>
> Yes; or if you can't show, _before_ the problem, that you considered both
> the possiblity of that problem and its associated costs, and the course
> you took was one that had been evaluated and approved. (It's gratifying
> to point out to the CEO that you *did* ask for that fully redundant UPS
> installation, and when the CFO refused, you had to take the second-best
> soluition (It's gratifying to point out to the CEO that you *did* ask
> for that fully redundant UPS installation, and when the CFO refused,
> you had to take the second-best solution. It's more gratifying if you
> can show that your solution still saved the data...)
>
> I don't really think we're disagreeing about ultimate ends--in a
> mission- critical installation, all risks must be assessed, and costs
> for mitigating them compared to the perceived benefits.
>
> Our only difference is in the perception of current risk levels in
> Linux vs. commercial Unix; and in the relative benefits of journaling
> filesystems _for most installations_. That's fair grounds for discussion,
> but probably has passed beyond the bounds of relevance for this discussion
> group.
>
> Cheers,
> --
> Dave Ihnat
> [EMAIL PROTECTED]
>
> _______________________________________________
> Redhat-list mailing list
> [EMAIL PROTECTED]
> https://listman.redhat.com/mailman/listinfo/redhat-list
--
Regards,
Clement
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
