Date: Wed, 27 Jun 2012 21:35:20 -0400 From: "Dieter BSD" <dieterbsd@engineer.com> To: To: freebsd-hackers@freebsd.org,freebsd-geom@freebsd.org Subject: Re: Freeze when running freebsd-update Message-ID: <20120628013522.298400@gmx.com>
next in thread | raw e-mail | index | archive | help
>>>> Robert writes: >>>>> 3) the box is responsive to hitting enter at the console (it produces >>>>> another login: prompt) >>>> >>>> Getty is in memory and can run. >>>> >>>>> 5) if I try to login to the console, it lets me enter a username then >>>>> locks up totally, it does not present me with a password: prompt. >>>> >>>> Login(1) is not in memory, and the kernel cannot read it from disk >>>> for some reason. >>>> >>>> I can get this symptom by writing a large file to a disk on a >>>> controller that FreeBSD doesn't support NCQ on. I assume there >>>> is a logjam in the buffer cache. Something trivial like reading >>>> login in from disk that would normally happen in well under a >>>> second can take many minutes. >>>> >>>> Perhaps geli is causing a similar logjam? Does it hang forever or >>>> is it just obscenely slow? If it truely hangs forever it is >>>> probably something else. Is there disk activity after it hangs? >>>> Can you try it without geli? systat -vmstat might provide a clue. >>> >>> Well, it is geli. I'm unable to reproduce the freeze on the same >>> exact system with everything else the same except for no geli. I'm >>> going to move this thread over to geom, and continue it there. Thanks >>> for your help! >> >> It occurs to me that it will need twice as much memory for disk i/o. >> 1 buffer for encrypted and 1 for unencrypted. I know nothing about geli, >> so I don't know if it uses the buffer cache for both, or what. >> Could it be that the kernel isn't keeping enough memory free and >> manages to paint itself into a corner and not have space to store >> the unencrypted version of disk reads, and can't page/swap anything >> out to make space because it doesn't have space to store the encrypted >> version to write? > > I think that's probably about what is happening. I'm still waiting > for an answer on the geom mailing list, but I will do some testing > with increasing memory sizes and see where the problem stops > occurring. Some of the vfs.*buf sysctls might be useful?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120628013522.298400>