|
|
Hello Enda,
Thursday, April 12, 2007, 2:36:39 PM, you wrote:
EOCSMSI> Robert Milkowski wrote:
>> Hello Enda,
>>
>> Wednesday, April 11, 2007, 4:21:35 PM, you wrote:
>>
>> EOCSMSI> Robert Milkowski wrote:
>>>> Hello zfs-discuss,
>>>>
>>>> In order to get IDR126199-01 I need to install 120473-05 first.
>>>> I can get 120473-07 but everything more than -05 is marked as
>>>> incompatible with IDR126199-01 so I do not want to force it.
>>>>
>>>> Local Sun's support has problems with getting 120473-05 also so I'm
>>>> stuck for now and I would really like to get that IDR running.
>>>>
>>>> Can someone help?
>>>>
>>
>> EOCSMSI> Hi
>> EOCSMSI> This patch will be on SunSolve possibly later today, tomorrow at
>> latest
>> EOCSMSI> I suspect as it has only justed being pushed out from testing.
>> EOCSMSI> I have sent the patch in another mail for now.
>>
>> Thank you patch - it worked (installed) along with IDR properly.
>>
>> However it seems like the problem is not solved by IDR :(
>>
EOCSMSI> Hi Robert
EOCSMSI> So this IDR has two bugs as fixed
EOCSMSI> 6458218 assertion failed: ss == NULL
EOCSMSI> 6495013 Loops and recursion in metaslab_ff_alloc can kill performance,
EOCSMSI> even on a pool with lots of free data
EOCSMSI> I have add'ed the IDR's requestors as they can comment, which one of
the
EOCSMSI> above fixes was not solved via this IDR in your testing.
I'm talking about 6495013 Loops and recursion in metaslab_ff_alloc can
kill performance.
I've got to test again with dtrace during peak hours if recursion
still happens (on that scale) or maybe it's not. The problem is that
during peak hours I still (again) can see performance problems. At
first glance it looks like this time CPU is probably NOT a problem, so
it would seem as 6495013 is indeed fixed and the problem is somewhere
else. As I send|recv all file systems to another server and than back
to the same server (after re-creating pool) before applying IDR it
solved problem with a performance for some time. Not it again is
getting worse day by day, and the IDR seems not to help. So perhaps
there is a problem with zfs data fragmentation - that's why zfs
sedn|recv helped and 6495013 made it only worse.
??
Do you have any specific dtrace script in mind to test if 6495013 is
solved or should I use the same as in the case?
--
Best regards,
Robert mailto:rmilkowski@xxxxxxxxxxx
http://milek.blogspot.com
_______________________________________________
zfs-discuss mailing list
zfs-discuss@xxxxxxxxxxxxxxx
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
|
|