ZFS: ZIL with only one additional disk and how secure?

From: O. Hartmann <ohartman_at_zedat.fu-berlin.de>
Date: Wed, 28 Nov 2012 14:29:26 +0100
Hello,
I have a naive question.
I read about speeding up NFSv4 shared ZFS array. I use a RAIDZ1 volume
made up from 5 times 3TB harddrives, attached to a ICH10 SATA controller
on a FreeBSD 10.0-CURRENT box. The maximum performance of that array
never goes beyond 45 - 51 MB/s and levels out very often at 12 - 35 MB/s
when used as a NFSv4 share and 1 GBit LAN. The local system harddisk,
attached to the sixth SATA port of the same controller and containig a
UFS2 filesystem, is capable of doing tasks with 60 - 80 MB/s (peak) when
used as a NFSv4 share with another FreeBSD 10.0-CURRENT box.

I used several reported tweaks on the RAIDZ1 ZFS volume exporting it as
a NFSv4 volume, so I was capable of raising the throughput from sad 3
MB/s up to the 30 MB/s sustained.

Also I was told that adding a dedicated ZIL drive could speed up things
up to 90 MB/s with the mentioned construction of a RAIDZ1 over NFSv4. It
is always suggested to add SSDs, a pair, for security reasons.

My question in conrete is now: Do I need two (2) ZIL drives in a mirror?
I guess this is considered due to security issues which lead to the next
question: If it is possible to use only one ZIL drive and this drive
gets corrupted, is the whole ZFS array corrupted, then?

The minor question regards to the use of SSDs: Is it possible to gain
speedup also from an ordinary disk dedicated to the ZFS array connected
to a additional SATA controller? The SATA controller should be fast
enough to serve a bandwith of 90 - 100 MB/s (theoretically) over 1 GBit
lines when using the ZFS array as a NFSv4 export (the LAN is limiting,
so, but 80 - 90 MB/s is possible on the specific box, the limiting
factor at the moment is the bad performance of ZFS).

The box is a quad core system at 3 GHz (Intel Q6600) with 8 GB of RAM
running most recent FreeBSD 10.0-CURRENT/amd64.

Thanks in advance,

Oliver


Received on Wed Nov 28 2012 - 12:29:34 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:32 UTC