From: Scott Carey <scott@richrelevance.com>
To: "david@lang.hm" <david@lang.hm>, Greg Smith <gsmith@gregsmith.com>
CC: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Date: Fri, 3 Apr 2009 22:24:52 -0700
Subject: Re: Raid 10 chunksize
Thread-Topic: [PERFORM] Raid 10 chunksize
Thread-Index: Acm0wYfaKClMeTW/RaChD/nBrN/OmgAJCZaK
Message-ID: <C5FC3D34.4343%scott@richrelevance.com>
In-Reply-To: <alpine.DEB.1.10.0904031800220.28893@asgard.lang.hm>
Accept-Language: en-US
Content-Language: en
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 4/3/09 6:05 PM, "david@lang.hm" <david@lang.hm> wrote:

> On Fri, 3 Apr 2009, Greg Smith wrote:
>=20
>> Hannes sent this off-list, presumably via newsgroup, and it's certainly =
worth
>> sharing.  I've always been scared off of using XFS because of the proble=
ms
>> outlined at http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc , with m=
ore
>> testing showing similar issues at http://pages.cs.wisc.edu/~vshree/xfs.p=
df
>> too
>>=20
>> (I'm finding that old message with Ted saying "Making sure you don't los=
e
>> data is Job #1" hilarious right now, consider the recent ext4 data loss
>> debacle)
>=20
> also note that the message from Ted was back in 2004, there has been a
> _lot_ of work done on XFS in the last 4 years.
>=20
> as for the second link, that focuses on what happens to the filesystem if
> the disk under it starts returning errors or garbage. with the _possible_
> exception of ZFS, every filesystem around will do strange things under
> those conditions. and in my option, the way to deal with this sort of
> thing isn't to move to ZFS to detect the problem, it's to setup redundanc=
y
> in your storage so that you can not only detect the problem, but correct
> it as well (it's a good thing to know that your database file is corrupt,
> but that's not nearly as useful as having some way to recover the data
> that was there)

Not trying to spread too much kool-aid around, but ZFS does that.

If a mirror set (which might be 2, 3 or more copies in the mirror) detects =
a
checksum error, it reads the other copies and attempts to correct the bad
block.
PLUS, the performance under normal conditions for reads scales with the
mirrors.  12 disks in raid 10 do writes as fast as 6 disk raid 0, but reads
as fast as 12 disk raid 0 since it does not have to read both mirror sets t=
o
detect an error, only to recover.  You can even just write zeros to random
spots in a mirror and it will throw errors and use the other copies.

This really isn't a ZFS promotion, rather its a promotion of the power of
checksums at the file system and raid level.  A hardware raid card could
just as well sacrifice some space to place checksums on its blocks and get
much the same result.


>=20
> David Lang
>=20