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 cache.
The slog SSD is a dedicated function device so there is minimal access latency.
Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
