On 04/18/10 08:58 PM, James C.McPherson wrote:
On 18/04/10 03:04 AM, Frank Middleton wrote:
We'll do some stress testing on a b134 test system and report back
here if anything interesting results. From your perspective, what
settings of zfs:zfs_vdev_max_pending and zfs_scrub_limit would
be best to provide meaningful results?
None of the usual stress tests I have used in the past seem to cause
stress any more. The caching seems now to be so amazingly efficient
that things that would normally have the disks smoking now cause a
little spike every 10-30 seconds or so, even without a separate ZIL or
l2ARC, and only 4GB to play with. Bonnie++ doesn't seem to cause
6894775 either.
I'll have to set up COMSTAR on this test machine and see if running
a scrub on a scrub will do it any more.
Frankly, I'd much prefer that you log a support call against
this CR and get it escalated.
Alas, we currently don't have a support contract or this would have
been escalated long ago. Maybe someone who does and experiences
6894775-like problems could do so.
I don't have suggestions about the zfs tuning you mention, sorry.
For the purposes of stress testing, left them at the default. So far
6894775 hasn't happened. It looks like you have to be running a
fairly heavy duty iscsi (or perhaps NFS) load to replicate this, if
it can be reproduced at all on b134.
Thanks for taking the time to reply
Cheers -- Frank
_______________________________________________
storage-discuss mailing list
storage-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
