Possible ZFS patch, please test!

[Henri Hennebert]

Jeremy Chadwick wrote:
> On Sat, Aug 30, 2008 at 09:28:36PM +0200, Henri Hennebert wrote:
>> John Baldwin wrote:
>>> This patch merges a few changes from HEAD back to 7.x.  I think the 
>>> endian changes specifically might solve the issue people saw with 
>>> zpools created with non-dtrace kernels not being readable by dtrace 
>>> kernels and vice versa.
>>>
>>> http://www.FreeBSD.org/~jhb/patches/zfs_7.patch
>>>
>> Just a follow-up
>>
>> I cvsup at Sat Aug 30 12:55 without zfs_7.patch and
>>
>> make buildworld && make buildkernel && make installkernel
>>
>> reboot (-s) --root on zfs is ok -- make installworld
>>
>> reboot
>>
>> System is still sluggish even during the make installworld in single user.
> 
> Sorry if I've missed this, but what tuning have you done for ZFS?  Some
> of us (most of us?) have seen fairly "sluggish" performance when
> prefetch is enabled (the default), while the system is generally more
> responsive when prefetch is disabled.

prefetch is enabled:

vfs.zfs.arc_min: 33554432
vfs.zfs.arc_max: 268435456
vfs.zfs.mdcomp_disable: 0
vfs.zfs.prefetch_disable: 0
vfs.zfs.zio.taskq_threads: 0
vfs.zfs.recover: 0
vfs.zfs.vdev.cache.size: 10485760
vfs.zfs.vdev.cache.max: 16384
vfs.zfs.cache_flush_disable: 0
vfs.zfs.zil_disable: 0
vfs.zfs.debug: 0

> 
> This may have nothing to do with the problem you've stated, but I
> thought I'd throw it out there.

I think that the problem is somewhere else because >80% of system cpu on 
a dual core seems awfully bad - eg more than 20 seconds to open this 
response after clicking on the response button.

Henri
>