linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Moshe Yudkowsky <moshe@pobox.com>
Cc: Carlos Carvalho <carlos@fisica.ufpr.br>, linux-raid@vger.kernel.org
Subject: Re: One Large md or Many Smaller md for Better Peformance?
Date: Tue, 22 Jan 2008 10:30:54 -0500	[thread overview]
Message-ID: <47960C2E.8090706@tmr.com> (raw)
In-Reply-To: <4795D4B6.4070908@pobox.com>

Moshe Yudkowsky wrote:
> Carlos Carvalho wrote:
>
>> I use reiser3 and xfs. reiser3 is very good with many small files. A
>> simple test shows interactively perceptible results: removing large
>> files is faster with xfs, removing large directories (ex. the kernel
>> tree) is faster with reiser3.
>
> My current main concern about XFS and reiser3 is writebacks. The 
> default mode for ext3 is "journal," which in case of power failure is 
> more robust than the writeback modes of XFS, reiser3, or JFS -- or so 
> I'm given to understand.
>
> On the other hand, I have a UPS and it should shut down gracefully 
> regardless if there's a power failure. I wonder if I'm being too 
> cautious?
>
No.

If you haven't actually *tested* the UPS failover code to be sure your 
system is talking to the UPS properly, and that the UPS is able to hold 
up power long enough for a shutdown after the system detects the 
problem, then you don't know if you actually have protection.  Even 
then, if you don't proactively replace batteries on schedule, etc, then 
you aren't as protected as you might wish to be.

And CPU fans fail, capacitors pop, power supplies fail, etc. These are 
things which have happened here in the last ten years. I also had a 
charging circuit in a UPS half-fail (from full wave rectifier to half). 
So the UPS would discharge until it ran out of power, then the system 
would fail hard. By the time I got on site and rebooted the UPS had 
trickle charged and would run the system. After replacing two 
"intermittent power supplies" in the system, the UPS was swapped on 
general principles and the real problem was isolated.

Shit happens, don't rely on graceful shutdowns (or recovery, have backups).

-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark 



  parent reply	other threads:[~2008-01-22 15:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-20 20:24 One Large md or Many Smaller md for Better Peformance? Moshe Yudkowsky
2008-01-20 21:57 ` Iustin Pop
2008-01-21  3:19   ` Moshe Yudkowsky
2008-01-22  2:32     ` Carlos Carvalho
2008-01-22 11:34       ` Moshe Yudkowsky
2008-01-22 15:17         ` Tomasz Chmielewski
2008-01-22 15:30         ` Bill Davidsen [this message]
2008-01-22 15:32         ` Iustin Pop
2008-01-20 22:18 ` Bill Davidsen
2008-01-21  3:17   ` One Large md or Many Smaller md for Better Performance? Moshe Yudkowsky
2008-01-21 10:41   ` One Large md or Many Smaller md for Better Peformance? Ask Bjørn Hansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47960C2E.8090706@tmr.com \
    --to=davidsen@tmr.com \
    --cc=carlos@fisica.ufpr.br \
    --cc=linux-raid@vger.kernel.org \
    --cc=moshe@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).