Date: Thu, 30 Dec 1999 19:17:19 -0800 (PST) From: Tom <tom@uniserve.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Peter Wemm <peter@netplex.com.au>, freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates and debug.max_softdeps Message-ID: <Pine.BSF.4.02A.9912301820230.9644-100000@shell.uniserve.ca> In-Reply-To: <199912310141.RAA78648@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 Dec 1999, Matthew Dillon wrote: > : That is interesting. So I guess the conclusion to this is, softupdates > :is useful for bursty IO, but not sustained because it can get far behind > :until it eventually reaches the point where the machine reboots silently. > :I guess the delay until reboot is dependent on the size of max_softdeps. > :If it is big, it takes a while. > : > : I still think that the default value of max_softdeps might be too big > :for the kernel memory space. > > Well it sure isn't supposed to reboot silently! No panic message at > all? No printf? Well, a panic/printf should be recorded in the dmesg buffer, but I don't see anything. I'm using a serial terminal now, and I'm repeating my 4 x postmark test. > Hopefully Kirk is around to help track down the problem but if not I'll > take a crack at it after newyears if you create a PR for it and assign > it to me. I also don't think "sync" is a fix either. I expect "sync" to reclaim unused space. For instance, the file system currently shows 9 GB in use with "df", but there is only about 5 GB actually present on the disk. I ran "sync", and I expected "df" to report about 5GB used, but it doesn't seem to change anything. I'm going to try sync again tommorrow once the unreclaimed space is about 30GB or so, and see if it does anything. The only fix seems to be to halt IO before the mystery limit is hit, and let softupdates catch up on unreclaimed space. My 4 x postmark test completely maxes out the IO capacity of the system (ex. an ls of any empty directory taks 5 seconds). One thing that is interesting is that the following sysctl variables are always zero: debug.blk_limit_push: 0 debug.ino_limit_push: 0 debug.blk_limit_hit: 0 debug.ino_limit_hit: 0 debug.rush_requests: 0 So it doesn't look like softupdates is rushing things out. "vmstat -m" is showing that the storage for "inodedep" is steadily increasing. I _think_ I need to increase tick_delay, so when the max_softdeps limit is finally hit, syncer gets run for a while and clean things up. > -Matt Tom Uniserve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.02A.9912301820230.9644-100000>