All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Cc: Tomasz K?oczko <kloczek@rudy.mif.pg.gda.pl>,
	Diego Calleja <diegocg@gmail.com>,
	Christoph Hellwig <hch@infradead.org>,
	Stefan Richter <stefanr@s5r6.in-berlin.de>,
	Jan Engelhardt <jengelh@linux01.gwdg.de>,
	Mike Snitzer <snitzer@gmail.com>, Neil Brown <neilb@suse.de>,
	"David R. Litwin" <presently42@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: ZFS with Linux: An Open Plea
Date: Wed, 18 Apr 2007 13:39:47 -0400	[thread overview]
Message-ID: <462657E3.3000004@garzik.org> (raw)
In-Reply-To: <20070418172519.GA5577@csclub.uwaterloo.ca>

Lennart Sorensen wrote:
> On Mon, Apr 16, 2007 at 10:18:45PM +0200, Tomasz K?oczko wrote:
>> Of cources it can be true in most cases (probably for some more advanced 
>> RAID controlers). Few weeks ago I perform some basic test on Dell 2950 
>> with 8x73GB SAS disk .. just as for kill time (waiting for access to some 
>> bigger box ;). This small iron box have inside RAID controller (Dell uses 
>> in this box LSI Logic SAS MegaRAID based ctrl). Anykind combinations on 
>> controler level RAID was slower than using this as plain JBOD with LVM or 
>> MD+LVM. Diffrence between HW and soft RAID was not so big (1-6% depending 
>> on configuration) but allways HW produces worser results (don't ask me 
>> why). Finaly I decide using this disk as four RAID1 luns only because 
>> under Linux I can't read each phisical disk SMART data and protecting this 
>> by RAID on controller level and collecting SNMP traps from DRAC card was 
>> kind of worakaround for this (in my case it will be better constanlty 
>> monitor disk healt and collesting some SMART data for observe trends on 
>> for example zabbix graphs for try predict some faults using triggers). On 
>> top of this was configured diffrent types of volumes on LVM level (some 
>> with stripping some without, some with bigger some with smaller chunk 
>> size).
> 
> Does it matter that google's recent report on disk failures indicated
> that SMART never predicted anything useful as far as they could tell?
> Certainly none of my drive failures ever had SMART make any kind of
> indication that anything was wrong.
> 
> I think the main benefit of MD raid, is that it is portable, doesn't
> lock you into a specific piece of hardware, and you can span multiple
> controllers, and it is likely easier to have bugs in MD raid fixed that
> in some raid controller's firmware if any were to be found.  Performance
> advantages are a bonus of course.

