From owner-freebsd-current Fri Dec 17 9:32: 9 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C9FBE15703 for ; Fri, 17 Dec 1999 09:32:07 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA63489; Fri, 17 Dec 1999 09:32:04 -0800 (PST) (envelope-from dillon) Date: Fri, 17 Dec 1999 09:32:04 -0800 (PST) From: Matthew Dillon Message-Id: <199912171732.JAA63489@apollo.backplane.com> To: "Rodney W. Grimes" Cc: vallo@solaris.matti.ee, freebsd-current@FreeBSD.ORG Subject: Re: Weird story with dump | restore References: <199912171648.IAA29595@gndrsh.dnsmgr.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> suggesting following flags for filesystem creation for newer, bigger :> disks: :> :> newfs -b16384 -f2048 -u2048 -c128 -i4096 :> :> I've used them since with no problems whatsoever. Now I got the dump :> done on the machine with default filesystem, the bugger is unusual :> filesystem I guess. Is it expected behavior? Does anybody know why it :> can't be done? : :A few more details please. Are you having problems when you are :dumping from a file system formatted as above, or is it a restore :going to this type of file system, or are both the source and destination :file system formatted as above? : :EXACTLY what dump/restore pipeline command did you run? : :I'll try to duplicate this here... I suspect a blocking/unblocking :operation is highly un optimized to deal with these large block size :file systems and/or your exasting a kernel resource during this :operation. : :-- :Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net Hmm. With a block size of 16384 and restore getting stuck in 'nbufkv', it sounds like a problem with the buffer cache. The buffer cache can get into this state if there are too many dirty buffers eating up available KVM. Try changing the vfs.lodirtybuffers and vfs.hidirtybuffers sysctl variables. Try halving the values for both and tell me if that solves the problem. sysctl -a | fgrep dirty sysctl -w vfs.lodirtybuffers=X sysctl -w vfs.hidirtybuffers=Y Where X and Y are appropriate numbers. The delay you are seeing is due to the fact that getnewbuf() no longer synchronously flushes buffers out. I'll look into fixing the code to better handle this situation. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message