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

Olivier Smedts wrote:
> Hi,
> 
> 2012/11/28 O. Hartmann <ohartman_at_zedat.fu-berlin.de>:
> > 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?
> 
> You don't "need" two because if the ZIL is corrupted you'll only loose
> the data since the last TXG, but no metadata. Make sure you have an
> up-to-date pool.
> 
Be careful here. When an NFS client does write, ..., commit and the NFS
server replies OK, the client assumes the data is "safe" and will no
longer cache it.

Take the following simple example:
- User on a client edits a file and then saves it. No errors are reported,
  and the client doesn't crash, so the user assumes the saved data is "safe".
- NFS server crashes and loses the one ZIL, losing the data. The User/client
  will not know the data was lost (might have seen the "server not repsonding...
  server ok" message, but that's all.)
- User discovers months later that the change to the file is somehow missing
  and is Not Happy.

If a user sees the client crash, they will suspect the data was lost, but they
won't expect that if the client keeps running and doesn't report errors.

I'd want the ZIL mirrored if I was setting this up, but I can't say how
serious the above failure might be for your environment. (Some are happy
with "sync=disabled").

rick

> But you'll *need* a battery cache or supercaps on the SSD(s) so that
> they flush their caches in case of a power failure.
> 
> > 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).
> 
> I don't think so, or not much. What makes SSDs appealing for ZIL is
> that they have very good access times / latencies.
> 
> > 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
> 
> Cheers
> 
> --
> Olivier Smedts _
> ASCII ribbon campaign ( )
> e-mail: olivier_at_gid0.org - against HTML email & vCards X
> www: http://www.gid0.org - against proprietary attachments / \
> 
> "Il y a seulement 10 sortes de gens dans le monde :
> ceux qui comprennent le binaire,
> et ceux qui ne le comprennent pas."
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe_at_freebsd.org"