On Mon, Jun 06, 2011 at 12:53:11PM +0200, Martin Matuska wrote: > I have merged ZFS version 28 to 8-STABLE (revision 222741)
Follow-up, since we're gradually upgrading our ZFS-based RELENG_8 servers to ZFSv28. Committers/those involved should see my very last paragraph. First, server upgrades: We've upgraded 2 of the 4 (including updating zfs and zpools), and so far things are working wonderfully. One of those 2 boxes is our NFS filer (which also does backups via rsync/rsnapshot), so that one's been a big worry-point of mine. The next rsync/rsnapshot runs tonight, so I'll be awake watching intently. All these systems are graphed via bsnmpd (memory, CPU, disk I/O, etc.). Second, performance tweaks: We're testing changing to our tweaks; the following directives have been commented out in our /boot/loader.conf files (e.g. we're now using prefetching): # vfs.zfs.prefetch_disable="1" And the following tunable has been removed completely, because it's now the default in ZFSv28 (see cvsweb, look at line 40 of the relevant commit for src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c): vfs.zfs.txg.timeout="5" Finally, talking a bit about dedup: In the ZFSv28 commit, did the zfs.8 man page get updated? I find no mention of the dedup property in the zfs(8) man page, and yes I did remove the old /usr/share/man/cat8/zfs.8.gz file. We tried using dedup on one of our systems, but within 10-15 minutes turned it off. I believe the added CPU overhead of dedup was causing the system to act "bursty" in other non-ZFS-related tasks; e.g. turn on dedup, then in a SSH window hold down the letter "q" indefinitely, then in another window do some ZFS I/O. The "q" would stall for 1-2 seconds at times (SSH connectivity was via direct private LAN, so network latency was not what we seen). Without dedup this behaviour wasn't seen at all. I'm happy to try any advice/patches on a locally-accessible box (e.g. private LAN, VGA console is right behind me, etc.). I have not tried tinkering with the following settings to find out what may relieve this issue. I'm referring to the sections titled "Trust or verify" and "Selecting a checksum" on Jeff's blog here: http://blogs.oracle.com/bonwick/entry/zfs_dedup All in all, thank you everyone for the work that's gone in to MFC'ing this to RELENG_8. I really do mean that. I'm a harsh bastard on the mailing lists, no question about it. But I always appreciate people doing the grunt work that I myself cannot do (over my head). I state this seriously: if any of you folks who participated in this MFC have donation links (PayPal, etc.), please give them to me. You absolutely will see some worthwhile kick-backs for your efforts, with no strings attached. Just my way of saying "thank you". -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
