Help ZFS FreeBSD 8.0 RC2 Write performance issue

James R. Van Artsdalen james-freebsd-current at jrv.org
Fri Nov 13 02:51:35 UTC 2009


Artem Belevich wrote:
> Log seems to be somewhat weak point in ZFS. If you lose your log
> device, you will lose your pool.

In ZFS losing *any* vdev causes a pool to fault!  The log vdev is no
different and is not a weak point in that regard.

In ZFS *every* vdev should be redundant.  In the case of a log this
means a MIRROR since a log cannot be a RAIDZ.  That's not a big deal
since you really should put the MIRROR disks on different controllers,
and preferably using different drives, independent cables & power
supplies, etc.

(I think a cache vdev is different and need not be reliable, but I have
not tested to see what happens if it is not present when the pool is
imported)

The ZIL may have bugs but it's a very important feature to have,
necessary in a transactional filesystem.

A mythical "zfsck" program could probably wipe out the ZIL allowing the
pool to import from the most recent uberblock state and losing a few
seconds of sync's, better than nothing.  Tricking ZFS into importing a
pool with the log vdev missing is probably harder.

> I'd say that SSD are probably the best fit for slog role.

A PCI-e SSD like the OCZ P84 with sustained writes "up to" 600 MB/s
might be a possibility for a high-throughput database server, if it uses
an interface we have a driver for.



More information about the freebsd-current mailing list