Date: Fri, 18 Apr 2003 14:23:30 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Marko Zec <zec@tel.fer.hr> Cc: freebsd-stable@freebsd.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <3EA06CD2.E299D864@mindspring.com> References: <200304162310.aa96829@salmon.maths.tcd.ie> <200304180245.53107.zec@tel.fer.hr> <3E9F4FE4.9B8567DC@mindspring.com> <200304182307.53890.zec@tel.fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
Marko Zec wrote: > On Friday 18 April 2003 03:07, Terry Lambert wrote: > > No, you are missing my previous point: the check for free space > > should include a check for number of elements *TOTAL* in all slots > > on the soft updates timer wheel. Otherwise it can eat all of > > memory. > > > > The free space check only works in the case that you've done a > > delete and are allocating new space: the case where you are doing > > more and more allocations/opverwrites of data is not handled, and > > can grow to eat all available kernel memory. There was in fact a > > bug, early on, that Matt Dillon worked around that caused it under > > load, and it was in exactly the code you are touching. > > If what you are saying were true, than one could simply crash an _unpached_ > system by doing a lot of FS write operations. No. See the checkin comments for "rushjob". > What my patch does is that it > just temporarily suspends the softupdates "wheels" as you call it. However, > if VM or another ffs subsytem indicates (by increasing the value of rushjob) > that buffers should get flushed more frequently, than my patch will > _immediately_ drop out of the delay loop and allow the syncing to proceed > ASAP. I really do not see what can be wrong with such a concept? No. See last posting: the wheel can not be allowed to "wrap". -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EA06CD2.E299D864>