ZFS kmem_map too small.
韓家標 Bill Hacker
askbill at conducive.net
Tue Oct 9 13:13:31 PDT 2007
Darren Reed wrote:
> Pawel Jakub Dawidek wrote:
>> Here are some updates:
>>
>> I was able to reproduce the panic by rsyncing big files and trying
>> bonnie++ test suggested in this thread.
>>
>> Can you guys retry with this patch:
>>
>> http://people.freebsd.org/~pjd/patches/vm_kern.c.2.patch
>>
>
> So, I have a question...
> What happens if the "for (i = 0..)" is changed to "while(1)" and
> the "panic" is subsequently removed?
>
>
> It appears like the code changes the meaning of "WAIT" to "wait
> for 4 seconds" then panic if it won't work. Previously, "WAIT" was
> not waiting at all...whch could be described as a bug!
>
> If I recall correctly, ZFS caches writes and doe them in spurts and
> that those spurts are spaced out more than 4 seconds. (For the
> curious, do "zpool status" and observe the gap in time between
> write activity.)
>
> If you start a large amount of I/O, it is possible that all the KVA will
> be used up and ZFS will not get a chance to flush its buffers before
> the 4s timer here expires. Does that sound plausible?
>
> Would doubling the 8 to (say) 16 be beneficial here, to at least make
> the waiting span one ZFS flush out to disk?
>
> Darren
"devil's Advocate" hat on here ...
But 4 *seconds* is an entire ice-age in machine cycle terms, so..
A) I hope you are wrong about that part [1]...
;-)
B) But if not...
Would it not make [ equal | better | optional ] sense to look into shortening
that time period?
By a factor of ten comes to my mind. At least.
Grant - that may mean a performance hit, hence I'd vote for 'optional' - but it
should also greatly reduce, not only the likelihood of using up the alloted RAM,
but of losing (quite as much of) the contents of those buffers if/as/when
disaster strikes.
- As it too often does, in one form or another.
JM2CW
Bill Hacker
[1] 4 seconds 'regardless' makes more sense. i.e. flush 'em periodically just
in case, even if no *known* alterations have been detected, ELSE more often
depending on [ many factors ].
>
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
More information about the freebsd-current
mailing list