zfs code - Feb 2007 - Assertion due to timer overflow

Hi,

Today one zfs-fuse experienced a problem with a timer overflow on a
32-bit machine with >300 days of uptime.

In arc.c, arc_reclaim_thread() there is an ASSERT(growtime > 0) which
fails in these 2 situations:

- In kernel context, if lbolt wraps around to a negative value. Since
clock_t has 32 bits on 32-bit machines, this will happen after 248.6
days of uptime with a 100 Hz clock tick.

- In user context (ztest), lbolt is defined to be (gethrtime() >> 23),
which gives us a 119 Hz clock tick, so it will wrap around to a negative
value if the machine has more than 208.9 days of uptime.

The attached patch should fix this issue.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: timer.patch
URL:
<http://mail.opensolaris.org/pipermail/zfs-code/attachments/20070223/640128bd/attachment.ksh>

Ricardo Correia wrote:
> Today one zfs-fuse experienced a problem with a timer overflow on a
One zfs-fuse *user* :)
> In arc.c, arc_reclaim_thread() there is an ASSERT(growtime > 0) which
> fails in these 2 situations:
By the way, if my analysis is correct and lbolt wraps around to -2^31
(and not 0) then, once arc.no_grow becomes TRUE, it will never become
FALSE again (for another 200+ days).

So this could be a real problem even on production machines, I believe.