Re: Weird story with dump | restore
On Fri, Dec 17, 1999 at 09:32:04AM -0800, Matthew Dillon [EMAIL PROTECTED] wrote: sysctl -a | fgrep dirty sysctl -w vfs.lodirtybuffers=X sysctl -w vfs.hidirtybuffers=Y Matt, I've tried your patch to sys/kern/vfs_bio.c, made no difference. Lowering the vfs.hidirtybuffers from 221 to 110 helps as before. The vfs.lodirtybuffers sysctl is gone for some reason. dmesg: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Sun Dec 19 09:45:03 EET 1999 root@tiiu:/usr/src/sys/compile/Tiiu Timecounter "i8254" frequency 1193199 Hz Timecounter "TSC" frequency 380232525 Hz CPU: AMD-K6(tm) 3D processor (380.23-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX AMD Features=0x8800SYSCALL,3DNow! real memory = 31391744 (30656K bytes) avail memory = 27590656 (26944K bytes) Preloaded elf kernel "kernel" at 0xc02cd000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc02cd09c. VESA: v2.0, 2048k memory, flags:0x4, mode table:0xc02815c2 (122) VESA: SiS devclass_alloc_unit: pcib0 already exists, using next available unit number npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 ata-pci0: SiS 5591 ATA controller irq 0 at device 0.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 isab0: SiS 85c503 PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 pci0: unknown card (vendor=0x1039, dev=0x0009) at 1.1 pcib2: PCI to PCI bridge (vendor=1039 device=0001) at device 2.0 on pci0 pci1: PCI bus on pcib2 vga-pci0: SiS model 6306 VGA-compatible display device at device 0.0 on pci1 fxp0: Intel EtherExpress Pro 10/100B Ethernet irq 11 at device 9.0 on pci0 fxp0: Ethernet address 00:a0:c9:97:90:65 pcm0: AudioPCI ES1371 irq 10 at device 11.0 on pci0 devclass_alloc_unit: pci1 already exists, using next available unit number pcib1: SiS 5591 host to AGP bridge on motherboard pci2: PCI bus on pcib1 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 8 virtual consoles, flags=0x200 fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 unknown0: PNP0c01 at iomem 0-0x9,0xe-0xf on isa0 unknown: PNP can't assign resources unknown1: PNP0200 at port 0-0xf,0x80-0x90,0x94-0x9f,0xc0-0xde drq 4 on isa0 unknown2: PNP0100 at port 0x40-0x43 irq 0 on isa0 unknown3: PNP0b00 at port 0x70-0x71 irq 8 on isa0 unknown: PNP0303 can't assign resources unknown: PNP0800 can't assign resources unknown4: PNP0c04 at port 0xf0-0xff irq 13 on isa0 unknown5: PNP0a03 on isa0 unknown: PNP0501 can't assign resources unknown: PNP0400 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0c02 can't assign resources ad0: IBM-DPTA-353750/P51OA30A ATA-4 disk at ata0 as master ad0: 35772MB (73261440 sectors), 72680 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 32 depth queue, UDMA33 ad1: ST36530A/841273 ATA-3 disk at ata1 as master ad1: 6208MB (12715920 sectors), 13456 cyls, 15 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 1 depth queue, UDMA33 acd0: NEC CD-ROM DRIVE:283/3.04 CDROM drive at ata1 as slave acd0: read 1376KB/s (1376KB/s), 128KB buffer, PIO acd0: Reads: CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked Mounting root from ufs:/dev/ad0a -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird story with dump | restore
:On Fri, Dec 17, 1999 at 09:32:04AM -0800, Matthew Dillon :[EMAIL PROTECTED] wrote: : : sysctl -a | fgrep dirty : sysctl -w vfs.lodirtybuffers=X : sysctl -w vfs.hidirtybuffers=Y : :Matt, I've tried your patch to sys/kern/vfs_bio.c, made no difference. :Lowering the vfs.hidirtybuffers from 221 to 110 helps as before. The :vfs.lodirtybuffers sysctl is gone for some reason. Oh my. Maybe we have two problems here. Alfred had similar problems and the patch fixed it right up. Try running a 'top -S -s1' while you are running your test, with my patch but without doing the sysctl's, and tell me what the various programs block on when the problem occurs (buf_daemon and whatever program is causing the hicup). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Weird story with dump | restore
Hello ! Something is weird with standard dump/restore procedure which I've always used to relocate my filesystems. I'm using 4.0-19991208-CURRENT on two machines, one is my home machine with SiS 5591 ATA controller and the other one has Intel PIIX. Home machine has disk pair Seagate 6.4GB and IBM 37.5GB, the other one Quantum Fireball 1GB and Fujitsu 3.2GB. First pair is in standard WDMA2 mode, the other one in PIO as per ata driver boot messages. Both setups have disks on separate channels, disks are masters. Problem: I'm trying to use dump/restore pair piped together to relocate / and /usr filesystems to the secondary master disk. In the first case from Seagate to IBM and second case from Quantum to Fujitsu. Target disks have innocent filesystems just created. On the home machine with SiS controller the overall dump/restore process runs smoothly until phase IV when it will do regular file dumping. Now the process stops regularly for about 10 seconds, then runs for 4 seconds or so. The process just runs, stops, runs, stops and so forth. Intervals aren't always same, but the stopped period is always longer. I dropped to in-kernel debugger and used ps to view process states. The dump wmesg column showed pipdwt and sbwait, for restore it's nbufkv. There's five lines for dump overall, the not mentioned were in wait or pause state. After viewing ps in debugger I continued the usual run and launced top. Everything stops while the restore process enters into nbuf?? state, top can't refresh screen etc, but everything continues after stopped period so I can see the restore process state changing. For the record, at last I used pax to relocate the data on the /usr filesystem and pax showed exactly same behavior. Difference was in reversed stop/run sequence, runs lasted lot longer than stopped states, pax even run for ten minutes, then stopped for about 13 seconds. The wd driver has same behavior, kernel with wd driver has same configuration as ata one. This claim is only true for SiS 5591 case as I've not tried yet with other machine. For other machine everything is same except machine stops completely. I've tried to disable softupdates on both source and target filesystems but no difference. All procedures were done in single user mode. It's very annoying, I have only fair experiences with dump/restore back to the 2.2.2 days until now. machine i386 ident Vokk maxusers32 makeoptions CONF_CFLAGS=-fno-builtin #Don't allow use of memcmp, etc. makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options PQ_NORMALCACHE # color for 256k/16k cache cpu I586_CPU# aka Pentium Pro(tm) options COMPAT_43 options SYSVSHM options SYSVSEM options SYSVMSG options MD5 options DDB options DDB_UNATTENDED options INET#Internet communications protocols pseudo-device ether #Generic Ethernet pseudo-device loop#Network loopback device pseudo-device bpf #Berkeley packet filter options ICMP_BANDLIM options FFS #Fast filesystem options NFS #Network File System options CD9660 #ISO 9660 filesystem options PROCFS #Process filesystem options FFS_ROOT#FFS usable as root device options SOFTUPDATES options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L pseudo-device pty #Pseudo ttys pseudo-device vn #Vnode driver (turns a file into a device) pseudo-device snp 3 #Snoop device - to look at pty/vty/etc.. options MSGBUF_SIZE=40960 controller isa0 controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device vga0at isa? port ? conflicts pseudo-device splash device sc0 at isa? options MAXCONS=8 # number of virtual consoles options SC_HISTORY_SIZE=800 # number of history buffer lines device npx0at nexus? port IO_NPX flags 0x0 irq 13 controller ata0 device atadisk0# ATA disk drives device atapicd0# ATAPI CDROM drives options ATA_ENABLE_ATAPI_DMA controller fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device sio0at isa? port IO_COM1 flags 0x10 irq 4 device sio1at isa? port IO_COM2 irq 3 controller miibus0 controller pci0 device vr0 controller ppbus0 device lpt0at ppbus? device plip0 at ppbus? device ppi0at ppbus? device ppc0at isa? port? irq 7 options CLK_CALIBRATION_LOOP options CLK_USE_I8254_CALIBRATION options CLK_USE_TSC_CALIBRATION --
Re: Weird story with dump | restore
On Fri, Dec 17, 1999 at 10:47:59AM +0200, Vallo Kallaste [EMAIL PROTECTED] wrote: [snip] It's very annoying, I have only fair experiences with dump/restore back to the 2.2.2 days until now. Sorry for the long post and partially? false alert. Something in my mind waked up and I checked what type of bsize and fsize the other machines have. Now I remember a little discussion in the cvs-all list, at that time phk committed something about default flags for newfs or so and there was rgrimes involved into discussion. He was 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? -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird story with dump | restore
On Fri, Dec 17, 1999 at 10:47:59AM +0200, Vallo Kallaste [EMAIL PROTECTED] wrote: [snip] It's very annoying, I have only fair experiences with dump/restore back to the 2.2.2 days until now. Sorry for the long post and partially? false alert. Something in my mind waked up and I checked what type of bsize and fsize the other machines have. Now I remember a little discussion in the cvs-all list, at that time phk committed something about default flags for newfs or so and there was rgrimes involved into discussion. He was 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) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird story with dump | restore
: 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) [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird story with dump | restore
:The source filesystems were both standard with bsize 8192 and fsize
:1024. Target filesystems were nonstandard.
:
:I umounted the source filesystem, in the exact case /usr (/dev/ad0s1e),
:then mounted target filesystem to /mnt, cd to /mnt and
:
:dump -0a -f - /dev/ad0s1e | restore rf -
:--
:
:Vallo Kallaste
:[EMAIL PROTECTED]
Try this patch to -current, it should solve the problem. I've been
meaning to fixup the buf_daemon for a while. This solves the
buf_daemon problem. We still will not be entirely optimal due to kvm
reshuffling but that's a different problem.
-Matt
Index: vfs_bio.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.237
diff -u -r1.237 vfs_bio.c
--- vfs_bio.c 1999/12/01 02:09:29 1.237
+++ vfs_bio.c 1999/12/17 18:44:40
@@ -88,7 +88,7 @@
bufmallocspace, maxbufmallocspace, hibufspace;
static int maxbdrun;
static int needsbuffer;
-static int numdirtybuffers, lodirtybuffers, hidirtybuffers;
+static int numdirtybuffers, hidirtybuffers;
static int numfreebuffers, lofreebuffers, hifreebuffers;
static int getnewbufcalls;
static int getnewbufrestarts;
@@ -96,8 +96,6 @@
SYSCTL_INT(_vfs, OID_AUTO, numdirtybuffers, CTLFLAG_RD,
numdirtybuffers, 0, "");
-SYSCTL_INT(_vfs, OID_AUTO, lodirtybuffers, CTLFLAG_RW,
- lodirtybuffers, 0, "");
SYSCTL_INT(_vfs, OID_AUTO, hidirtybuffers, CTLFLAG_RW,
hidirtybuffers, 0, "");
SYSCTL_INT(_vfs, OID_AUTO, numfreebuffers, CTLFLAG_RD,
@@ -275,6 +273,16 @@
}
}
+/*
+ * bd_speedup - speedup the buffer cache flushing code
+ */
+
+static __inline__
+void
+bd_speedup(void)
+{
+ bd_wakeup(1);
+}
/*
* Initialize buffer headers and related structures.
@@ -353,7 +361,6 @@
* Reduce the chance of a deadlock occuring by limiting the number
* of delayed-write dirty buffers we allow to stack up.
*/
- lodirtybuffers = nbuf / 7 + 10;
hidirtybuffers = nbuf / 4 + 20;
numdirtybuffers = 0;
/*
@@ -365,14 +372,9 @@
* the buffer cache.
*/
while (hidirtybuffers * BKVASIZE 3 * hibufspace / 4) {
- lodirtybuffers = 1;
hidirtybuffers = 1;
buf_maxio = 1;
}
- if (lodirtybuffers 2) {
- lodirtybuffers = 2;
- hidirtybuffers = 4;
- }
/*
* Temporary, BKVASIZE may be manipulated soon, make sure we don't
@@ -799,9 +801,9 @@
void
bwillwrite(void)
{
- int twenty = (hidirtybuffers - lodirtybuffers) / 5;
+ int slop = hidirtybuffers / 10;
- if (numdirtybuffers hidirtybuffers + twenty) {
+ if (numdirtybuffers hidirtybuffers + slop) {
int s;
s = splbio();
@@ -1571,9 +1573,8 @@
flags = VFS_BIO_NEED_ANY;
}
- /* XXX */
+ bd_speedup(); /* hlp */
- (void) speedup_syncer();
needsbuffer |= flags;
while (needsbuffer flags) {
if (tsleep(needsbuffer, (PRIBIO + 4) | slpflag,
@@ -1652,6 +1653,7 @@
static struct proc *bufdaemonproc;
static int bd_interval;
static int bd_flushto;
+static int bd_flushinc;
static struct kproc_desc buf_kp = {
"bufdaemon",
@@ -1672,6 +1674,7 @@
bd_interval = 5 * hz; /* dynamically adjusted */
bd_flushto = hidirtybuffers;/* dynamically adjusted */
+ bd_flushinc = 1;
while (TRUE) {
bd_request = 0;
@@ -1694,44 +1697,38 @@
}
}
- /*
-* If nobody is requesting anything we sleep
-*/
- if (bd_request == 0)
- tsleep(bd_request, PVM, "psleep", bd_interval);
+ if (bd_request ||
+ tsleep(bd_request, PVM, "psleep", bd_interval) == 0) {
+ /*
+* Another request is pending or we were woken up
+* without timing out. Flush more.
+*/
+ --bd_flushto;
+ if (bd_flushto = numdirtybuffers - 5) {
+ bd_flushto = numdirtybuffers - 10;
+ bd_flushinc = 1;
+ }
+ if (bd_flushto 2)
+ bd_flushto = 2;
+ } else {
+ /*
+* We slept and timed out, we can slow down.
+*/
+ bd_flushto += bd_flushinc;
+ if (bd_flushto hidirtybuffers)
+ bd_flushto = hidirtybuffers;
+ ++bd_flushinc;
+ if (bd_flushinc hidirtybuffers / 20 + 1)
+
Re: Weird story with dump | restore
On Fri, Dec 17, 1999 at 11:18:18AM -0800, Matthew Dillon [EMAIL PROTECTED] wrote: Try this patch to -current, it should solve the problem. I've been meaning to fixup the buf_daemon for a while. This solves the buf_daemon problem. We still will not be entirely optimal due to kvm reshuffling but that's a different problem. Thank you for your clear explanation and patch, I will try it out. Your previous suggestion to lower the dirtybuffers marks was successful. The initial values were 222 for hi and 125 for lowmark. Lowering them by half let the restore run as usual. Now I'm running off from an IBM 35GB disk :-) that's because my response was abit delayed. Thanks -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
