Re: ZFS kmem_map too small.

From: 韓家標 Bill Hacker <askbill_at_conducive.net>
Date: Tue, 09 Oct 2007 16:13:28 -0400
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"
Received on Tue Oct 09 2007 - 18:13:30 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:19 UTC