On Thu, Nov 12, 2009 at 3:14 PM, Scott Ullrich <sullrich_at_gmail.com> wrote: > On Thu, Nov 12, 2009 at 3:19 PM, Artem Belevich <fbsdlist_at_src.cx> wrote: >> >> Log seems to be somewhat weak point in ZFS. If you lose your log >> device, you will lose your pool. Plus, there's no way to remove log >> device from the pool. So, once you attach some device as a log, you'd >> better be sure that device does not disappear, because it will take >> the rest of the pool with it. From that point, real ram-disk (i.e. >> /dev/mdN) is definitely a recipe for disaster. External ramdisk with a >> battery backup may be an option, but even in mirrored configuration >> seems rather risky to me. >> >> http://jmlittle.blogspot.com/2008/05/problem-with-slogs-how-i-lost.html >> >> I'd say that SSD are probably the best fit for slog role. > > Indeed. I mirrored 2 SSDs on an Areca in case I loose one of them. > Partitioned the SSD into a log device and the rest being cache (see > the ZFS best practices guide for details). > > Needless to say my performance matches that of normal writes and reads > when using NFS now. if you wouldn't mind posting, what kind of NFS performance can you achieve? my application is office Fileserver (the clients are FreeBSD 8 diskless PXE boot) so idk if it is possible to achieve gigabit NFS performance. iperf is able to get ~970mbit from a client to the NFS server. I realize that disk i/o is the limiting factor so I bought 6x SATA2 disks and a Areca card Sam Fourman Jr.Received on Thu Nov 12 2009 - 20:39:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:57 UTC