From owner-freebsd-geom@FreeBSD.ORG Thu Jun 28 01:35:31 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A7EE106564A for ; Thu, 28 Jun 2012 01:35:31 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 0A4C88FC16 for ; Thu, 28 Jun 2012 01:35:30 +0000 (UTC) Received: (qmail 3285 invoked by uid 0); 28 Jun 2012 01:35:24 -0000 Received: from 67.206.183.61 by rms-us006.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Wed, 27 Jun 2012 21:35:20 -0400 From: "Dieter BSD" Message-ID: <20120628013522.298400@gmx.com> MIME-Version: 1.0 To: To: freebsd-hackers@freebsd.org,freebsd-geom@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: jdGZb/QV3zOlNR3dAHAhI35+IGRvb4DV Cc: Subject: Re: Freeze when running freebsd-update X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 01:35:31 -0000 >>>> 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?