slow zvol performance compared to files on the same pool
I was experimenting with iscsi earlier, using both a flat file as the backing store and also a zvol. I noticed that the zvol was giving me dreadful performance - reading at about 20 meg/second and writing at about 12. the fklat file gives about 45 meg/second both ways. i thouht it was to do wuth the iscsi layer, but I then tried it using dd on the machinbe itself and got the same results. it seems very curious - I am creating both the filesystem for the iscsi file and the zvol on the same pool, so the underlying discs (4 x 15k SCSI drives on U320) are the same in both places, as is the pool. anybody got any opinions ? this is on 7.1-RC2, but I have nothing else to compare it to. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Panic in RELENG_7_1 with fxp(4)
After running 7-PRERELEASE from around November 25th, I upgraded today
to find the system panics repeatably on RELENG_7_1 sources. I can boot
back to the old kernel and it operates as expected. It seems to be
related to fxp(4).
FreeBSD didy.internal 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Sat Jan 3
18:11:18 CST 2009 bwe...@didy.internal:/usr/obj/usr/src/sys/DIDY i386
(19:00:35 bwe...@didy ) 507 $ sudo kgdb
kernel.debug /var/crash/vmcore.2
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x40c
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0a94510
stack pointer = 0x28:0xe677b878
frame pointer = 0x28:0xe677b88c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 843 (ntpd)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 25s
Physical memory: 995 MB
Dumping 94 MB: 79 63 47 31 15
Reading symbols from /boot/kernel/vesa.ko...Reading symbols from
/boot/kernel/vesa.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/vesa.ko
Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from
/boot/kernel/accf_http.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/accf_http.ko
Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
/boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from
/boot/kernel/pflog.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pflog.ko
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/boot/kernel/pf.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pf.ko
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
/boot/kernel/nullfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/nullfs.ko
Reading symbols from /boot/kernel/logo_saver.ko...Reading symbols from
/boot/kernel/logo_saver.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/logo_saver.ko
#0 doadump () at pcpu.h:196
196 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) list *0xc0a94510
0xc0a94510 is in _bus_dmamap_sync
(/usr/src/sys/i386/i386/busdma_machdep.c:935).
930 CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x op 0x%x "
931 "performing bounce", __func__, op, dmat,
dmat->flags);
932
933 if (op & BUS_DMASYNC_PREWRITE) {
934 while (bpage != NULL) {
935 bcopy((void *)bpage->datavaddr,
936 (void *)bpage->vaddr,
937 bpage->datacount);
938 bpage = STAILQ_NEXT(bpage, links);
939 }
(kgdb) bt
#0 doadump () at pcpu.h:196
#1 0xc079c1b7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2 0xc079c489 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3 0xc0ab03bc in trap_fatal (frame=0xe677b838, eva=1036) at
/usr/src/sys/i386/i386/trap.c:939
#4 0xc0ab0640 in trap_pfault (frame=0xe677b838, usermode=0, eva=1036)
at /usr/src/sys/i386/i386/trap.c:852
#5 0xc0ab0ffc in trap (frame=0xe677b838) at
/usr/src/sys/i386/i386/trap.c:530
#6 0xc0a96e6b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7 0xc0a94510 in _bus_dmamap_sync (dmat=0xc4048880, map=0xc416e800,
op=4) at /usr/src/sys/i386/i386/busdma_machdep.c:933
#8 0xc05cc3cd in fxp_start_body (ifp=0xc4163000) at
/usr/src/sys/dev/fxp/if_fxp.c:1396
#9 0xc05ccc77 in fxp_start (ifp=0xc4163000) at
/usr/src/sys/dev/fxp/if_fxp.c:1183
#10 0xc0830a89 in if_start (ifp=0xc4163000) at /usr/src/sys/net/if.c:2768
#11 0xc08374cb in ether_output_frame (ifp=0xc4163000, m=0xc43a5600) at
/usr/src/sys/net/if_ethersubr.c:405
#12 0xc0837a7c in ether_output (ifp=0xc4163000, m=0xc43a5600,
dst=0xc423b710, rt0=0xc4489364) at /usr/src/sys/net/if_ethersubr.c:374
#13 0xc087e115 in ip_output (m=0xc43a5600, opt=0x0, ro=0xe677bac4,
flags=Variable "flags" is not available.
) at /usr/src/sys/netinet/ip_output.c:554
#14 0xc08eb9b9 in udp_send (so=0xc46ef9c0, flags=0, m=0xc43a5600,
addr=0xc4462ab0, control=0x0, td=0xc421f230) at
/usr/src/sys/netinet/udp_usrreq.c:1074
#15 0xc07f2546 in sosend_dgram (so=0xc46ef9c0, addr=0xc4462ab0,
uio=0xe677bbe8, top=0
Re: slow zvol performance compared to files on the same pool
Pete French wrote: I was experimenting with iscsi earlier, using both a flat file as the backing store and also a zvol. I noticed that the zvol was giving me dreadful performance - reading at about 20 meg/second and writing at about 12. the fklat file gives about 45 meg/second both ways. i thouht it was to do wuth the iscsi layer, but I then tried it using dd on the machinbe itself and got the same results. it seems very curious - I am creating both the filesystem for the iscsi file and the zvol on the same pool, so the underlying discs (4 x 15k SCSI drives on U320) are the same in both places, as is the pool. anybody got any opinions ? this is on 7.1-RC2, but I have nothing else to compare it to. On 7.x (where ZFS is really quite broken for server use - don't waste too much time on it) the ZVOL code did an "fsync" after every single block write. Its a testament to your fast disks that you got as high as 12mb/s. I don't know why your read speed was so bad, but you should try again on 8-current as numerous fixes and improvements have happened. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: rdump stuck in sbwait state (RELENG_7)
> Sorry, I can't think of any - by the time you see it hung, whatever
> went wrong has already happened. You might glean some insight from
> the TCP socket state (on the FreeBSD side, use 'netstat -A' to print
> the PCB address and gdb to dump the contents but I'm not sure how to
> get this data out of OpenVMS). The '-C' and '-W' options to tcpdump
> will help.
Ok, I found some time to reproduce this while capturing a trace with
tcpdump.
Here's the relevant output from netstat / kgdb:
(0:31) test4:~terry# netstat -A
Active Internet connections
TcpcbProto Recv-Q Send-Q Local Address Foreign Address(state)
c73eeae0 tcp4 0 0 test4.892 server.shell ESTABLISHED
[snip]
(0:32) test4:~terry# kgdb
GNU gdb 6.1.1 [FreeBSD]
[snip]
#0 0x in ?? ()
(kgdb) print * (struct tcpcb *) 0xc73eeae0
$1 = {t_segq = {lh_first = 0x0}, t_segqlen = 0, t_dupacks = 0,
t_timers = 0xc73eec24, t_inpcb = 0xc7387708, t_state = 4, t_flags = 484,
snd_una = 292841209, snd_max = 292841209, snd_nxt = 292841209,
snd_up = 292780017, snd_wl1 = 3606352422, snd_wl2 = 292841209,
iss = 3955646224, irs = 3606284909, rcv_nxt = 3606352422,
rcv_adv = 3606415910, rcv_wnd = 63488, rcv_up = 3606352422, snd_wnd = 65535,
snd_cwnd = 65535, snd_bwnd = 1073725440, snd_ssthresh = 1073725440,
snd_bandwidth = 0, snd_recover = 3955646224, t_maxopd = 1460,
t_rcvtime = 11273919, t_starttime = 11024967, t_rtttime = 0,
t_rtseq = 292839154, t_bw_rtttime = 11024966, t_bw_rtseq = 3955646224,
t_rxtcur = 230, t_maxseg = 1448, t_srtt = 145, t_rttvar = 34,
t_rxtshift = 0, t_rttmin = 30, t_rttbest = 67, t_rttupdated = 232101,
max_sndwnd = 65535, t_softerror = 0, t_oobflags = 0 '\0', t_iobc = 0 '\0',
snd_scale = 0 '\0', rcv_scale = 3 '\003', request_r_scale = 3 '\003',
ts_recent = 1207233, ts_recent_age = 11273919, ts_offset = 0,
last_ack_sent = 3606352422, snd_cwnd_prev = 0, snd_ssthresh_prev = 0,
snd_recover_prev = 0, t_badrxtwin = 0, snd_limited = 0 '\0',
snd_numholes = 0, snd_holes = {tqh_first = 0x0, tqh_last = 0xc73eebb8},
snd_fack = 0, rcv_numsacks = 0, sackblks = {{start = 0, end = 0}, {
start = 0, end = 0}, {start = 0, end = 0}, {start = 0, end = 0}, {
start = 0, end = 0}, {start = 0, end = 0}}, sack_newdata = 0,
sackhint = {nexthole = 0x0, sack_bytes_rexmit = 0}, t_rttlow = 1,
rfbuf_ts = 0, rfbuf_cnt = 0, t_pspare = {0x0, 0x0, 0x0}, t_tu = 0x0,
t_toe = 0x0}
(kgdb) q
Rather than pasting the decoded tcpdump output here, the raw capture
file is at http://www.tmk.com/transient/rdump30.gz (it is only 76KB
compressed, 270KB uncompressed). It looks to me like the remote host
(the VMS box) has correctly ack'd all outstanding data from the FreeBSD
host, but that the FreeBSD host is just sitting there for some reason.
As before, I have this sitting in the wedged state so if anyone needs
more data, I can either collect it or give you access to the system.
Terry Kennedy http://www.tmk.com
te...@tmk.com New York, NY USA
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: slow zvol performance compared to files on the same pool
Andrew Snow wrote: On 7.x (where ZFS is really quite broken for server use - don't waste too much time on it) How exactly is it broken? I know there are some issues, but so serious you'd say it's broken? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic in RELENG_7_1 with fxp(4)
On Jan 3, 2009, at 5:17 PM, Brandon Weisz wrote:
After running 7-PRERELEASE from around November 25th, I upgraded
today to find the system panics repeatably on RELENG_7_1 sources. I
can boot back to the old kernel and it operates as expected. It
seems to be related to fxp(4).
FreeBSD didy.internal 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Sat Jan 3
18:11:18 CST 2009 bwe...@didy.internal:/usr/obj/usr/src/sys/
DIDY i386
(19:00:35 bwe...@didy ) 507 $ sudo kgdb
kernel.debug /var/crash/vmcore.2
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-marcel-freebsd"...
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x40c
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0a94510
stack pointer = 0x28:0xe677b878
frame pointer = 0x28:0xe677b88c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 843 (ntpd)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 25s
Physical memory: 995 MB
Dumping 94 MB: 79 63 47 31 15
Reading symbols from /boot/kernel/vesa.ko...Reading symbols from /
boot/kernel/vesa.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/vesa.ko
Reading symbols from /boot/kernel/accf_http.ko...Reading symbols
from /boot/kernel/accf_http.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/accf_http.ko
Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /
boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from /
boot/kernel/pflog.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pflog.ko
Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/
kernel/pf.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pf.ko
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /
boot/kernel/nullfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/nullfs.ko
Reading symbols from /boot/kernel/logo_saver.ko...Reading symbols
from /boot/kernel/logo_saver.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/logo_saver.ko
#0 doadump () at pcpu.h:196
196 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) list *0xc0a94510
0xc0a94510 is in _bus_dmamap_sync (/usr/src/sys/i386/i386/
busdma_machdep.c:935).
930 CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x op 0x%x "
931 "performing bounce", __func__, op, dmat,
dmat->flags);
932
933 if (op & BUS_DMASYNC_PREWRITE) {
934 while (bpage != NULL) {
935 bcopy((void *)bpage->datavaddr,
936 (void *)bpage->vaddr,
937 bpage->datacount);
938 bpage = STAILQ_NEXT(bpage, links);
939 }
(kgdb) bt
#0 doadump () at pcpu.h:196
#1 0xc079c1b7 in boot (howto=260) at /usr/src/sys/kern/
kern_shutdown.c:418
#2 0xc079c489 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3 0xc0ab03bc in trap_fatal (frame=0xe677b838, eva=1036) at /usr/
src/sys/i386/i386/trap.c:939
#4 0xc0ab0640 in trap_pfault (frame=0xe677b838, usermode=0,
eva=1036) at /usr/src/sys/i386/i386/trap.c:852
#5 0xc0ab0ffc in trap (frame=0xe677b838) at /usr/src/sys/i386/i386/
trap.c:530
#6 0xc0a96e6b in calltrap () at /usr/src/sys/i386/i386/exception.s:
159
#7 0xc0a94510 in _bus_dmamap_sync (dmat=0xc4048880, map=0xc416e800,
op=4) at /usr/src/sys/i386/i386/busdma_machdep.c:933
#8 0xc05cc3cd in fxp_start_body (ifp=0xc4163000) at /usr/src/sys/
dev/fxp/if_fxp.c:1396
#9 0xc05ccc77 in fxp_start (ifp=0xc4163000) at /usr/src/sys/dev/fxp/
if_fxp.c:1183
#10 0xc0830a89 in if_start (ifp=0xc4163000) at /usr/src/sys/net/if.c:
2768
#11 0xc08374cb in ether_output_frame (ifp=0xc4163000, m=0xc43a5600)
at /usr/src/sys/net/if_ethersubr.c:405
#12 0xc0837a7c in ether_output (ifp=0xc4163000, m=0xc43a5600,
dst=0xc423b710, rt0=0xc4489364) at /usr/src/sys/net/if_ethersubr.c:374
#13 0xc087e115 in ip_output (m=0xc43a5600, opt=0x0, ro=0xe677bac4,
flags=Variable "flags" is not available.
) at /usr/src/sys/netinet/ip_output.c:554
#14 0xc08eb9b9 in udp_send (so=0xc46ef9c0, flags=0, m=0xc43a5600,
addr=0xc4462ab0, control=0x0, td=0xc421f230) at /usr/src/sys/netinet/
udp_usrreq.c:107
