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
>> 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
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
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?
zfs-discuss mailing list