Date: Tue, 2 Dec 2008 21:33:09 +0100 From: Peter Schuller <peter.schuller@infidyne.com> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: HEADS UP: New ZFS in the tree. Message-ID: <20081202203308.GA13818@hyperion.scode.org> In-Reply-To: <20081117205526.GC1733@garage.freebsd.pl> References: <20081117205526.GC1733@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
--BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I just upgraded my workstation to CURRENT for the purpose of testing ZFS. I wanted to report one anomoly that I have seen so far, that I never saw before and that I do not recognize from other posts. I had ktorrent seemingly hang. The process is in state TL, and does not respond to SIGKILL. SIGCONT also has no effect; neither has SIGSTOP followed by SIGCONT. Though I do not know how ktorrent works internally, the typical behavior, and behavior that I saw just prior to this hang, is one of periodically flushing out a lot of (bittorrent, not file system) blocks. This happens to the point that the pool is more or less saturated for the duration of these bursts (when downloading quickly; around 10 MB/sec in this case). So possibly the triggering factor is quick writing of a lot of randomly located blocks in a handful of files. The current kernel has WITNESS/INVARIATNS, but I did not see anyting in dmesg subsequent or just prior to this hang. Both the pool and the file system seem fully functional; this is distinct from the "hang in zfs state" issue that I see every now and then on 7.0 whereby the affect ZFS file systems will be completely inoperable (but not the entire pool). The sources were cvsup:ed late yesterday. The pool consists of two mirrored vdev:s with one hot spare. The on-disk format is 6 (I have not yet upgrade:d the pool nor any file systems). This is on an amd64 dual-core system with 4 GB:s of RAM. No ZFS related loader variables remain in loader.conf (I let it auto-tune the ARC to around 600 MB). The file system on which ktorrent was doing it's bulk I/O has its recordsize set to 8 kb, but is otherwise standard (no compression or funny options). --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk1m4QACgkQDNor2+l1i321fgCeI3gIhLMr4SjoqqVjfnm/ATuC baoAoIeqEftXjk+AI74IhbygzLTlQEly =jRP0 -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081202203308.GA13818>