On Thu, Jan 28, 2010 at 09:33:19PM -0800, Ed Fang wrote: > We considered a SSD ZIL as well but from my understanding it won't > help much on sequential bulk writes but really helps on random > writes (to sequence going to disk better).
slog will only help if your write load involves lots of synchronous writes; typically apps calling fsync() or using O_*SYNC, and writes via NFS. Random vs sequential isn't important (though sync random writes can be worse for the combination). Otherwise, it won't help. zilstat.sh will help you figure out if it will. If the workload would be helped by slog at all, raidz might be helped the most, since it's the most limited for total IOPS (vs mirror). > Also, doubt L2ARC/ARC will help that much for sequential either. Maybe, maybe not. It depends mostly on how often you re-stream the same content, so the cache can be hit often enough to be worthwhile. At the other end, with decent RAM and lots of repeated content, you might not even see much benefit from l2arc if enough fits in l1arc :) I didn't mention it when talking about performance, even if it might reduce disk load with a good hit ratio, because l2arc (currently) starts cold after each reboot. If you need to stream N clits at rate X, you probably need to do so from boot and can't wait for the cache to warm up. Cache might help you keep doing so after a while, with less work, but for a discussion of the underlying pool storage the base requirement is the same. -- Dan.
pgpYG8yTKYOd5.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
