ZFS RaidZ2 with 24 drives?

Bernd Walter ticso at cicely7.cicely.de
Fri Jan 1 22:39:54 UTC 2010


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 at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.


More information about the freebsd-fs mailing list