> Kris Kennaway wrote:
>> Ivan Voras wrote:
>>> On 06/01/2008, Peter Schuller <peter.schuller@infidyne.com> wrote:
>>>>> This number is not so large. It seems to be easily crashed by rsync,
>>>>> for example (speaking from my own experience, and also some of my
>>>>> colleagues).
>>>> I can definitely say this is not *generally* true, as I do a lot of
>>>> rsyncing/rdiff-backup:ing and similar stuff (with many files / large
>>>> files)
>>>> on ZFS without any stability issues. Problems for me have been
>>>> limited to
>>>> 32bit and the memory exhaustion issue rather than "hard" issues.
>>>
>>> It's not generally true since kmem problems with rsync are often hard
>>> to repeat - I have them on one machine, but not on another, similar
>>> machine. This nonrepeatability is also a part of the problem.
>>>
>>>> But perhaps that's all you are referring to.
>>>
>>> Mostly. I did have a ZFS crash with rsync that wasn't kmem related,
>>> but only once.
>>
>> kmem problems are just tuning. They are not indicative of stability
>> problems in ZFS. Please report any further non-kmem panics you
>> experience.
>
> I encounter 2 times a deadlock during high I/O activity (the last one
> during rsync + rm -r on a 5GB hierarchy (openoffice-2/work).
>
> I was running with this patch:
>
http://people.freebsd.org/~pjd/patches/zgd_done.patch
> db> show allpcpu
> Current CPU: 1
>
> cpuid = 0
> curthread = 0xa5ebe440: pid 3422 "txg_thread_enter"
> curpcb = 0xeb175d90
> fpcurthread = none
> idlethread = 0xa5529aa0: pid 12 "idle: cpu0"
> APIC ID = 0
> currentldt = 0x50
>
> cpuid = 1
> curthread = 0xa56ab220: pid 47 "arc_reclaim_thread"
> curpcb = 0xe6837d90
> fpcurthread = none
> idlethread = 0xa5529880: pid 11 "idle: cpu1"
> APIC ID = 1
> currentldt = 0x50
>
> With the 2 times arc_reclaim_thread `running`
