Date: Tue, 29 Jul 2008 02:10:58 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-fs@freebsd.org Cc: freebsd-current@freebsd.org Subject: Re: ZFS patches. Message-ID: <g6ln6j$c7k$2@ger.gmane.org> In-Reply-To: <20080727125413.GG1345@garage.freebsd.pl> References: <20080727125413.GG1345@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA0BAA7E21CDCC347012E0BFE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Pawel Jakub Dawidek wrote: > Hi. >=20 > http://people.freebsd.org/~pjd/patches/zfs_20080727.patch.bz2 >=20 > The patch above contains the most recent ZFS version that could be foun= d > in OpenSolaris as of today. Apart for large amount of new functionality= , > I belive there are many stability (and also performance) improvements > compared to the version from the base system. >=20 > Check out OpenSolaris website to find out the differences between base > system version and patch version. >=20 > Please test, test, test. If I get enough positive feedback, I may be > able to squeeze it into 7.1-RELEASE, but this might be hard. I currently don't have high-end (4 CPU+) AMD64 machines to test, but=20 with 1 CPU i386 virtual machine in VMWare, with 1 GB of memory,=20 kmem_size=3Dkmem_size_max=3D512M and no other tuning, with latest zpool=20 format (11) it took about 15 minutes to get a "kmem_map too small" panic = on a mixed load (buildkernel + blogbench + bonnie++). I've then tried the same load on the "real" hardware, 2 CPU, 2 GB=20 memory, kmem_size=3Dkmem_size_max=3D512M, and no other tuning, with the=20 older zpool format (6) i get the same panic, though it takes about twice = as long to happen. In both cases, iostat was running and I noticed there's about 30 seconds = of complete inactivity (CPU 100% idle, no IO on any drives) just before=20 the panic. Locking issue? In the second case I was also monitoring the=20 system more closely and before the inactivity period the IO bandwidth=20 gets really slow, considering the type of load I'm generating: cca 2=20 MB/s, with all tasks except bonnnie++ stopped (SIGSTOP), and bonnie++=20 generating large-block writes. This is what provoked the panic in the=20 second case. Core dumps are available, as always. But, overall, I see a definite improvement here. Before the new patch I=20 could panic the machine within a minute and now it can survive much more = beating. If the other problems (deadlocks) are solved, I'd say it's=20 worth the effort to get it in 7.1 - considering what's in 7.0, any=20 improvement helps. --------------enigA0BAA7E21CDCC347012E0BFE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIjmATldnAQVacBcgRAt/2AKC4ZIAiZmHkA8R2dUQdmIE7KEZgGgCg8cg7 QMydE4g4+iC8TdenfyWj6nw= =qEt6 -----END PGP SIGNATURE----- --------------enigA0BAA7E21CDCC347012E0BFE--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?g6ln6j$c7k$2>