On Tue, 4 Aug 2009, Ross Walker wrote:
But this MUST happen. If it doesn't then you are playing Russian
Roulette with your data, as a kernel panic can cause a loss of up to
1/8 of the size of your system's RAM (ZFS lazy write cache) of your
iSCSI target's data!
The actual risk (with recent zfs) seems to be 7/8ths RAM (not 1/8),
sufficient data to accomplish 5 seconds of 100% write, or up to 30
seconds of aggregation time. On a large memory system with high
performance I/O, this can represent a huge amount (gigabytes) of data.
Actually I recommend using a controller with an NVRAM cache on it, say
256MB-512MB (or more).
This is much faster then SSD and has the advantage that the ZIL is
stripped across the pool making ZIL reads much faster!
Are you sure that it is faster than an SSD? The data is indeed pushed
closer to the disks, but there may be considerably more latency
associated with getting that data into the controller NVRAM cache than
there is into a dedicated slog SSD. Remember that only synchronous
writes go into the slog but all writes must pass through the
controller's NVRAM, and so synchronous writes may need to wait for
other I/Os to make it to controller NVRAM cache before their turn
comes. There may also be read requests queued in the same I/O channel
which are queued before the synchronous write request.
Tests done by others show a considerable NFS write speed advantage
when using a dedicated slog SSD rather than a controller's NVRAM
The slog SSD is a dedicated function device so there is minimal
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
zfs-discuss mailing list