Date: Fri, 17 Dec 1999 09:32:04 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Cc: vallo@solaris.matti.ee, freebsd-current@FreeBSD.ORG Subject: Re: Weird story with dump | restore Message-ID: <199912171732.JAA63489@apollo.backplane.com> References: <199912171648.IAA29595@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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
<dillon@backplane.com>
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?199912171732.JAA63489>