On Mon, Feb 15, 2010 at 01:45:57PM +0100, Bogdan ?ulibrk wrote: > One more thing regarding SSD, will be useful to throw in additional > SAS/SATA drive in to serve as L2ARC? I know SSD is the most logical > thing to put as L2ARC, but will conventional drive be of *any* help in > L2ARC?
Only in very particular circumstances. L2ARC is a latency play; for it to win, you need the l2arc device(s) to be lower latency than the primary storage, at least for reads. This usually translates to ssd for lower latency than disk, but can also work if your data pool has unusually high latency - remote iscsi, usb, some other odd mostly channel-related configurations. If the reason your disks have high latency is simply high load, l2arc on another disk might, maybe, just work to redistribute some of that load, but it will be a precarious balance, and probably need several additional disks, perhaps roughly as many as currently in the pool. By that stage, you're better off just reshaping the pool to use the extra disks to best effect; mirrors vs raidz, more vdevs, etc. Managing all that l2arc will take memory, too. In your case, though, a couple of extra disks dedicated to staging whatever transform you're doing to the backup files might be worthwhile, if it will fit. Even if they make the backup transform itself slower (unlikely if its predominantly sequential), removing the contention impact from the primary service could be a net win. -- Dan.
pgppyQ2MBTeW2.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
