Date: Tue, 15 Apr 2008 12:05:41 -0500 From: "James Snyder" <jbsnyder@gmail.com> To: "Claus Guttesen" <kometen@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: ZFS & Bittorent -> Hang? Message-ID: <33644d3c0804151005r17095cb1n33117a8e4d8cc09b@mail.gmail.com> In-Reply-To: <b41c75520804150244p1f7c9693w180cb3a0d4416e4c@mail.gmail.com> References: <16447331.post@talk.nabble.com> <ft2fsj$7i7$1@ger.gmane.org> <16491496.post@talk.nabble.com> <b41c75520804150244p1f7c9693w180cb3a0d4416e4c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the followup. I have not yet gotten a reliable test case to reproduce the problem. I've done a number of tests with the zil and/or prefetch on with no hangs. I will be collecting some more data later this week. If anyone knows a source of consistently slow but large torrents (I suppose I could artificially limit bandwidth, or connection states at my router which is running pfSense), that might help for testing. The process that triggered things before was about a gigabyte or two but took around 12 hours to complete. Here's the overall group of variables I'm experimenting with. Stock Kernel vs Recompiled Kerel w/ ULE (stock sources otherwise) ZIL on and off prefetch on and off Should I add or remove anything? I have no idea if ULE may or may not play a role here, but my original failing condition had the zil off, prefetch on, ule for the scheduler. I also had: vm.kmem_size_max="1073741824" (loader.conf) vm.kmem_size="1073741824" (loader.conf) Any recommendations on what to leave running to record what zfs is getting hung on, beside watching states? Since I can fire up things prior to the hang, and they'll keep running if disk isn't hit, I could leave some diagnostics running to display what's blowing up. Thanks! On Tue, Apr 15, 2008 at 4:44 AM, Claus Guttesen <kometen@gmail.com> wrote: > > > http://wiki.freebsd.org/ZFSKnownProblems > > > > > > This looks like #1. > > > > > > > Hmm.. I don't think there's a large amount of transfer between UFS & ZFS, > > unless the client is using /tmp a lot, it should all be on ZFS. > > > > I noted #4 as well, and therefore tried disabling prefetch. I can't seem to > > get it to hang now. I queued up a bunch of different torrents (full freebsd > > 7 amd64 & i386, some other random things), and they all completed without > > leading to me being locked out or any processes waiting on zfs. > > > > I'll try some testing this weekend to see if I can reproduce the lock-up > > again by re-enabling prefetch. Perhaps we can confirm that issue? Should I > > bother with trying to run CURRENT or should any testing I do be done with > > STABLE. I don't see any indication that there might be experimental patches > > for dealing with this or related issues. > > Were you able to reproduce the lock-up by re-enabling prefetch? > > -- > regards > Claus > > When lenity and cruelty play for a kingdom, > the gentlest gamester is the soonest winner. > > Shakespeare > -- James Snyder Biomedical Engineering Northwestern University jbsnyder@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33644d3c0804151005r17095cb1n33117a8e4d8cc09b>