Date: Mon, 25 Oct 1999 11:02:48 -0600 From: Greg Lehey <grog@lemis.com> To: Dennis Glatting <dennis.glatting@software-munitions.com>, freebsd-current@freebsd.org Subject: Re: Strangeness with vinum Message-ID: <19991025110248.57032@mojave.worldwide.lemis.com> In-Reply-To: <Pine.BSF.4.10.9910240838520.4574-100000@btw.plaintalk.bellevue.wa.us>; from Dennis Glatting on Sun, Oct 24, 1999 at 08:53:28AM -0700 References: <Pine.BSF.4.10.9910240838520.4574-100000@btw.plaintalk.bellevue.wa.us>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, 24 October 1999 at 8:53:28 -0700, Dennis Glatting wrote: > > I just want to document some strangeness I see with vinum, in case it > has been noticed before but not identified, or someone knows a cure. You should read vinum(4). It tells you what kind of information I need for resolving problems. It also tells you to send the message to me personally so that I don't miss them. > I have a Dell XPS D333 with two Adaptec 2940 Ultra SCSI adapters, one > assigned to fast things and the other to slow things, generally. On > the slow adapter I have two SEAGATE ST43400N disks I placed under > vinum. Below is my config file. > > drive a device /dev/da3e > drive b device /dev/da4e > volume vol1 > plex org striped 16k This is too small. Choose 257 kB unless you have a good reason not to. But it has nothing to do with your problem. > sd length 2777m drive a > sd length 2777m drive b > > When I run "iozone -aR" against the volume the entire disks subsystem > seems to take a pause from time to time when the file sizes get large > (>= 32 MB). You don't really want to run iozone. Use rawio instead. But of course you shouldn't get this behaviour. > By this I mean the pause encompasses both disk controllers. > Specifically, if I enter a command in a window, such as "ls," > against a disk on the fast controller and my cwd is on that > controller too, then there is a big delay before the disk is listed, > on the order of 5-10 seconds. My PATH variable does not include any > devices on the slow controller. The window system still runs fine as > does the network. We seem to have buffer management problems in the kernel. I suspect what you're seeing here is some kind of yo-yo effect where the system uses up all its buffers and doesn't recover until a large number have been flushed. I've added some additional checks to -CURRENT, but they're not in -STABLE yet. > FreeBSD 3.3-STABLE #23: Sat Sep 25 08:27:04 PDT 1999 This isn't really a question for -CURRENT then, is it? But since you're here, try the same tests with -CURRENT and see if it happens there too. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991025110248.57032>