ZFS & Bittorent -> Hang?

[jbsnyder]

OK.  I've been able to reproduce the issue.

Conditions:
- Stock shipped kernel and modules from RELENG 7.0

loader.conf settings:
- zfs prefetch enabled
- zfs zil disabled
- vm.kmem_size_max="1073741824"
- vm.kmem_size="1073741824"

AMD64 on Core 2 Duo w/ 4 GB RAM

raidz across 4 disks, using root on zfs (also experienced this hang with zfs
just on /usr)

How To Reproduce
- install transmission-daemon, run transmission-daemon (it will daemonize,
automatically backgrounding)
- grab a torrent, such as KNOPPIX (http://torrent.unix-ag.uni-kl.de/)
- transmission-remote -a <torrentfile> (add the torrent)
- transmission-remote -s all  (start all the torrents)

wait hours to a day or so with whatever you want logging things running and
active since anything that hits disk after the hang will get hung as well

I've just done this twice.  It doesn't seem to happen with zil enabled and
prefetch off.

Expected Behavior
No hang.


jbsnyder wrote:
> 
> 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 at 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 at gmail.com
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
> 
> 

-- 
View this message in context: http://www.nabble.com/ZFS---Bittorent--%3E-Hang--tp16447331p16763410.html
Sent from the freebsd-stable mailing list archive at Nabble.com.