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). -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller_at_infidyne.com>' Key retrieval: Send an E-Mail to getpgpkey_at_scode.org E-Mail: peter.schuller_at_infidyne.com Web: http://www.scode.org
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:38 UTC