Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Jan 2010 23:39:08 +0100
From:      Bernd Walter <ticso@cicely7.cicely.de>
To:        Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
Cc:        "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>, "ticso@cicely.de" <ticso@cicely.de>
Subject:   Re: ZFS RaidZ2 with 24 drives?
Message-ID:  <20100101223907.GX43739@cicely7.cicely.de>
In-Reply-To: <alpine.GSO.2.01.1001011538130.1586@freddy.simplesystems.org>
References:  <55389.88569.qm@web112405.mail.gq1.yahoo.com> <20100101204752.GW43739@cicely7.cicely.de> <alpine.GSO.2.01.1001011538130.1586@freddy.simplesystems.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 01, 2010 at 03:45:19PM -0600, Bob Friesenhahn wrote:
> On Fri, 1 Jan 2010, Bernd Walter wrote:
> >
> >Everyone do this if the board dies and needs replacement.
> >Not willingly, but it happens.
> >And what about zfs export - relocate disks to another machine - and
> >zfs import - without halt?
> >It is less safe if a cache flush won't flush its cache.
> >The real purpose to have buffered cache is to handle asyncronity in
> >RAID systems after power failure, but RAIDZ won't have this problem
> >by design, at least if running with CRC enabled.
> 
> A proper write-through cache should automatically commit itself (in 
> order) to backing store within a second or two.  Other than cache 
> designs which are not "proper" (which we should not use) the main 
> concern is if the system loses power or crashes while it is producing 
> a significant write load so that there is uncomitted data in cache.

There are many possible reasons why this won't happen.
One of them is a simple write failure, which can't be reported back
to the filesystem, because not even a cache flush fails.
Yes - the risk might be tolerable for many people and I don't think it
is very high.
The main problem I see is that such controllers won't tell about
their strategy, so you are left in the dark.

> ZFS is not particularly more likely to lose user data, but it is much 
> more likely to detect and report loss since most other filesystems 
> don't even check, or even have a way to check.

Agreed.
And ZFS can win a lot from fast flushes.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100101223907.GX43739>