[EMAIL PROTECTED] said:
> bash-3.00# uname -a SunOS nfs-10-1.srv 5.10 Generic_125100-04 sun4u sparc
> SUNW,Sun-Fire-V440
>
> zil_disable set to 1 Disks are over FCAL from 3510.
>
> bash-3.00# dtrace -n fbt::*SYNCHRONIZE*:entry'{printf("%Y",walltimestamp);}'
> dtrace: description 'fbt::*SYNCHRONIZE*:entry' matched 4 probes
>
> [no output]
>
> Why?
Robert,
I saw this happen in some of my tests. It was quite odd in that one
pool would have no sync's show up, and another pool on the same machine
(and on the same array) would show sync's happening.
The explanation we came up with was that the code remembers if at some
point a sync-cache request failed (e.g. "invalid operation" or some such
error), after which it will no longer issue sync requests (until the next
server reboot, of course).
We never did figure out why the array might've given an error on one set
of LUN's and not on another. Perhaps a queue overrun or some other
condition happened during earlier tests.
Nowadays we have the array configured to ignore the sync requests, and
indeed we never see them in dtrace anymore (on any pool/LUN). Presumably
the array responds "invalid operation" for every such request now.
Regards,
Marion
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