SMART largely depends on how you use it.  Simply polling the current 
status will not give you all the benefits SMART provides.  On the 
dedicated servers that I rent, running the extended test ('-t long') 
often finds problems before you start losing data, or deal with a drive 
death.  Certainly not a huge sample size, but it backs up what I hear in 
the field.  Running the SMART tests on a weekly basis seems most 
effective, though you'll want to stagger the tests if running in a RAID set.

	Jeff




  reply	other threads:[~2007-04-18 17:40 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-13 23:18 ZFS with Linux: An Open Plea David R. Litwin
2007-04-13 23:43 ` Neil Brown
2007-04-14 12:16   ` Christoph Hellwig
2007-04-14 14:04   ` Mike Snitzer
2007-04-14 20:53     ` Jan Engelhardt
2007-04-16  9:40       ` Tomasz Kłoczko
2007-04-16 11:19         ` John Anthony Kazos Jr.
2007-04-16 14:02         ` Stefan Richter
2007-04-16 14:20           ` Tomasz Kłoczko
2007-04-16 14:55             ` Christoph Hellwig
2007-04-16 15:46               ` Tomasz Kłoczko
2007-04-16 15:59                 ` Christoph Hellwig
2007-04-16 19:02                 ` Diego Calleja
2007-04-16 20:18                   ` Tomasz Kłoczko
2007-04-18 17:25                     ` Lennart Sorensen
2007-04-18 17:39                       ` Jeff Garzik [this message]
2007-04-27  5:21                       ` Valerie Henson
2007-04-27 21:57                         ` Matt Mackall
2007-04-16 19:46                 ` Jörn Engel
2007-04-16 18:19             ` Stefan Richter
2007-04-16 19:21               ` Bernd Eckenfels
2007-04-16 19:26                 ` Lee Revell
2007-04-16 20:20                   ` Bernd Eckenfels
2007-04-16 20:15                 ` Stefan Richter
2007-04-14 21:13     ` Bill Huey
2007-04-16  9:58     ` Tomasz Kłoczko
     [not found]       ` <170fa0d20704160507w4af4cb92ua259a55789f95c3e@mail.gmail.com>
2007-04-16 14:01         ` Tomasz Kłoczko
2007-04-16 14:30           ` Adrian Bunk
2007-04-16 15:27             ` Tomasz Kłoczko
2007-04-16 17:21               ` Adrian Bunk
2007-04-14 18:56   ` Krzysztof Halasa
2007-04-16  3:00     ` David Chinner
2007-04-15  4:16 ` Kasper Sandberg
2007-04-15 21:58 ` Jesper Juhl
2007-05-02 15:03 ` Tomasz Kłoczko
2007-05-02 15:42   ` Alan Cox
2007-05-02 20:53     ` Theodore Tso
  -- strict thread matches above, loose matches on Subject: below --
2007-04-14 17:40 Ignatich
2007-04-15 12:44 ` Nikita Danilov
2007-04-17 14:14   ` Alan Cox
2007-04-15  8:54 David R. Litwin
2007-04-16  0:50 ` Rik van Riel
2007-04-16  3:07   ` David Chinner
2007-04-15  8:57 David R. Litwin
2007-04-15 17:34 ` Kasper Sandberg
2007-04-17  6:54 David R. Litwin
2007-04-17  8:18 ` Miklos Szeredi
2007-04-17 13:10 ` Theodore Tso
2007-04-17 13:47   ` Tomasz Kłoczko
2007-04-17 13:59     ` Matthew Garrett
2007-04-17 15:46       ` Tomasz Kłoczko
2007-04-17 15:59         ` Alan Cox
2007-04-17 16:29         ` Daniel Hazelton
2007-04-17 19:58           ` Tomasz Kłoczko
2007-04-17 22:19             ` Daniel Hazelton
2007-04-17 22:12               ` David Lang
2007-04-17 22:52                 ` Daniel Hazelton
2007-04-17 22:38               ` Roland Dreier
2007-04-17 14:06     ` Erik Mouw
2007-04-17 14:32     ` John Anthony Kazos Jr.
2007-04-17 15:41       ` Tomasz Kłoczko
2007-04-17 16:02         ` John Anthony Kazos Jr.
2007-04-17 14:37     ` Diego Calleja
2007-04-17 14:48     ` Alan Cox
2007-04-17 15:06       ` Ricardo Correia
2007-04-17 15:23         ` Xavier Bestel
2007-04-17 15:30           ` Ricardo Correia
2007-04-17 15:36             ` Alan Cox
2007-04-17 16:02       ` Mike Snitzer
2007-04-17 16:57       ` Alistair John Strachan
2007-04-18 11:10       ` Manoj Joseph
2007-04-18 11:23         ` Alan Cox
2007-04-18 11:32           ` Manoj Joseph
2007-04-17 16:22     ` Daniel Hazelton
2007-04-17 17:50       ` Theodore Tso
2007-04-17 19:24         ` Florian Weimer
2007-04-17 19:56           ` Ricardo Correia
2007-04-17 20:05             ` Ricardo Correia
2007-04-17 14:59   ` linux-os (Dick Johnson)
2007-04-17 15:08     ` Xavier Bestel
2007-04-17 15:12       ` linux-os (Dick Johnson)
2007-04-17 15:29     ` Michal Schmidt
2007-04-17  8:42 David R. Litwin

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=462657E3.3000004@garzik.org \
    --to=jeff@garzik.org \
    --cc=diegocg@gmail.com \
    --cc=hch@infradead.org \
    --cc=jengelh@linux01.gwdg.de \
    --cc=kloczek@rudy.mif.pg.gda.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lsorense@csclub.uwaterloo.ca \
    --cc=neilb@suse.de \
    --cc=presently42@gmail.com \
    --cc=snitzer@gmail.com \
    --cc=stefanr@s5r6.in-berlin.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.