Re: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd problem?)

[Alexander V. Chernikov]

Harald Schmalzbauer wrote:

Mikolaj Golub schrieb am 22.01.2010 23:26 (localtime):

On Wed, 20 Jan 2010 08:06:23 +0100 Harald Schmalzbauer wrote:


Dear all,

I have no idea why top crashes with segmentation fault on my amd64
machine running FreeBSD 8.0-RELEASE-p2.
If someone wants to have a loot at the core dump:
http://www.schmalzbauer.de/downloads/top.core


core file is useless without binary and libraries. So it is better to 
run gdb

on your host, produce backtrace and post here:

gdb /usr/bin/top top.core
bt

And sure a backtrace from the top built with -g would be much better.

cd /usr/src/usr.bin/top
CFLAGS=-g make


Unfortunately nss_ldap seems to be the culprit.

There is some strange problem with TLS and gcc optimization I can't localize

Please try to rebuild port with

post-configure:
   @${REINPLACE_CMD} -e 's/^\(CFLAGS .*\)-O2 \(.*\)$$/\1 -O0 \2/' 
${WRKSRC}/nss/Makefile


I'll submit updated port later


gdb /usr/bin/top top.core
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 "amd64-marcel-freebsd"...
Core was generated by `top'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libncurses.so.8...done.
Loaded symbols for /lib/libncurses.so.8
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libkvm.so.5...done.
Loaded symbols for /lib/libkvm.so.5
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/local/lib/nss_ldap.so.1...done.
Loaded symbols for /usr/local/lib/nss_ldap.so.1
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
bt:
#0  0x000800d08403 in __nss_compat_gethostbyname () from 
/usr/local/lib/nss_ldap.so.1
#0  0x000800d08403 in __nss_compat_gethostbyname () from 
/usr/local/lib/nss_ldap.so.1
#1  0x000800d0606f in _nss_ldap_getpwent_r () from 
/usr/local/lib/nss_ldap.so.1

#2  0x0008009ffc54 in __nss_compat_getpwent_r () from /lib/libc.so.7
#3  0x000800a84a3d in nsdispatch () from /lib/libc.so.7
#4  0x000800a50976 in getpwent_r () from /lib/libc.so.7
#5  0x000800a50596 in sysctlbyname () from /lib/libc.so.7
#6  0x00406c6d in machine_init (statics=0x7fffea30, 
do_unames=1 '\001')

at /usr/src/usr.bin/top/machine.c:257
#7  0x00407a10 in main (argc=1, argv=0x7fffeb08)
at /usr/src/usr.bin/top/../../contrib/top/top.c:458

I'm using nss_ldapd-0.7.2 and there's no way to live without ldap...

Any help highly appreciated!

Thanks,

-Harry



___
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"

Problem with alias length in base Sendmail

[Spil Oss]

Hi All,

Today I ran into the BUG documented in the aliases man-page.

   If you have compiled sendmail with DBM support instead  of  NEWDB,  you
   may  have  encountered problems in dbm(3) restricting a single alias to
   about 1000 bytes  of  information.   

Looking at Sendmail, it is compiled with NEWDB so the restriction
would not apply.

# sendmail -d0.1 -bv root
Version 8.14.3
 Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7
NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SCANF
STARTTLS TCPWRAPPERS USERDB XDEBUG

If my alias (including whitespace) exceeds ca. 1000 characters,
running `make aliases` will report an error.
   /etc/mail/aliases: line 320: alias too long
Resulting in an aliases.db file without the too long alias
   550 5.1.1 ... User unknown
Which means to me that the alias is simply skipped and the rest of the
aliases database is installed.

There is a workaround documented with the bug in the man-page, but I'd
very much like to understand why this is failing.

FreeBSD gw.example.org 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #2: Thu
Jun 11 12:58:02 CEST 2009
r...@gw.example.org:/usr/obj/usr/src/sys/MYKERNEL  i386

Kind regards,

Spil
___
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: make buildkernel failing on zfs - fixed but now everything is slow

[Colin]

Colin wrote:

Thanks for the reply.
I must admit that the ins and outs of paging and interrupts are 
something I don't have much expertise in. I've asked the colo company 
to look into it but I've put the output of those commands into 
pastebin incase anything stands out.

http://www.pastebin.org/81107



I suspect this is an none issue now as everything is OK. My best guess 
is that the RAID array was rebuilding itself as there were a few mpt cam 
events logged overnight and the problem seems to have gone away after that.


Now I'm left with one problem which is a bit different so I'll start it 
on its own topic

Cheers for the help folks.
___
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: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd problem?)

[Harald Schmalzbauer]

Alexander V. Chernikov schrieb am 24.01.2010 10:24 (localtime):
...

gdb /usr/bin/top top.core
bt

And sure a backtrace from the top built with -g would be much better.

cd /usr/src/usr.bin/top
CFLAGS=-g make


Unfortunately nss_ldap seems to be the culprit.
There is some strange problem with TLS and gcc optimization I can't 
localize


Please try to rebuild port with

post-configure:
   @${REINPLACE_CMD} -e 's/^\(CFLAGS .*\)-O2 \(.*\)$$/\1 -O0 \2/' 
${WRKSRC}/nss/Makefile


I'll submit updated port later


That indeed fixed the problem. Thank you very much.
But I found another point for improovement:
When deinstalling/installing nss_ldap.conf gets deleted/overwritten. I 
think it's better to install nss_ldap.conf.sample like many other ports do.

I also like the way lighttpd port is managed:
@unexec if cmp -s %D/etc/lighttpd.conf %D/etc/lighttpd.conf.sample; then 
rm -f %D/etc/lighttpd.conf; fi

etc/lighttpd.conf.sample
@exec [ -f %B/lighttpd.conf ] || cp %B/%f %B/lighttpd.conf

Thanks,

-Harry



signature.asc
Description: OpenPGP digital signature

Re: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd problem?)

[Alexander V. Chernikov]

Harald Schmalzbauer wrote:

Alexander V. Chernikov schrieb am 24.01.2010 10:24 (localtime):
...

gdb /usr/bin/top top.core
bt

And sure a backtrace from the top built with -g would be much better.

cd /usr/src/usr.bin/top
CFLAGS=-g make


Unfortunately nss_ldap seems to be the culprit.
There is some strange problem with TLS and gcc optimization I can't 
localize


Please try to rebuild port with

post-configure:
   @${REINPLACE_CMD} -e 's/^\(CFLAGS .*\)-O2 \(.*\)$$/\1 -O0 \2/' 
${WRKSRC}/nss/Makefile


I'll submit updated port later


That indeed fixed the problem. Thank you very much.
But I found another point for improovement:
When deinstalling/installing nss_ldap.conf gets deleted/overwritten. I 
think it's better to install nss_ldap.conf.sample like many other 
ports do.

I also like the way lighttpd port is managed:
@unexec if cmp -s %D/etc/lighttpd.conf %D/etc/lighttpd.conf.sample; 
then rm -f %D/etc/lighttpd.conf; fi

etc/lighttpd.conf.sample
@exec [ -f %B/lighttpd.conf ] || cp %B/%f %B/lighttpd.conf

Thanks,

-Harry


Already noticed that, thanks.
___
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: ZFS performance degradation over time

[Miroslav Lachman]

Garrett Moore wrote:

I've been watching my memory usage and I have no idea what is consuming
memory as 'Active'.

Last night I had around 6500MB 'Active' again, 1500MB Wired, no inact, ~30MB
buf, no free, and ~100MB swap used. My performance copying ZFS->ZFS was
again slow (<1MB/s). I tried killing rTorrent and no significant amount of
memory was reclaimed - maybe 100MB. `ps aux` showed no processes using any
significant amount of memory, and I was definitely nowhere near 6500MB
usage.

I tried running the perl oneliner again to hog a bunch of memory, and almost
all of the Active memory was IMMEDIATELY marked as Free, and my performance
was excellent again.

I'm not sure what in userland could be causing the issue. The only things
I've installed are rTorrent, lighttpd, samba, smartmontools, vim, bash,
Python, Perl, and SABNZBd. There is nothing that *should* be consuming any
serious amount of memory.


Last night I tried ZFS with pool on iSCSI connected Dell MD3000i and I 
was suprised by too low speed of simple cp -a command (copying from UFS 
partition to ZFS) The write speed was about 2MB/s only.


After looking in to ARC stuff, I realized some weird values:

ARC Size:
 Current Size: 1 MB (arcsize)
 Target Size (Adaptive):   205 MB (c)
 Min Size (Hard Limit):205 MB (zfs_arc_min)
 Max Size (Hard Limit):1647 MB (zfs_arc_max)

(stats from script http://cuddletech.com/arc_summary/
freebsd version 
http://bitbucket.org/koie/arc_summary/changeset/dbe14d2cf52b/ )


I don't know why it shows Current Size 1MB.

I tried the perl oneliner from this thread. Then I got about 5GB free 
merory and Target Size and Current Size growed to 1647MB. Write speed 
increase to about 8MB/s and after few minuts slowly dropped to 2MB/s and 
ARC Current Size dropped to 1MB again.


This server is not in production and was idle. Just copying the data 
from one partition to another.


Today I tried serving the data by Lighttpd.
There is impressive iSCSI read performance - because of ZFS prefetch, it 
can achieve 880Mbits of read from iSCSI, but serving by Lighttpd only 
about 66Mbits


bce0 - internet
bce1 - iSCSI to storage MD3000i

  bce0bce1
 Kbps in  Kbps out   Kbps in  Kbps out
 2423.22  65481.56  855970.7   4348.73
 2355.26  63911.74  820561.3   4846.08
 2424.87  65998.62  848937.1   4312.37
 2442.78  66544.95  858019.0   4356.64


iostat -x
extended device statistics
device r/s   w/skr/skw/s wait svc_t  %b
da1  1596.8   3.6 102196.722.2   13   7.4  97
da1  1650.2   2.9 105612.755.7   16   7.4 103
da1  1647.3   0.0 105422.9 0.0   13   7.2 100
da1  1636.5   2.3 104735.420.0   16   7.3 100
da1  1642.9   0.0 105141.1 0.0   13   7.3 100


~/bin/arcstat.pl -f 
Time,read,hits,Hit%,miss,miss%,dmis,dm%,mmis,mm%,arcsz,c 30

Time  read  hits  Hit%  miss  miss%  dmis  dm%  mmis  mm%  arcsz c
12:18:05   16K   15K94   838  5   5703 10   16933296 
  215902720
12:18:36   16K   15K94   839  5   5713 00   21488288 
  215902720
12:19:06   16K   15K94   836  5   5693 10   17228688 
  215902720
12:19:37   16K   15K94   839  5   5723 41   22002672 
  215902720
12:20:07   16K   15K94   841  5   5703 10   27784960 
  215902720
12:20:38   16K   15K94   838  5   5693 00   21839472 
  215902720
12:21:08   16K   15K94   837  5   5683 00   28244992 
  215902720
12:21:39   16K   15K94   833  5   5653 10   28744416 
  215902720
12:22:09   16K   15K94   842  5   5763 41   28646656 
  215902720
12:22:39   16K   15K94   840  5   5753 30   28903696 
  215902720
12:23:10   15K   15K94   821  5   5613 00   28765904 
  215902720
12:23:40   16K   15K94   828  5   5663 00   28395840 
  215902720
12:24:11   16K   15K94   828  5   5683 00   32063408 
  215902720
12:24:41   16K   15K94   834  5   5703 00   29800976 
  215902720
12:25:12   15K   15K94   820  5   5623 10   29066512 
  215902720



# ~/bin/arc_summary.pl
System Memory:
 Physical RAM:  8169 MB
 Free Memory :  0 MB

ARC Size:
 Current Size: 22 MB (arcsize)
 Target Size (Adaptive):   205 MB (c)
 Min Size (Hard Limit):205 MB (zfs_arc_min)
 Max Size (Hard Limit):1647 MB (zfs_arc_max)

ARC Size Breakdown:
 Most Recently Used Cache Size:   5%11 MB (p)
 Most Frequently Used Cache Size:94%194 MB (c-p)

ARC Efficency:
 Cache Access Total: 81843958
 Cache Hit Ratio:  95%   78525502   [Defined State 
for buffer]
 Cache Miss Ratio:  4%   3318456[Undefined 
State for Buffer]

 REAL Hit Ratio:

Re: ZFS performance degradation over time

[Miroslav Lachman]

Miroslav Lachman wrote:

[...]


Last night I tried ZFS with pool on iSCSI connected Dell MD3000i and I
was suprised by too low speed of simple cp -a command (copying from UFS
partition to ZFS) The write speed was about 2MB/s only.

After looking in to ARC stuff, I realized some weird values:

ARC Size:
Current Size: 1 MB (arcsize)
Target Size (Adaptive): 205 MB (c)
Min Size (Hard Limit): 205 MB (zfs_arc_min)
Max Size (Hard Limit): 1647 MB (zfs_arc_max)

(stats from script http://cuddletech.com/arc_summary/
freebsd version
http://bitbucket.org/koie/arc_summary/changeset/dbe14d2cf52b/ )

I don't know why it shows Current Size 1MB.


[...]


Today I tried serving the data by Lighttpd.
There is impressive iSCSI read performance - because of ZFS prefetch, it
can achieve 880Mbits of read from iSCSI, but serving by Lighttpd only
about 66Mbits

bce0 - internet
bce1 - iSCSI to storage MD3000i

bce0 bce1
Kbps in Kbps out Kbps in Kbps out
2423.22 65481.56 855970.7 4348.73
2355.26 63911.74 820561.3 4846.08
2424.87 65998.62 848937.1 4312.37
2442.78 66544.95 858019.0 4356.64


[...]


ARC Size:
Current Size: 22 MB (arcsize)
Target Size (Adaptive): 205 MB (c)
Min Size (Hard Limit): 205 MB (zfs_arc_min)
Max Size (Hard Limit): 1647 MB (zfs_arc_max)

ARC Size Breakdown:
Most Recently Used Cache Size: 5% 11 MB (p)
Most Frequently Used Cache Size: 94% 194 MB (c-p)


[...]


Can somebody tell me, why ARC Current Size is dropping too low? (1-20MB
if arc_min is 205MB)

The system have 8GB of memory and 8 CPU cores:

last pid: 83605; load averages: 0.17, 0.15, 0.10 up 36+10:34:34 12:29:05
58 processes: 1 running, 56 sleeping, 1 zombie
CPU: 0.1% user, 0.0% nice, 2.3% system, 1.7% interrupt, 95.8% idle
Mem: 237M Active, 6259M Inact, 1154M Wired, 138M Cache, 827M Buf, 117M Free
Swap: 8192M Total, 96K Used, 8192M Free


Hmmm, it seems related to ZFS + Sendfile bug as was pointed in older thread:
Performance issues with 8.0 ZFS and sendfile/lighttpd
http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052595.html

http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052629.html

I tried the test with Lighttpd again, but with "writev" instead of 
sendfile in lighttpd.conf (server.network-backend = "writev") and with 
this settings it triple the performance!
Now Lighttpd is serving about 180Mbits instead of 66Mbits and ARC 
Current Size is constantly on its max size:


# ~/bin/arc_summary.pl
System Memory:
 Physical RAM:  8169 MB
 Free Memory :  0 MB

ARC Size:
 Current Size: 1647 MB (arcsize)
 Target Size (Adaptive):   1647 MB (c)
 Min Size (Hard Limit):205 MB (zfs_arc_min)
 Max Size (Hard Limit):1647 MB (zfs_arc_max)

ARC Size Breakdown:
 Most Recently Used Cache Size:  99%1643 MB (p)
 Most Frequently Used Cache Size: 0%3 MB (c-p)

ARC Efficency:
 Cache Access Total: 126994437
 Cache Hit Ratio:  94%   119500977  [Defined State 
for buffer]
 Cache Miss Ratio:  5%   7493460[Undefined 
State for Buffer]

 REAL Hit Ratio:   93%   118808103  [MRU/MFU Hits Only]

 Data Demand   Efficiency:97%
 Data Prefetch Efficiency:14%

CACHE HITS BY CACHE LIST:
  Anon:   --%Counter Rolled.
  Most Recently Used:  2%3552568 (mru) 
 [ Return Customer ]
  Most Frequently Used:   96%115255535 (mfu) 
 [ Frequent Customer ]
  Most Recently Used Ghost:1%1277990 (mru_ghost) 
 [ Return Customer Evicted, Now Back ]
  Most Frequently Used Ghost:  0%464787 (mfu_ghost) 
 [ Frequent Customer Evicted, Now Back ]

CACHE HITS BY DATA TYPE:
  Demand Data:96%114958883
  Prefetch Data:   0%713418
  Demand Metadata: 3%3828650
  Prefetch Metadata:   0%26
CACHE MISSES BY DATA TYPE:
  Demand Data:40%3017229
  Prefetch Data:  57%4324961
  Demand Metadata: 2%151246
  Prefetch Metadata:   0%24


# ~/bin/arcstat.pl -f 
Time,read,hits,Hit%,miss,miss%,dmis,dm%,mmis,mm%,arcsz,c 30

Time  read  hits  Hit%  miss  miss%  dmis  dm%  mmis  mm%  arcsz c
14:04:455K4K87   672 12531 20 
1727635056   1727221760
14:05:165K4K86   679 13481 10 
1727283200   1727221760
14:05:465K5K88   674 11551 10 
1727423184   1727221760
14:06:175K4K87   668 12511 00 
1727590560   1727221760
14:06:475K5K88   665 11561 10 
1727278896   1727221760
14:07:185K5K88   664 11531 10 
1727347632   1727221760


# # ifstat -i bce0,bce1

Re: Loader, MBR and the boot process

[Romain Garbage]

2010/1/22, Dan Naumov :

> Putting the swap into it's own slice and then putting FreeBSD into
> it's own slice worked fine. So why the hell can't they both coexist in
> 1 slice if the swap comes first?

Similar problem here: I have a full-zfs system in a bsd slice, but I
have the zfs-freebsd partition before the swap one. The problem is
that the system doesn't seem to detect the swap partition partition (I
see "swapon: /dev/ada0s1b: No such file or directory" during boot)

% bsdlabel /dev/ada0s1
# /dev/ada0s1:
8 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
  a: 530432000   ZFS
  b:  9883342 53043200  swap
  c: 629265420unused0 0 # "raw" part, don't edit

but to see ada0s1b in /dev/ I have to reload geom_bsd module (loading
it at boot time doesn't work).

Even though (but this seems to be another problem):
% sudo swapon /dev/ada0s1b
swapon: /dev/ada0s1b: Operation not permitted


Regards,
Romain
___
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: Loader, MBR and the boot process

[John]

On Fri, Jan 22, 2010 at 07:02:53AM +0200, Dan Naumov wrote:
> On Fri, Jan 22, 2010 at 6:49 AM, Dan Naumov  wrote:
> > On Fri, Jan 22, 2010 at 6:12 AM, Thomas K.  wrote:
> >> On Fri, Jan 22, 2010 at 05:57:23AM +0200, Dan Naumov wrote:
> >>
> >> Hi,
> >>
> >>> I recently found a nifty "FreeBSD ZFS root installation script" and
> >>> been reworking it a bit to suit my needs better, including changing it
> >>> from GPT to MBR partitioning. However, I was stumped, even though I
> >>> had done everything right (or so I thought), the system would get
> >>> stuck at Loader and refuse to go anywhere. After trying over a dozen
> >>
> >> probably this line is the cause:
> >>
> >> dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s1a skip=1 seek=1024
> >>
> >> Unless by "swap first" you meant the on-disk location, and not the
> >> partition letter. If swap is partition "a", you're writing the loader
> >> into swapspace.
> >>
> >>
> >> Regards,
> >> Thomas
> >
> > At first you made me feel silly, but then I decided to double-check, I
> > uncommented the swap line in the partitioning part again, ensured I
> > was writing the bootloader to "${TARGETDISK}"s1b and ran the script.
> > Same problem, hangs at loader. Again, if I comment out the swap,
> > giving the entire slice to ZFS and then write the bootloader to
> > "${TARGETDISK}"s1a, run the script, everything works.
> 
> I have also just tested creating 2 slices, like this:
> 
> gpart create -s mbr "${TARGETDISK}"
> gpart add -s 3G -t freebsd "${TARGETDISK}"
> gpart create -s BSD "${TARGETDISK}"s1
> gpart add -t freebsd-swap "${TARGETDISK}"s1
> 
> gpart add -t freebsd "${TARGETDISK}"
> gpart create -s BSD "${TARGETDISK}"s2
> gpart add -t freebsd-zfs "${TARGETDISK}"s2
> 
> gpart set -a active -i 2 "${TARGETDISK}"
> gpart bootcode -b /mnt2/boot/boot0 "${TARGETDISK}"
> 
> 
> and later:
> 
> dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s2 count=1
> dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s2a skip=1 seek=1024
> 
> 
> Putting the swap into it's own slice and then putting FreeBSD into
> it's own slice worked fine. So why the hell can't they both coexist in
> 1 slice if the swap comes first?

I know what the answer to this USED to be, but I don't know if it is
still true (obviously, I think so, I or wouldn't waste your time).

The filesystem code is all carefully written to avoid the very
first few sector of the partition.  That's because the partition
table is there for the first filesystem of the slice (or disk).
That's a tiny amout of space wasted, because it's also skipped on
all the other filesystems even though there's not actually anything
there, but it was a small inefficency, even in the 70's.

Swap does not behave that way.  SWAP will begin right at the slice
boundry, with 0 offset.  As long as it's not the first partition, no
harm, no foul.  If it IS the first partition, you just nuked your partition
table.  As long as SWAP owns the slice, again, no harm, no foul, but
if there were filesystems BEHIND it, you just lost 'em.

That's the way it always used to be, and I think it still is.  SWAP can
only be first if it is the ONLY thing using that slice (disk), otherwise,
you need a filesystem first to protect the partition table.
-- 

John Lind
j...@starfire.mn.org
___
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: Loader, MBR and the boot process

[Dan Naumov]

On Sun, Jan 24, 2010 at 5:29 PM, John  wrote:
> On Fri, Jan 22, 2010 at 07:02:53AM +0200, Dan Naumov wrote:
>> On Fri, Jan 22, 2010 at 6:49 AM, Dan Naumov  wrote:
>> > On Fri, Jan 22, 2010 at 6:12 AM, Thomas K.  wrote:
>> >> On Fri, Jan 22, 2010 at 05:57:23AM +0200, Dan Naumov wrote:
>> >>
>> >> Hi,
>> >>
>> >>> I recently found a nifty "FreeBSD ZFS root installation script" and
>> >>> been reworking it a bit to suit my needs better, including changing it
>> >>> from GPT to MBR partitioning. However, I was stumped, even though I
>> >>> had done everything right (or so I thought), the system would get
>> >>> stuck at Loader and refuse to go anywhere. After trying over a dozen
>> >>
>> >> probably this line is the cause:
>> >>
>> >> dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s1a skip=1 seek=1024
>> >>
>> >> Unless by "swap first" you meant the on-disk location, and not the
>> >> partition letter. If swap is partition "a", you're writing the loader
>> >> into swapspace.
>> >>
>> >>
>> >> Regards,
>> >> Thomas
>> >
>> > At first you made me feel silly, but then I decided to double-check, I
>> > uncommented the swap line in the partitioning part again, ensured I
>> > was writing the bootloader to "${TARGETDISK}"s1b and ran the script.
>> > Same problem, hangs at loader. Again, if I comment out the swap,
>> > giving the entire slice to ZFS and then write the bootloader to
>> > "${TARGETDISK}"s1a, run the script, everything works.
>>
>> I have also just tested creating 2 slices, like this:
>>
>> gpart create -s mbr "${TARGETDISK}"
>> gpart add -s 3G -t freebsd "${TARGETDISK}"
>> gpart create -s BSD "${TARGETDISK}"s1
>> gpart add -t freebsd-swap "${TARGETDISK}"s1
>>
>> gpart add -t freebsd "${TARGETDISK}"
>> gpart create -s BSD "${TARGETDISK}"s2
>> gpart add -t freebsd-zfs "${TARGETDISK}"s2
>>
>> gpart set -a active -i 2 "${TARGETDISK}"
>> gpart bootcode -b /mnt2/boot/boot0 "${TARGETDISK}"
>>
>>
>> and later:
>>
>> dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s2 count=1
>> dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s2a skip=1 seek=1024
>>
>>
>> Putting the swap into it's own slice and then putting FreeBSD into
>> it's own slice worked fine. So why the hell can't they both coexist in
>> 1 slice if the swap comes first?
>
> I know what the answer to this USED to be, but I don't know if it is
> still true (obviously, I think so, I or wouldn't waste your time).
>
> The filesystem code is all carefully written to avoid the very
> first few sector of the partition.  That's because the partition
> table is there for the first filesystem of the slice (or disk).
> That's a tiny amout of space wasted, because it's also skipped on
> all the other filesystems even though there's not actually anything
> there, but it was a small inefficency, even in the 70's.
>
> Swap does not behave that way.  SWAP will begin right at the slice
> boundry, with 0 offset.  As long as it's not the first partition, no
> harm, no foul.  If it IS the first partition, you just nuked your partition
> table.  As long as SWAP owns the slice, again, no harm, no foul, but
> if there were filesystems BEHIND it, you just lost 'em.
>
> That's the way it always used to be, and I think it still is.  SWAP can
> only be first if it is the ONLY thing using that slice (disk), otherwise,
> you need a filesystem first to protect the partition table.
> --
>
> John Lind
> j...@starfire.mn.org

This explanation does sound logical, but holy crap, if this is the
case, you'd think there would be bells, whistles and huge red label
warnings in EVERY FreeBSD installation / partitioning guide out there
warning people to not put swap first (unless given a dedicated slice)
under any circumstances. The warnings were nowhere to be seen and lots
of pointy hair first greyed and were then lost during the process of
me trying to figure out why my system would install but wouldn't boot.

- Sincerely,
Dan Naumov
___
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"

8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance

[Dan Naumov]

Note: Since my issue is slow performance right off the bat and not
performance degradation over time, I decided to start a separate
discussion. After installing a fresh pure ZFS 8.0 system and building
all my ports, I decided to do some benchmarking. At this point, about
a dozen of ports has been built installed and the system has been up
for about 11 hours, No heavy background services have been running,
only SSHD and NTPD:

==
bonnie -s 8192:

  ---Sequential Output ---Sequential Input-- --Random--
  -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
 8192 23821 61.7 22311 19.2 13928 13.7 25029 49.6 44806 17.2 135.0  3.1

During the process, TOP looks like this:

last pid: 83554;  load averages:  0.31,  0.31,  0.37  up 0+10:59:01  17:24:19
33 processes:  2 running, 31 sleeping
CPU:  0.1% user,  0.0% nice, 14.1% system,  0.7% interrupt, 85.2% idle
Mem: 45M Active, 4188K Inact, 568M Wired, 144K Cache, 1345M Free
Swap: 3072M Total, 3072M Free

Oh wow, that looks low, alright, lets run it again, just to be sure:

  ---Sequential Output ---Sequential Input-- --Random--
  -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
 8192 18235 46.7 23137 19.9 13927 13.6 24818 49.3 44919 17.3 134.3  2.1

OK, let's reboot the machine and see what kind of numbers we get on a
fresh boot:

===

  ---Sequential Output ---Sequential Input-- --Random--
  -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
 8192 21041 53.5 22644 19.4 13724 12.8 25321 48.5 43110 14.0 143.2  3.3

Nope, no help from the reboot, still very low speed. Here is my pool:

===

zpool status
  pool: tank
 state: ONLINE
 scrub: none requested
config:

NAME STATE READ WRITE CKSUM
tank ONLINE   0 0 0
  mirror ONLINE   0 0 0
ad10s1a  ONLINE   0 0 0
ad8s1a   ONLINE   0 0 0

===

diskinfo -c -t /dev/ad10
/dev/ad10
512 # sectorsize
2000398934016   # mediasize in bytes (1.8T)
3907029168  # mediasize in sectors
3876021 # Cylinders according to firmware.
16  # Heads according to firmware.
63  # Sectors according to firmware.
WD-WCAVY0301430 # Disk ident.

I/O command overhead:
time to read 10MB block  0.164315 sec   =0.008 msec/sector
time to read 20480 sectors   3.030396 sec   =0.148 msec/sector
calculated command overhead =0.140 msec/sector

Seek times:
Full stroke:  250 iter in   7.309334 sec =   29.237 msec
Half stroke:  250 iter in   5.156117 sec =   20.624 msec
Quarter stroke:   500 iter in   8.147588 sec =   16.295 msec
Short forward:400 iter in   2.544309 sec =6.361 msec
Short backward:   400 iter in   2.007679 sec =5.019 msec
Seq outer:   2048 iter in   0.392994 sec =0.192 msec
Seq inner:   2048 iter in   0.332582 sec =0.162 msec
Transfer rates:
outside:   102400 kbytes in   1.576734 sec =64944 kbytes/sec
middle:102400 kbytes in   1.381803 sec =74106 kbytes/sec
inside:102400 kbytes in   2.145432 sec =47729 kbytes/sec

===

diskinfo -c -t /dev/ad8
/dev/ad8
512 # sectorsize
2000398934016   # mediasize in bytes (1.8T)
3907029168  # mediasize in sectors
3876021 # Cylinders according to firmware.
16  # Heads according to firmware.
63  # Sectors according to firmware.
WD-WCAVY1611513 # Disk ident.

I/O command overhead:
time to read 10MB block  0.176820 sec   =0.009 msec/sector
time to read 20480 sectors   2.966564 sec   =0.145 msec/sector
calculated command overhead =0.136 msec/sector

Seek times:
Full stroke:  250 iter in   7.993339 sec =   31.973 msec
Half stroke:  250 iter in   5.944923 sec =   23.780 msec
Quarter stroke:   500 iter in   9.744406 sec =   19.489 msec
Short forward:400 iter in   2.511171 sec =6.2

PCIe audio cards: what is tob be preferred with FreeBSD 8.0/9-CURRENT?

[O. Hartmann]

Well,
At this very moment I utilise a M-Audio 5.1 PCI-audio board with which 
I'm really satisfied. My next box doesn't have PCI slots at all (ASUS 
P6T6-WS Revolution) and due to the fact I'm using Windows 7 sometimes 
for recreational gaming, I'd like to have a moderate expensive audio 
board with the workstation which is supported by FreeBSD 8/9. In the 
past - means two or three ywars ago, I had problems with Soundblaster 
PCIe boards, so I was recommended avoiding those and choosing the more 
elabotrated M-Audio cards for the PCI bus.
At this moment, I look for the Soundblaster X-Fi range of PCIe cards, 
but I'm not sure whether they are supported by FreeBSd 8/9. Any suggestions?


Regards,
Oliver
___
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: Pack of CAM improvements

[Alexander Motin]

Gary Jennejohn wrote:
> I started seeing a problem a few days ago with one of my DVD drives (a
> burner at cd0) under 9-current, which makes it impossible to use it even
> to simply read a DVD.
> 
> Here the (rather strange IMO) output in dmesg:
> 
> cd0:  Removable CD-ROM SCSI-0 device
> cd0: 66.700MB/s transfers (UDMA4, PIO size 65534bytes)
> cd0: Attempt to query device size failed: UNIT ATTENTION, Power on, reset,
> or bus device reset occurred
> cd1 at ata0 bus 0 scbus6 target 1 lun 0
> cd1:  Removable CD-ROM SCSI-0 device
> cd1: 33.300MB/s transfers (UDMA2, PIO size 65534bytes)
> cd1: Attempt to query device size failed: NOT READY, Medium not present -
> tray closed
> 
> I haven't the foggiest why cd0 behaves diffrently from cd1, which is a
> vanilla DVD drive and just works.

I am not sure yet what triggered these changes. May be just some timing
issue. That UNIT ATTENTION seems reasonable, as reset indeed just
happened there. The real problem is that CAM had several limitations in
SCSI status handling, when working with ATAPI or USB devices. It made
request processing stop in some cases, where retries would be expected.

New patch version should handle this and some other problems:
http://people.freebsd.org/~mav/cam-ata.20100124.patch

Try it please. Thanks.

-- 
Alexander Motin
___
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: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance

[Dan Naumov]

On Sun, Jan 24, 2010 at 7:05 PM, Jason Edwards  wrote:
> Hi Dan,
>
> I read on FreeBSD mailinglist you had some performance issues with ZFS.
> Perhaps i can help you with that.
>
> You seem to be running a single mirror, which means you won't have any speed
> benefit regarding writes, and usually RAID1 implementations offer little to
> no acceleration to read requests also; some even just read from the master
> disk and don't touch the 'slave' mirrored disk unless when writing. ZFS is
> alot more modern however, although i did not test performance of its mirror
> implementation.
>
> But, benchmarking I/O can be tricky:
>
> 1) you use bonnie, but bonnie's tests are performed without a 'cooldown'
> period between the tests; meaning that when test 2 starts, data from test 1
> is still being processed. For single disks and simple I/O this is not so
> bad, but for large write-back buffers and more complex I/O buffering, this
> may be inappropriate. I had patched bonnie some time in the past, but if you
> just want a MB/s number you can use DD for that.
>
> 2) The diskinfo tiny benchmark is single queue only i assume, meaning that
> it would not scale well or at all on RAID-arrays. Actual filesystems on
> RAID-arrays use multiple-queue; meaning it would not read one sector at a
> time, but read 8 blocks (of 16KiB) "ahead"; this is called read-ahead and
> for traditional UFS filesystems its controlled by the sysctl vfs.read_max
> variable. ZFS works differently though, but you still need a "real"
> benchmark.
>
> 3) You need low-latency hardware; in particular, no PCI controller should be
> used. Only PCI-express based controllers or chipset-integrated Serial ATA
> cotrollers have proper performance. PCI can hurt performance very badly, and
> has high interrupt CPU usage. Generally you should avoid PCI. PCI-express is
> fine though, its a completely different interface that is in many ways the
> opposite of what PCI was.
>
> 4) Testing actual realistic I/O performance (in IOps) is very difficult. But
> testing sequential performance should be alot easier. You may try using dd
> for this.
>
>
> For example, you can use dd on raw devices:
>
> dd if=/dev/ad4 of=/dev/null bs=1M count=1000
>
> I will explain each parameter:
>
> if=/dev/ad4 is the input file, the "read source"
>
> of=/dev/null is the output file, the "write destination". /dev/null means it
> just goes no-where; so this is a read-only benchmark
>
> bs=1M is the blocksize, howmuch data to transfer per time. default is 512 or
> the sector size; but that's very slow. A value between 64KiB and 1024KiB is
> appropriate. bs=1M will select 1MiB or 1024KiB.
>
> count=1000 means transfer 1000 pieces, and with bs=1M that means 1000 * 1MiB
> = 1000MiB.
>
>
>
> This example was raw reading sequentially from the start of the device
> /dev/ad4. If you want to test RAIDs, you need to work at the filesystem
> level. You can use dd for that too:
>
> dd if=/dev/zero of=/path/to/ZFS/mount/zerofile.000 bs=1M count=2000
>
> This command will read from /dev/zero (all zeroes) and write to a file on
> ZFS-mounted filesystem, it will create the file "zerofile.000" and write
> 2000MiB of zeroes to that file.
> So this command tests write-performance of the ZFS-mounted filesystem. To
> test read performance, you need to clear caches first by unmounting that
> filesystem and re-mounting it again. This would free up memory containing
> parts of the filesystem as cached (reported in top as "Inact(ive)" instead
> of "Free").
>
> Please do make sure you double-check a dd command before running it, and run
> as normal user instead of root. A wrong dd command may write to the wrong
> destination and do things you don't want. The only real thing you need to
> check is the write destination (of=). That's where dd is going to write
> to, so make sure its the target you intended. A common mistake made by
> myself was to write dd of=... if=... (starting with of instead of if) and
> thus actually doing something the other way around than what i was meant to
> do. This can be disastrous if you work with live data, so be careful! ;-)
>
> Hope any of this was helpful. During the dd benchmark, you can of course
> open a second SSH terminal and start "gstat" to see the devices current I/O
> stats.
>
> Kind regards,
> Jason

Hi and thanks for your tips, I appreciate it :)

[j...@atombsd ~]$ dd if=/dev/zero of=/home/jago/test1 bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 36.206372 secs (29656156 bytes/sec)

[j...@atombsd ~]$ dd if=/dev/zero of=/home/jago/test2 bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 143.878615 secs (29851325 bytes/sec)

This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and
4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the
bonnie results. It also sadly seems to confirm the very slow speed :(
The disks are attached to a 4-port Sil3124 controller and again, my
Wind

Re: Pack of CAM improvements

[Gary Jennejohn]

On Sun, 24 Jan 2010 18:48:15 +0200
Alexander Motin  wrote:

> Gary Jennejohn wrote:
> > I started seeing a problem a few days ago with one of my DVD drives (a
> > burner at cd0) under 9-current, which makes it impossible to use it even
> > to simply read a DVD.
> > 
> > Here the (rather strange IMO) output in dmesg:
> > 
> > cd0:  Removable CD-ROM SCSI-0 device
> > cd0: 66.700MB/s transfers (UDMA4, PIO size 65534bytes)
> > cd0: Attempt to query device size failed: UNIT ATTENTION, Power on, reset,
> > or bus device reset occurred
> > cd1 at ata0 bus 0 scbus6 target 1 lun 0
> > cd1:  Removable CD-ROM SCSI-0 device
> > cd1: 33.300MB/s transfers (UDMA2, PIO size 65534bytes)
> > cd1: Attempt to query device size failed: NOT READY, Medium not present -
> > tray closed
> > 
> > I haven't the foggiest why cd0 behaves diffrently from cd1, which is a
> > vanilla DVD drive and just works.
> 
> I am not sure yet what triggered these changes. May be just some timing
> issue. That UNIT ATTENTION seems reasonable, as reset indeed just
> happened there. The real problem is that CAM had several limitations in
> SCSI status handling, when working with ATAPI or USB devices. It made
> request processing stop in some cases, where retries would be expected.
> 
> New patch version should handle this and some other problems:
> http://people.freebsd.org/~mav/cam-ata.20100124.patch
> 
> Try it please. Thanks.
> 

This patch works extremely well!  Thanks.

---
Gary Jennejohn
___
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: Problem with alias length in base Sendmail

[jhell]

On Sun, 24 Jan 2010 04:50, spil.oss@ wrote:

Hi All,

Today I ran into the BUG documented in the aliases man-page.

  If you have compiled sendmail with DBM support instead  of  NEWDB,  you
  may  have  encountered problems in dbm(3) restricting a single alias to
  about 1000 bytes  of  information.   

Looking at Sendmail, it is compiled with NEWDB so the restriction
would not apply.

# sendmail -d0.1 -bv root
Version 8.14.3
Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7
   NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SCANF
   STARTTLS TCPWRAPPERS USERDB XDEBUG

If my alias (including whitespace) exceeds ca. 1000 characters,
running `make aliases` will report an error.
  /etc/mail/aliases: line 320: alias too long
Resulting in an aliases.db file without the too long alias
  550 5.1.1 ... User unknown
Which means to me that the alias is simply skipped and the rest of the
aliases database is installed.

There is a workaround documented with the bug in the man-page, but I'd
very much like to understand why this is failing.

FreeBSD gw.example.org 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #2: Thu
Jun 11 12:58:02 CEST 2009
r...@gw.example.org:/usr/obj/usr/src/sys/MYKERNEL  i386

Kind regards,

Spil



That's either one hell of a pipe or the owner of that email address can be 
proud that no-one will ever email him/her ;)


Can you post the alias in question ? Maybe there is another way that you 
could go about doing this if it is not just a test case trying to flaunt 
the adequate limits of sendmail.


--

 jhell

___
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: Problem with alias length in base Sendmail

[Spil Oss]

Hi jhell,

aliases can be used as mailing-lists (remember to also have a
-owner alias if you wish to use it that way)

And there is a work-around, also documented in the aliases man-page.
split it up in multiple parts that are lists again

mailinglist: mailinglist-part1, mailinglist-part2, mailinglist-part3

mailinglist-part1: recipie...@example.org, recipie...@example.net

mailinglist-part2: recepie...@example.net, recipie...@example.org

Still curious as to why the NEWDB in FreeBSD does not support more
than ca. 1000-bytes in an alias.

Kind regards,

Spil.

On Sun, Jan 24, 2010 at 7:03 PM, jhell  wrote:
>
> On Sun, 24 Jan 2010 04:50, spil.oss@ wrote:
>>
>> Hi All,
>>
>> Today I ran into the BUG documented in the aliases man-page.
>>
>>      If you have compiled sendmail with DBM support instead  of  NEWDB,
>>  you
>>      may  have  encountered problems in dbm(3) restricting a single alias
>> to
>>      about 1000 bytes  of  information.   
>>
>> Looking at Sendmail, it is compiled with NEWDB so the restriction
>> would not apply.
>>
>> # sendmail -d0.1 -bv root
>> Version 8.14.3
>> Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7
>>               NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING
>> SCANF
>>               STARTTLS TCPWRAPPERS USERDB XDEBUG
>>
>> If my alias (including whitespace) exceeds ca. 1000 characters,
>> running `make aliases` will report an error.
>>  /etc/mail/aliases: line 320: alias too long
>> Resulting in an aliases.db file without the too long alias
>>  550 5.1.1 ... User unknown
>> Which means to me that the alias is simply skipped and the rest of the
>> aliases database is installed.
>>
>> There is a workaround documented with the bug in the man-page, but I'd
>> very much like to understand why this is failing.
>>
>> FreeBSD gw.example.org 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #2: Thu
>> Jun 11 12:58:02 CEST 2009
>> r...@gw.example.org:/usr/obj/usr/src/sys/MYKERNEL  i386
>>
>> Kind regards,
>>
>> Spil
>>
>
> That's either one hell of a pipe or the owner of that email address can be
> proud that no-one will ever email him/her ;)
>
> Can you post the alias in question ? Maybe there is another way that you
> could go about doing this if it is not just a test case trying to flaunt the
> adequate limits of sendmail.
>
> --
>
>  jhell
>
>
___
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: sendmail replacement

[Svein Skogen (Listmail Account)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13.01.2010 11:52, S.N.Grigoriev wrote:
> Hi list,
> 
> I would like to know if there is a way to completely
> replace the base sendmail with a ports one. The goal
> is to have corresponding files on the traditional places
> (not in /usr/local) and to use the system sendmail
> startup script but not /usr/local/etc/rc.d/sendmail.sh.
> 

Every once in a while something along these lines pops up. The regular
answer seems to be something along the "make.conf" or "src.conf" files,
which will stop something from being compiled.

Maybe we need a third conf file along the lines of base_remove.conf were
we list the disabled stuff in src.conf, and the installworld make A)
removes the installed version, and B) then removes/sets false the
corresponding line in remove.conf (so versions installed from ports
aren't touched).

This would (potentially) solve the issue, but I'll be the first to admit
it has about the same charm as driving a nail with a wrecking ball, but
I'm sure some of the brighter minds can do something about it.

//Svein

- -- 
- +---+---
  /"\   |Svein Skogen   | sv...@d80.iso100.no
  \ /   |Solberg Østli 9| PGP Key:  0xE5E76831
   X|2020 Skedsmokorset | sv...@jernhuset.no
  / \   |Norway | PGP Key:  0xCE96CE13
|   | sv...@stillbilde.net
 ascii  |   | PGP Key:  0x58CD33B6
 ribbon |System Admin   | svein-listm...@stillbilde.net
Campaign|stillbilde.net | PGP Key:  0x22D494A4
+---+---
|msn messenger: | Mobile Phone: +47 907 03 575
|sv...@jernhuset.no | RIPE handle:SS16503-RIPE
- +---+---
 If you really are in a hurry, mail me at
   svein-mob...@stillbilde.net
 This mailbox goes directly to my cellphone and is checked
even when I'm not in front of my computer.
- 
 Picture Gallery:
  https://gallery.stillbilde.net/v/svein/
- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktcjXIACgkQODUnwSLUlKRT1ACfVYqGzYTkqinPBEvn/5AJA3Tg
n+wAn2vB8seXpV65l8TB1lvv7H6j7mOx
=KQ+9
-END PGP SIGNATURE-
___
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: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance

[Dan Naumov]

On Sun, Jan 24, 2010 at 7:42 PM, Dan Naumov  wrote:
> On Sun, Jan 24, 2010 at 7:05 PM, Jason Edwards  wrote:
>> Hi Dan,
>>
>> I read on FreeBSD mailinglist you had some performance issues with ZFS.
>> Perhaps i can help you with that.
>>
>> You seem to be running a single mirror, which means you won't have any speed
>> benefit regarding writes, and usually RAID1 implementations offer little to
>> no acceleration to read requests also; some even just read from the master
>> disk and don't touch the 'slave' mirrored disk unless when writing. ZFS is
>> alot more modern however, although i did not test performance of its mirror
>> implementation.
>>
>> But, benchmarking I/O can be tricky:
>>
>> 1) you use bonnie, but bonnie's tests are performed without a 'cooldown'
>> period between the tests; meaning that when test 2 starts, data from test 1
>> is still being processed. For single disks and simple I/O this is not so
>> bad, but for large write-back buffers and more complex I/O buffering, this
>> may be inappropriate. I had patched bonnie some time in the past, but if you
>> just want a MB/s number you can use DD for that.
>>
>> 2) The diskinfo tiny benchmark is single queue only i assume, meaning that
>> it would not scale well or at all on RAID-arrays. Actual filesystems on
>> RAID-arrays use multiple-queue; meaning it would not read one sector at a
>> time, but read 8 blocks (of 16KiB) "ahead"; this is called read-ahead and
>> for traditional UFS filesystems its controlled by the sysctl vfs.read_max
>> variable. ZFS works differently though, but you still need a "real"
>> benchmark.
>>
>> 3) You need low-latency hardware; in particular, no PCI controller should be
>> used. Only PCI-express based controllers or chipset-integrated Serial ATA
>> cotrollers have proper performance. PCI can hurt performance very badly, and
>> has high interrupt CPU usage. Generally you should avoid PCI. PCI-express is
>> fine though, its a completely different interface that is in many ways the
>> opposite of what PCI was.
>>
>> 4) Testing actual realistic I/O performance (in IOps) is very difficult. But
>> testing sequential performance should be alot easier. You may try using dd
>> for this.
>>
>>
>> For example, you can use dd on raw devices:
>>
>> dd if=/dev/ad4 of=/dev/null bs=1M count=1000
>>
>> I will explain each parameter:
>>
>> if=/dev/ad4 is the input file, the "read source"
>>
>> of=/dev/null is the output file, the "write destination". /dev/null means it
>> just goes no-where; so this is a read-only benchmark
>>
>> bs=1M is the blocksize, howmuch data to transfer per time. default is 512 or
>> the sector size; but that's very slow. A value between 64KiB and 1024KiB is
>> appropriate. bs=1M will select 1MiB or 1024KiB.
>>
>> count=1000 means transfer 1000 pieces, and with bs=1M that means 1000 * 1MiB
>> = 1000MiB.
>>
>>
>>
>> This example was raw reading sequentially from the start of the device
>> /dev/ad4. If you want to test RAIDs, you need to work at the filesystem
>> level. You can use dd for that too:
>>
>> dd if=/dev/zero of=/path/to/ZFS/mount/zerofile.000 bs=1M count=2000
>>
>> This command will read from /dev/zero (all zeroes) and write to a file on
>> ZFS-mounted filesystem, it will create the file "zerofile.000" and write
>> 2000MiB of zeroes to that file.
>> So this command tests write-performance of the ZFS-mounted filesystem. To
>> test read performance, you need to clear caches first by unmounting that
>> filesystem and re-mounting it again. This would free up memory containing
>> parts of the filesystem as cached (reported in top as "Inact(ive)" instead
>> of "Free").
>>
>> Please do make sure you double-check a dd command before running it, and run
>> as normal user instead of root. A wrong dd command may write to the wrong
>> destination and do things you don't want. The only real thing you need to
>> check is the write destination (of=). That's where dd is going to write
>> to, so make sure its the target you intended. A common mistake made by
>> myself was to write dd of=... if=... (starting with of instead of if) and
>> thus actually doing something the other way around than what i was meant to
>> do. This can be disastrous if you work with live data, so be careful! ;-)
>>
>> Hope any of this was helpful. During the dd benchmark, you can of course
>> open a second SSH terminal and start "gstat" to see the devices current I/O
>> stats.
>>
>> Kind regards,
>> Jason
>
> Hi and thanks for your tips, I appreciate it :)
>
> [j...@atombsd ~]$ dd if=/dev/zero of=/home/jago/test1 bs=1M count=1024
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes transferred in 36.206372 secs (29656156 bytes/sec)
>
> [j...@atombsd ~]$ dd if=/dev/zero of=/home/jago/test2 bs=1M count=4096
> 4096+0 records in
> 4096+0 records out
> 4294967296 bytes transferred in 143.878615 secs (29851325 bytes/sec)
>
> This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and
> 4GB in 143.8 seconds / 28,4mb/s and 

Re: Problem with alias length in base Sendmail

[Clifton Royston]

On Sun, Jan 24, 2010 at 01:03:33PM -0500, jhell wrote:
...
> That's either one hell of a pipe or the owner of that email address can be 
> proud that no-one will ever email him/her ;)

st...@example.com: p...@example.com, v...@example.com, employ...@example.com, \
  ...
sa...@example.com: j...@example.com, g...@example.com, \
  ...

  Used to be very common and still might be; it's the traditional
old-UNIX way to do organizational mail aliases/mailing lists.

  -- Clifton

-- 
Clifton Royston  --  clift...@iandicomputing.com / clift...@lava.net
   President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services
___
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: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance

[Dan Naumov]

On Sun, Jan 24, 2010 at 8:12 PM, Bob Friesenhahn
 wrote:
> On Sun, 24 Jan 2010, Dan Naumov wrote:
>>
>> This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and
>> 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the
>> bonnie results. It also sadly seems to confirm the very slow speed :(
>> The disks are attached to a 4-port Sil3124 controller and again, my
>> Windows benchmarks showing 65mb/s+ were done on exact same machine,
>> with same disks attached to the same controller. Only difference was
>> that in Windows the disks weren't in a mirror configuration but were
>> tested individually. I do understand that a mirror setup offers
>> roughly the same write speed as individual disk, while the read speed
>> usually varies from "equal to individual disk speed" to "nearly the
>> throughput of both disks combined" depending on the implementation,
>> but there is no obvious reason I am seeing why my setup offers both
>> read and write speeds roughly 1/3 to 1/2 of what the individual disks
>> are capable of. Dmesg shows:
>
> There is a mistatement in the above in that a "mirror setup offers roughly
> the same write speed as individual disk".  It is possible for a mirror setup
> to offer a similar write speed to an individual disk, but it is also quite
> possible to get 1/2 (or even 1/3) the speed. ZFS writes to a mirror pair
> requires two independent writes.  If these writes go down independent I/O
> paths, then there is hardly any overhead from the 2nd write.  If the writes
> go through a bandwidth-limited shared path then they will contend for that
> bandwidth and you will see much less write performance.
>
> As a simple test, you can temporarily remove the mirror device from the pool
> and see if the write performance dramatically improves. Before doing that,
> it is useful to see the output of 'iostat -x 30' while under heavy write
> load to see if one device shows a much higher svc_t value than the other.

Ow, ow, WHOA:

atombsd# zpool offline tank ad8s1a

[j...@atombsd ~]$ dd if=/dev/zero of=/home/jago/test3 bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 16.826016 secs (63814382 bytes/sec)

Offlining one half of the mirror bumps DD write speed from 28mb/s to
64mb/s! Let's see how Bonnie results change:

Mirror with both parts attached:

  ---Sequential Output ---Sequential Input-- --Random--
  -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
 8192 18235 46.7 23137 19.9 13927 13.6 24818 49.3 44919 17.3 134.3  2.1

Mirror with 1 half offline:

  ---Sequential Output ---Sequential Input-- --Random--
  -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
 1024 22888 58.0 41832 35.1 22764 22.0 26775 52.3 54233 18.3 166.0  1.6

Ok, the Bonnie results have improved, but only very little.

- Sincerely,
Dan Naumov
___
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: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance

[Dan Naumov]

On Sun, Jan 24, 2010 at 8:34 PM, Jason Edwards  wrote:
>> ZFS writes to a mirror pair
>> requires two independent writes.  If these writes go down independent I/O
>> paths, then there is hardly any overhead from the 2nd write.  If the
>> writes
>> go through a bandwidth-limited shared path then they will contend for that
>> bandwidth and you will see much less write performance.
>
> What he said may confirm my suspicion on PCI. So if you could try the same
> with "real" Serial ATA via chipset or PCI-e controller you can confirm this
> story. I would be very interested. :P
>
> Kind regards,
> Jason


This wouldn't explain why ZFS mirror on 2 disks directly, on the exact
same controller (with the OS running off a separate disks) results in
"expected" performance, while having the OS run off/on a ZFS mirror
running on top of MBR-partitioned disks, on the same controller,
results in very low speed.

- Dan
___
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"

Problematic network performance with Marvell 8072 on HP Probook 4710s

[Emanuele A. Bagnaschi]

Hi,
I've been experiencing a troubling issue with a Marvell 8072 NIC on an HP
ProBook 4710s. 
I first noticed that there is a problem while transferring some files
through scp to a FreeBSD8-STABLE server: CPUs usage sky-rocketed to 100% 
(system)
and network performance was awful (about 1.8 MiB/s).
I tried and succeeded in reproducing the issue with 'ttcp'. I decided
to use this little benchmark because is so simple (it is linked only against 
libc) that I can
be sure that the problem doesn't depend on scp/ssh or other parts of the system.

This is the output of 'uname -a':

FreeBSD polaris 8.0-STABLE FreeBSD 8.0-STABLE #24: Sun Jan 17 21:08:02
CET 2010 t...@polaris:/usr/obj/usr/src/sys/POLARIS  amd64

Here it's some relevant information to identify the NIC:

first from 'dmesg'

mskc0:  port 0x2000-0x20ff mem
0x9010-0x90103fff irq 17 at device 0.0 on pci134
msk0:  on mskc0
msk0: Ethernet address: 00:25:b3:52:fc:fa
miibus0:  on msk0
mskc0: [FILTER]
msk0: link state changed to DOWN
msk0: link state changed to UP

and then from 'pciconf -lv'

ms...@pci0:134:0:0: class=0x02 card=0x3074103c chip=0x436c11ab
rev=0x10 hdr=0x00
vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
device = 'Marvell 8072 Ethernet Nic (88E8072)'
class  = network
subclass   = ethernet

Here it's the output of 'ifconfig':

msk0: flags=8843 metric 0 mtu
1500
options=19b
ether 00:25:b3:52:fc:fa
inet 192.168.1.4 netmask 0xff00 broadcast 192.168.1.255
media: Ethernet autoselect (100baseTX )
satus: active


Attached you will find the results of my tests, I hope that the file
will be self-explanatory.

I'm wondering, are there any other tunable parameters (apart from MSI on/off) I
should try to modify? Should I file a PR? Are there any other interesting data
I should gather? With the proper guide I'm also available to contribute some
code myself.

Best regards
-- 
Emanuele A. Bagnaschi
* notebook - Linux 2.6.32 - hostname: elsinore *
* server - FreeBSD8-STABLE - hostname:atlantis * 


FIRST RUN - elsinore transmits, atlantis receives

elsinore --> atlantis (output on elsinore)

ttcp -n 12800 -t -s atlantis
ttcp-t: buflen=8192, nbuf=12800, align=16384/0, port=5001  tcp  -> atlantis
ttcp-t: socket
ttcp-t: connect
ttcp-t: 104857600 bytes in 8.87 real seconds = 11538.31 KB/sec +++
ttcp-t: 12800 I/O calls, msec/call = 0.71, calls/sec = 1442.29

atlantis <-- elsinore (output on atlantis)

ttcp -r -s
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 192.168.1.4
ttcp-r: 16777216 bytes in 1.43 real seconds = 11464.61 KB/sec +++
ttcp-r: 11562 I/O calls, msec/call = 0.13, calls/sec = 8090.45
ttcp-r: 0.0user 0.0sys 0:01real 3% 14i+1022d 502maxrss 0+2pf 11559+42csw

SECOND RUN - elsinore receives, atlantis transmits

elsinore <-- atlantis (output on elsinore)

ttcp -r -s
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 192.168.1.1
ttcp-r: 104857600 bytes in 9.00 real seconds = 11372.89 KB/sec +++
ttcp-r: 29235 I/O calls, msec/call = 0.32, calls/sec = 3246.94
ttcp-r: 0.0user 0.7sys 0:09real 8% 0i+0d 910maxrss 0+2pf 29195+456csw

atlantis --> elsinore (output on atlantis)

ttcp -t -s -n 12800 elsinore
ttcp-t: buflen=8192, nbuf=12800, align=16384/0, port=5001  tcp  -> elsinore
ttcp-t: socket
ttcp-t: connect
ttcp-t: 104857600 bytes in 8.99 real seconds = 11394.04 KB/sec +++
ttcp-t: 12800 I/O calls, msec/call = 0.72, calls/sec = 1424.26
ttcp-t: 0.0user 0.2sys 0:08real 3% 15i+1095d 578maxrss 0+2pf 27143+2543csw

-

* notebook - FreeBSD8-STABLE - hostname:polaris - msk with MSI enabled *
* server - FreeBSD8-STABLE - hostname:atlantis *


FIRST RUN - polaris transmits, atlantis receives

polaris --> atlantis (output on polaris)

ttcp -t -s -n 12800 atlantis
ttcp-t: buflen=8192, nbuf=12800, align=16384/0, port=5001  tcp  -> atlantis
ttcp-t: socket
ttcp-t: connect
ttcp-t: 104857600 bytes in 13.63 real seconds = 7514.90 KB/sec +++
ttcp-t: 12800 I/O calls, msec/call = 1.09, calls/sec = 939.36
ttcp-t: 0.1user 10.7sys 0:13real 80% 5i+408d 674maxrss 0+1pf 1004+1525csw

atlantis <-- polaris (output on atlantis)

ttcp -r -s
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 192.168.1.4
ttcp-r: 104857600 bytes in 13.63 real seconds = 7512.69 KB/sec +++
ttcp-r: 76875 I/O calls, msec/call = 0.18, calls/sec = 5640.02
ttcp-r: 0.0user 0.3sys 0:13real 2% 16i+1168d 502maxrss 0+2pf 76849+2128csw

SECOND RUN - polaris receives, atlantis transmits

polaris <-- atlantis (output on polaris)

ttcp -r -s
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 192.168.1.1
ttcp-r: 104857600 bytes in 53.68 real seconds = 1907.67 KB/sec +++
ttcp-r: 14021 I/O calls, msec/call = 3.92, calls/sec = 261.21
ttcp-r: 0.0user 14.9sys 0:53real 27% 7i+563d 600maxrss 0+2pf 1176+2765csw

atlantis --> polaris (output on polar

Re: 8.0-RELEASE -> -STABLE and size of /

[Bjoern A. Zeeb]

On Fri, 22 Jan 2010, Oliver Brandmueller wrote:

Hi,


I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default
512M. First step after setup was to csup to RELENG_8 and buildkernel and
buildworld (no custom kernel, no make.conf).

Instaling the new kernel failed, since /boot/kernel/ is already well
over 230 MBytes in size. moving that to kernel.old and writing a new one
with about the same size fails due to no space left on device.


Replying to the first post in the thread.

One first thing to help people to avoid problems with future upgrades
could be to just make / 1G:
http://people.freebsd.org/~bz/20100124-03-sysinstall-root-1g.diff

Another entirely untested patch would compress the symbol files:
http://people.freebsd.org/~bz/20100124-04-kernel-compress-symbols.diff

It would be interesting to see if (a) they work and (b) how much the
latter would safe.


/bz

--
Bjoern A. Zeeb It will not break if you know what you are doing.
___
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: Problematic network performance with Marvell 8072 on HP Probook 4710s

[Pyun YongHyeon]

On Sun, Jan 24, 2010 at 07:39:11PM +0100, Emanuele A. Bagnaschi wrote:
> Hi,
> I've been experiencing a troubling issue with a Marvell 8072 NIC on an HP
> ProBook 4710s. 
> I first noticed that there is a problem while transferring some files
> through scp to a FreeBSD8-STABLE server: CPUs usage sky-rocketed to 100% 
> (system)
> and network performance was awful (about 1.8 MiB/s).
> I tried and succeeded in reproducing the issue with 'ttcp'. I decided
> to use this little benchmark because is so simple (it is linked only against 
> libc) that I can
> be sure that the problem doesn't depend on scp/ssh or other parts of the 
> system.
> 

Last time I checked ttcp, it was broken with threading. So you have
to build ttcp without threading support or use netperf to check
performance numbers.

> This is the output of 'uname -a':
> 
> FreeBSD polaris 8.0-STABLE FreeBSD 8.0-STABLE #24: Sun Jan 17 21:08:02
> CET 2010 t...@polaris:/usr/obj/usr/src/sys/POLARIS  amd64
> 
> Here it's some relevant information to identify the NIC:
> 
> first from 'dmesg'
> 
> mskc0:  port 0x2000-0x20ff mem
> 0x9010-0x90103fff irq 17 at device 0.0 on pci134
> msk0:  on mskc0
> msk0: Ethernet address: 00:25:b3:52:fc:fa
> miibus0:  on msk0
> mskc0: [FILTER]
> msk0: link state changed to DOWN
> msk0: link state changed to UP
> 
> and then from 'pciconf -lv'
> 
> ms...@pci0:134:0:0: class=0x02 card=0x3074103c chip=0x436c11ab
> rev=0x10 hdr=0x00
> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
> device = 'Marvell 8072 Ethernet Nic (88E8072)'
> class  = network
> subclass   = ethernet
> 
> Here it's the output of 'ifconfig':
> 
> msk0: flags=8843 metric 0 mtu
> 1500
> options=19b
> ether 00:25:b3:52:fc:fa
> inet 192.168.1.4 netmask 0xff00 broadcast 192.168.1.255
> media: Ethernet autoselect (100baseTX )
> satus: active
> 
> 
> Attached you will find the results of my tests, I hope that the file
> will be self-explanatory.
> 

It seems you have Yukon Extreme controller and its revision is B0
which is known to have various silicon bug. How about disabling TX 
related offloading?(e.g. ifconfig msk0 -txcsum -tso) Does that make
any difference?

> I'm wondering, are there any other tunable parameters (apart from MSI on/off) 
> I
> should try to modify? Should I file a PR? Are there any other interesting data
> I should gather? With the proper guide I'm also available to contribute some
> code myself.
> 

Given that high rates of silicon bug of Yukon having a detailed
errata information would be great help to analyze the issue. But we
still have no access to the information as well as datasheet.
___
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: Loader, MBR and the boot process

[Mark Andrews]

In message , Dan N
aumov writes:
> On Sun, Jan 24, 2010 at 5:29 PM, John  wrote:
> > On Fri, Jan 22, 2010 at 07:02:53AM +0200, Dan Naumov wrote:
> >> On Fri, Jan 22, 2010 at 6:49 AM, Dan Naumov  wrote=
> :
> >> > On Fri, Jan 22, 2010 at 6:12 AM, Thomas K.  wro=
> te:
> >> >> On Fri, Jan 22, 2010 at 05:57:23AM +0200, Dan Naumov wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >>> I recently found a nifty "FreeBSD ZFS root installation script" and
> >> >>> been reworking it a bit to suit my needs better, including changing =
> it
> >> >>> from GPT to MBR partitioning. However, I was stumped, even though I
> >> >>> had done everything right (or so I thought), the system would get
> >> >>> stuck at Loader and refuse to go anywhere. After trying over a dozen
> >> >>
> >> >> probably this line is the cause:
> >> >>
> >> >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s1a skip=3D1 seek=
> =3D1024
> >> >>
> >> >> Unless by "swap first" you meant the on-disk location, and not the
> >> >> partition letter. If swap is partition "a", you're writing the loader
> >> >> into swapspace.
> >> >>
> >> >>
> >> >> Regards,
> >> >> Thomas
> >> >
> >> > At first you made me feel silly, but then I decided to double-check, I
> >> > uncommented the swap line in the partitioning part again, ensured I
> >> > was writing the bootloader to "${TARGETDISK}"s1b and ran the script.
> >> > Same problem, hangs at loader. Again, if I comment out the swap,
> >> > giving the entire slice to ZFS and then write the bootloader to
> >> > "${TARGETDISK}"s1a, run the script, everything works.
> >>
> >> I have also just tested creating 2 slices, like this:
> >>
> >> gpart create -s mbr "${TARGETDISK}"
> >> gpart add -s 3G -t freebsd "${TARGETDISK}"
> >> gpart create -s BSD "${TARGETDISK}"s1
> >> gpart add -t freebsd-swap "${TARGETDISK}"s1
> >>
> >> gpart add -t freebsd "${TARGETDISK}"
> >> gpart create -s BSD "${TARGETDISK}"s2
> >> gpart add -t freebsd-zfs "${TARGETDISK}"s2
> >>
> >> gpart set -a active -i 2 "${TARGETDISK}"
> >> gpart bootcode -b /mnt2/boot/boot0 "${TARGETDISK}"
> >>
> >>
> >> and later:
> >>
> >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s2 count=3D1
> >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s2a skip=3D1 seek=3D=
> 1024
> >>
> >>
> >> Putting the swap into it's own slice and then putting FreeBSD into
> >> it's own slice worked fine. So why the hell can't they both coexist in
> >> 1 slice if the swap comes first?
> >
> > I know what the answer to this USED to be, but I don't know if it is
> > still true (obviously, I think so, I or wouldn't waste your time).
> >
> > The filesystem code is all carefully written to avoid the very
> > first few sector of the partition. =A0That's because the partition
> > table is there for the first filesystem of the slice (or disk).
> > That's a tiny amout of space wasted, because it's also skipped on
> > all the other filesystems even though there's not actually anything
> > there, but it was a small inefficency, even in the 70's.
> >
> > Swap does not behave that way. =A0SWAP will begin right at the slice
> > boundry, with 0 offset. =A0As long as it's not the first partition, no
> > harm, no foul. =A0If it IS the first partition, you just nuked your parti=
> tion
> > table. =A0As long as SWAP owns the slice, again, no harm, no foul, but
> > if there were filesystems BEHIND it, you just lost 'em.
> >
> > That's the way it always used to be, and I think it still is. =A0SWAP can
> > only be first if it is the ONLY thing using that slice (disk), otherwise,
> > you need a filesystem first to protect the partition table.
> > --
> >
> > John Lind
> > j...@starfire.mn.org
> 
> This explanation does sound logical, but holy crap, if this is the
> case, you'd think there would be bells, whistles and huge red label
> warnings in EVERY FreeBSD installation / partitioning guide out there
> warning people to not put swap first (unless given a dedicated slice)
> under any circumstances. The warnings were nowhere to be seen and lots
> of pointy hair first greyed and were then lost during the process of
> me trying to figure out why my system would install but wouldn't boot.

>From "man bsdlabel".

 offset  The offset of the start of the partition from the beginning of
 the drive in sectors, or * to have bsdlabel calculate the correct
 offset to use (the end of the previous partition plus one, ignor-
 ing partition `c'.  For partition `c', * will be interpreted as
 an offset of 0.  The first partition should start at offset 16,
 because the first 16 sectors are reserved for metadata.

> - Sincerely,
> Dan Naumov
> ___
> 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"
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742

ata driver downgrades transfer speed for Intel ICH5 SATA150 in RELENG_8 ?

[Kristian Kræmmer Nielsen]

Hey,

I just updated my kernel from RELEASE_8_0 to RELENG_8 and by rutine I 
compare my dmesg -a output to make sure everything still works as expected.


I notices that the ata-driver suddently downgraded the speed of my Intel 
ICH5 SATS150 from SATA150 til UDMA133 - and I am not allowed to change 
it manually by using atacontrol.


Can this have something to do with the recent rewrite of ata-sata.c ?
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-sata.c.diff?r1=1.6.2.2;r2=1.6.2.3

By mav:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-sata.c


Here is the dmesg output compared with RELEASE_8_0 to RELENG_8:

...cut out...
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0

ata0:  on atapci0
ata0: [ITHREAD]
ata1:  on atapci0
ata1: [ITHREAD]
atapci1:  port 
0xec00-0xec07,0xe800-0xe803,0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc0f 
irq 18 at d

evice 31.2 on pci0
atapci1: [ITHREAD]
ata2:  on atapci1
ata2: [ITHREAD]
ata3:  on atapci1
ata3: [ITHREAD]
...cut out...
-ad4: 305245MB  at ata2-master SATA150
+ad4: 305245MB  at ata2-master UDMA133
...cut out...
-ad6: 305245MB  at ata3-master SATA150
+ad6: 305245MB  at ata3-master UDMA133
...cut out...
 ar0: 305245MB  status: READY
 ar0: disk0 READY (master) using ad4 at ata2-master
 ar0: disk1 READY (mirror) using ad6 at ata3-master
...end...

Best regards,
Kristian Kræmmer Nielsen,
Odense, Denmark


___
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"

ata driver downgrades transfer speed for Intel ICH5 SATA150 in RELENG_8 ?

[Kristian Kræmmer Nielsen]

Hey,

I just updated my kernel from RELEASE_8_0 to RELENG_8 and by rutine I
compare my dmesg -a output to make sure everything still works as expected.

I notices that the ata-driver suddently downgraded the speed of my Intel
ICH5 SATS150 from SATA150 til UDMA133 - and I am not allowed to change
it manually by using atacontrol.

Can this have something to do with the recent rewrite of ata-sata.c ?
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-sata.c.diff?r1=1.6.2.2;r2=1.6.2.3

By mav:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-sata.c


Here is the dmesg output compared with RELEASE_8_0 to RELENG_8:

...cut out...
atapci0:  port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0
ata0:  on atapci0
ata0: [ITHREAD]
ata1:  on atapci0
ata1: [ITHREAD]
atapci1:  port
0xec00-0xec07,0xe800-0xe803,0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc0f
irq 18 at d
evice 31.2 on pci0
atapci1: [ITHREAD]
ata2:  on atapci1
ata2: [ITHREAD]
ata3:  on atapci1
ata3: [ITHREAD]
...cut out...
-ad4: 305245MB  at ata2-master SATA150
+ad4: 305245MB  at ata2-master UDMA133
...cut out...
-ad6: 305245MB  at ata3-master SATA150
+ad6: 305245MB  at ata3-master UDMA133
...cut out...
 ar0: 305245MB  status: READY
 ar0: disk0 READY (master) using ad4 at ata2-master
 ar0: disk1 READY (mirror) using ad6 at ata3-master
...end...

Best regards,
Kristian Kræmmer Nielsen,
Odense, Denmark



___
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: PCIe audio cards: what is tob be preferred with FreeBSD 8.0/9-CURRENT?

[Alexander Motin]

O. Hartmann wrote:
> Well,
> At this very moment I utilise a M-Audio 5.1 PCI-audio board with which
> I'm really satisfied. My next box doesn't have PCI slots at all (ASUS
> P6T6-WS Revolution) and due to the fact I'm using Windows 7 sometimes
> for recreational gaming, I'd like to have a moderate expensive audio
> board with the workstation which is supported by FreeBSD 8/9. In the
> past - means two or three ywars ago, I had problems with Soundblaster
> PCIe boards, so I was recommended avoiding those and choosing the more
> elabotrated M-Audio cards for the PCI bus.
> At this moment, I look for the Soundblaster X-Fi range of PCIe cards,
> but I'm not sure whether they are supported by FreeBSd 8/9. Any
> suggestions?

I would first test on-board HDA codec, placed on that motherboard. They
are free and usually work with FreeBSD just out of the box, using
snd_hda driver. Now snd_hda and snd_uaudio are only two drivers
supporting multichannel playback. If you need analog connection, snd_hda
can usually provide multichannel 24bit/192kHz playback. But also it
supports digital SPDIF I/O, including AC3/DTS pass-through. Together
with SPDIF-connected external audio receiver, even simple HDA codec
could become very interesting high-quality choice.

Personally I am completely fulfilled with combination of simple Realtek
HDA codec, digitally connected via SPDIF to Marantz SR4001 receiver,
loaded to the full-sized Eltax 7.1 speaker set. Previously I was using
Creative Audigy2 ZS, but now it just collecting dust in my table. It
works, but I really don't need it.

PS: If you want to look cool, you may use optical SPDIF connection. :)

-- 
Alexander Motin
___
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: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance

[Alexander Motin]

Dan Naumov wrote:
> This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and
> 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the
> bonnie results. It also sadly seems to confirm the very slow speed :(
> The disks are attached to a 4-port Sil3124 controller and again, my
> Windows benchmarks showing 65mb/s+ were done on exact same machine,
> with same disks attached to the same controller. Only difference was
> that in Windows the disks weren't in a mirror configuration but were
> tested individually. I do understand that a mirror setup offers
> roughly the same write speed as individual disk, while the read speed
> usually varies from "equal to individual disk speed" to "nearly the
> throughput of both disks combined" depending on the implementation,
> but there is no obvious reason I am seeing why my setup offers both
> read and write speeds roughly 1/3 to 1/2 of what the individual disks
> are capable of. Dmesg shows:
> 
> atapci0:  port 0x1000-0x100f mem
> 0x90108000-0x9010807f,0x9010-0x90107fff irq 21 at device 0.0 on
> pci4
> ad8: 1907729MB  at ata4-master SATA300
> ad10: 1907729MB  at ata5-master SATA300

8.0-RELEASE, and especially 8-STABLE provide alternative, much more
functional driver for this controller, named siis(4). If your SiI3124
card installed into proper bus (PCI-X or PCIe x4/x8), it can be really
fast (up to 1GB/s was measured).

-- 
Alexander Motin
___
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: Extra keys in multimedia keyboard doesn't work

[Krzysztof Dajka]

On Sun, 24 Jan 2010 01:43:14 -, Jeremy Chadwick  
 wrote:



If so: yes, FreeBSD's USB driver appears to lack support for these.  Or,
well, it did on RELENG_7 (which is a completely different USB driver),
so it sounds like RELENG_8 needs some work in this regard.


I did check my keyboard with FreeBSD 7.2 and it wasn't supported either.  
Xev also didn't return anything.

___
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: immense delayed write to file system (ZFS and UFS2), performance issues

[Aragon Gouveia]

On 01/18/10 22:13, O. Hartmann wrote:

Symptome: All boxes have ZFS and UFS2 filesystems. Since two weeks or
so, sometimes the I/O performance drops massively when doing 'svn
update', 'make world' or even 'make kernel'. It doesn't matter what
memory and how many cpu the box has, it get stuck for several seconds
and freezing. On the UP box, this is sometimes for 10 - 20 seconds.
A very interesting phenomenon is the massively delayed file writing on
ZFS filesystems I realise. Editing a file in 'vi' running on one XTerm
and having in another Xterminal my shell for compiling this file, it
takes sometimes up to 20 seconds to get the file updated after it has
been written. It's like having an old, slow NFS connection with long
cache delays.
These massively delayed file transactions are not necessarely under
heavy load, sometimes they occur in a relaxed situation. They seem to
occur much more often on the UP box than on the SMP boxes, but this
strange phenomenon also occur on the Dell Poweredge II, which has 16GB
RAM and summa summarum 16 cores. This phenomenon does occur on ZFS- and
UFS2 filesystems as well. It is hardly reproducable.


I'm experiencing the same thing, except in my case it's most noticeable 
when writing to a USB flash drive with a FAT32 filesystem.  It slows the 
entire system down, even if the data being written is coming from cache 
or a memory file system.


I don't know if it's related.  I'm running 8-STABLE from about 4 December.


Regards,
Aragon
___
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: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd problem?)

[Doug Barton]

On 01/24/10 03:02, Harald Schmalzbauer wrote:

Alexander V. Chernikov schrieb am 24.01.2010 10:24 (localtime):

Please try to rebuild port with

post-configure:
@${REINPLACE_CMD} -e 's/^\(CFLAGS .*\)-O2 \(.*\)$$/\1 -O0 \2/'
${WRKSRC}/nss/Makefile


That should be pre- or post- patch, since it's actually modifying 
something.



hth,

Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

Computers are useless. They can only give you answers.
-- Pablo Picasso

___
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: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd problem?)

[Alexander V. Chernikov]

Doug Barton wrote:

On 01/24/10 03:02, Harald Schmalzbauer wrote:

Alexander V. Chernikov schrieb am 24.01.2010 10:24 (localtime):

Please try to rebuild port with

post-configure:
@${REINPLACE_CMD} -e 's/^\(CFLAGS .*\)-O2 \(.*\)$$/\1 -O0 \2/'
${WRKSRC}/nss/Makefile


That should be pre- or post- patch, since it's actually modifying 
something.

I can't do this before configure -
Makefile.in contains only @CFLAGS@ which needs to be substituted from 
configure and CFLAGS cannot be predicted due to

possible environment/make.conf variables



hth,

Doug



___
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: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd problem?)

[Doug Barton]

On 01/24/10 15:10, Alexander V. Chernikov wrote:

Doug Barton wrote:

On 01/24/10 03:02, Harald Schmalzbauer wrote:

Alexander V. Chernikov schrieb am 24.01.2010 10:24 (localtime):

Please try to rebuild port with

post-configure:
@${REINPLACE_CMD} -e 's/^\(CFLAGS .*\)-O2 \(.*\)$$/\1 -O0 \2/'
${WRKSRC}/nss/Makefile


That should be pre- or post- patch, since it's actually modifying
something.

I can't do this before configure -
Makefile.in contains only @CFLAGS@ which needs to be substituted from
configure and CFLAGS cannot be predicted due to
possible environment/make.conf variables


um, that's odd, but I'll take your word for it. :)


Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

Computers are useless. They can only give you answers.
-- Pablo Picasso

___
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: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance

[Dan Naumov]

On Sun, Jan 24, 2010 at 11:53 PM, Alexander Motin  wrote:
> Dan Naumov wrote:
>> This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and
>> 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the
>> bonnie results. It also sadly seems to confirm the very slow speed :(
>> The disks are attached to a 4-port Sil3124 controller and again, my
>> Windows benchmarks showing 65mb/s+ were done on exact same machine,
>> with same disks attached to the same controller. Only difference was
>> that in Windows the disks weren't in a mirror configuration but were
>> tested individually. I do understand that a mirror setup offers
>> roughly the same write speed as individual disk, while the read speed
>> usually varies from "equal to individual disk speed" to "nearly the
>> throughput of both disks combined" depending on the implementation,
>> but there is no obvious reason I am seeing why my setup offers both
>> read and write speeds roughly 1/3 to 1/2 of what the individual disks
>> are capable of. Dmesg shows:
>>
>> atapci0:  port 0x1000-0x100f mem
>> 0x90108000-0x9010807f,0x9010-0x90107fff irq 21 at device 0.0 on
>> pci4
>> ad8: 1907729MB  at ata4-master SATA300
>> ad10: 1907729MB  at ata5-master SATA300
>
> 8.0-RELEASE, and especially 8-STABLE provide alternative, much more
> functional driver for this controller, named siis(4). If your SiI3124
> card installed into proper bus (PCI-X or PCIe x4/x8), it can be really
> fast (up to 1GB/s was measured).
>
> --
> Alexander Motin

Sadly, it seems that utilizing the new siis driver doesn't do much good:

Before utilizing siis:

iozone -s 4096M -r 512 -i0 -i1
random
randombkwd   record   stride
  KB  reclen   write rewritereadrereadread
writeread  rewrite read   fwrite frewrite   fread  freread
 4194304 512   28796   287665161050695

After enabling siis in loader.conf (and ensuring the disks show up as ada):

iozone -s 4096M -r 512 -i0 -i1

random
randombkwd   record   stride
  KB  reclen   write rewritereadrereadread
writeread  rewrite read   fwrite frewrite   fread  freread
 4194304 512   28781   288974721450540

I've checked with the manufacturer and it seems that the Sil3124 in
this NAS is indeed a PCI card. More info on the card in question is
available at http://green-pcs.co.uk/2009/01/28/tranquil-bbs2-those-pci-cards/
I have the card described later on the page, the one with 4 SATA ports
and no eSATA. Alright, so it being PCI is probably a bottleneck in
some ways, but that still doesn't explain the performance THAT bad,
considering that same hardware, same disks, same disk controller push
over 65mb/s in both reads and writes in Win2008. And agian, I am
pretty sure that I've had "close to expected" results when I was
booting an UFS FreeBSD installation off an SSD (attached directly to
SATA port on the motherboard) while running the same kinds of
benchmarks with Bonnie and DD on a ZFS mirror made directly on top of
2 raw disks.


- Sincerely,
Dan Naumov
___
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: atheros broadcast/multicast corruption with multiple hostap's

[Russell Yount]

On Sat, Jan 23, 2010 at 8:22 PM, Sam Leffler  wrote:

> Russell Yount wrote:
> > On Sun, Jan 17, 2010 at 1:45 PM, Sam Leffler  > > wrote:
> >
> > Russell Yount wrote:
> >
> >
> >
> > On Sat, Jan 16, 2010 at 3:21 PM, Sam Leffler  >    > >> wrote:
> >
> >Russell Yount wrote:
> >
> >It seems AP to client broadcasts/multicasts traffic is
> >broken when using WPA2/802.11i with multiple hostapds in
> 8.0.
> >
> >Only the SSID associated with the last hostapd to be
> > started has
> >AP to client broadcasts/multicasts being delivered
> correctly.
> >
> >The AP and client are 8.0 freebsd systems althought I see
> > same
> >problems with windows XP as a client.
> >
> >The AP has 4 hostapds configured to use TLS with client
> >certificates for
> >authentication. (hostapd recompiled with
> >HOSTAPD_CFLAGS=-DEAP_SERVER)
> >The AP and client radio are shown as ath0: AR5212 mac 5.9
> > RF5112
> >phy 4.3
> >in dmesg.
> >
> >Client authenticate using client certificates associate
> > correctly
> >to all 4 SSIDs. Unicast traffic flows correctly between
> > clients
> >and AP
> >for all for 4 SSIDs. Client to AP broadcast/multicast
> > traffic works
> >on of 4 SSIDs. AP to client broadcast/multicast traffic
> > only works
> >on 1 of the SSIDs. I have documented this using ARP
> > broadcasts,
> >but normal IP broadcasts also observed to corrupted.
> >
> >When an ARP request is send through the AP to an
> > associated client
> >it seems to be trashed on any of the SSID except the one
> > associated
> >with the last hostapd to be started. Here is the output of
> >client side
> >tcpdump showing the problems.
> >
> >In the first client side tcpdump with the hostapd
> associated
> >with the SSID
> >being associaed with the last hostapd started and the
> traffic
> >flowing
> >normally.
> >
> >In the second client side tcpdump with the hostapd
> associated
> >with the SSID
> >being not the last hostapd started the ARP request is
> resent
> >multiple times
> >and appears corrupted.
> >
> >I would really like to find a fix for this.
> >Any help would be greatly appreciated.
> >
> >
> >This sounds like the crypto encap of the frame is clobbering
> the
> >mbuf contents.  You can verify this by setting up multiple
> > vaps w/o
> >WPA.  If this is the problem look for the mbuf copy logic for
> > mcast
> >frames and make sure a deep copy is done.
> >
> >   Sam
> >
> >The four VAPs broadcast traffic works find without WPA if I
> > do not start hostapds on them
> >  I have been trying to discovery why broadcast traffic only
> > works correctly on the VAP associated with the last hostapd to
> > be started. I have move with VAP has the working broadcast
> > traffic by restarting the hostapd
> > associated with it.
> >  It would seem something in the WPA/802.1x layer initialization
> > remembers which hostapd was started last and that affected the
> > crypto encap.
> >  I keep looking but do not see any place in the code that could
> > account for this.
> >  It seems the corrupt crypto encap also happens on broadcast
> > between stations.
> > Please correct me if I am wrong:
> > but when using hostapd normally traffic is bridged withing the
> card.
> > So if a station sends to the VAP a broadcast it is actaully
> > sending a non- broadcast frame to the AP
> > and the AP sends the frame to all the other stations.
> >
> >
> > I told you waht the likely problem is.  Look in the net80211 layer
> > in the kernel for the problem.
> >
> >Sam
> >
> >
> >
> >
> >  I tried to find problems in mbuf corruption
> > in ieee80211_output.c by placing
> >
> >   m = m_unshare(m,M_NOWAIT);
> >   if (m == NULL) {
> >   IEEE80211_DPRINTF(vap, IEEE80211_MSG_OUTPUT,
> >   "%s: cannot get writable mbuf\n", __func__);
> >   return NULL;
> >   }
> >
> > at begining ieee80211_mbuf_adjust() and at
> > beginning of ieee80211_encap() with no change
> > in the broadcast traffic behaviour.
> >
> > I tried then to in ieee802

Re: Extra keys in multimedia keyboard doesn't work

[Jeremy Chadwick]

On Sun, Jan 24, 2010 at 11:47:46PM -, Krzysztof Dajka wrote:
> On Sun, 24 Jan 2010 01:43:14 -, Jeremy Chadwick
>  wrote:
> 
> >If so: yes, FreeBSD's USB driver appears to lack support for these.  Or,
> >well, it did on RELENG_7 (which is a completely different USB driver),
> >so it sounds like RELENG_8 needs some work in this regard.
> 
> I did check my keyboard with FreeBSD 7.2 and it wasn't supported
> either. Xev also didn't return anything.

My sentence meant: it didn't work on RELENG_7, which used a different
USB stack compared to RELENG_8.  :-)

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
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: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance

[Dan Naumov]

On Mon, Jan 25, 2010 at 2:14 AM, Dan Naumov  wrote:
> On Sun, Jan 24, 2010 at 11:53 PM, Alexander Motin  wrote:
>> Dan Naumov wrote:
>>> This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and
>>> 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the
>>> bonnie results. It also sadly seems to confirm the very slow speed :(
>>> The disks are attached to a 4-port Sil3124 controller and again, my
>>> Windows benchmarks showing 65mb/s+ were done on exact same machine,
>>> with same disks attached to the same controller. Only difference was
>>> that in Windows the disks weren't in a mirror configuration but were
>>> tested individually. I do understand that a mirror setup offers
>>> roughly the same write speed as individual disk, while the read speed
>>> usually varies from "equal to individual disk speed" to "nearly the
>>> throughput of both disks combined" depending on the implementation,
>>> but there is no obvious reason I am seeing why my setup offers both
>>> read and write speeds roughly 1/3 to 1/2 of what the individual disks
>>> are capable of. Dmesg shows:
>>>
>>> atapci0:  port 0x1000-0x100f mem
>>> 0x90108000-0x9010807f,0x9010-0x90107fff irq 21 at device 0.0 on
>>> pci4
>>> ad8: 1907729MB  at ata4-master SATA300
>>> ad10: 1907729MB  at ata5-master SATA300
>>
>> 8.0-RELEASE, and especially 8-STABLE provide alternative, much more
>> functional driver for this controller, named siis(4). If your SiI3124
>> card installed into proper bus (PCI-X or PCIe x4/x8), it can be really
>> fast (up to 1GB/s was measured).
>>
>> --
>> Alexander Motin
>
> Sadly, it seems that utilizing the new siis driver doesn't do much good:
>
> Before utilizing siis:
>
> iozone -s 4096M -r 512 -i0 -i1
>                                                            random
> random    bkwd   record   stride
>              KB  reclen   write rewrite    read    reread    read
> write    read  rewrite     read   fwrite frewrite   fread  freread
>         4194304     512   28796   28766    51610    50695
>
> After enabling siis in loader.conf (and ensuring the disks show up as ada):
>
> iozone -s 4096M -r 512 -i0 -i1
>
>                                                            random
> random    bkwd   record   stride
>              KB  reclen   write rewrite    read    reread    read
> write    read  rewrite     read   fwrite frewrite   fread  freread
>         4194304     512   28781   28897    47214    50540

Just to add to the numbers above, exact same benchmark, on 1 disk
(detached 2nd disk from the mirror) while using the siis driver:

random
randombkwd   record   stride
  KB  reclen   write rewritereadrereadread
writeread  rewrite read   fwrite frewrite   fread  freread
 4194304 512   57760   563716886774047


- Dan
___
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"

ports/packages management in jail

[Maciej Jan Broniarz]

Hi,

I am running a server with several jails. They were created using 
ezjail. What is the best way, to allow jail internal admin to manage 
ports/packages by himself?
By default ezjail shares ports tree between basejail and otherjails. Is 
there a way for each jail to have a separate ports tree?


Best regards,
mjb
___
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"

make installworld failed

[Maciej Jan Broniarz]

Hi,

I am trying to installworld:

/usr/share/man/man8/bootpgw.8.gz -> /usr/share/man/man8/bootpd.8.gz
rm: /usr/share/man/man8/bootpgw.8: Not a directory
rm: /usr/share/man/man8/bootpgw.8.gz: Not a directory
*** Error code 1

Stop in /usr/src/libexec/bootpd.
*** Error code 1

Stop in /usr/src/libexec.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.


What might be the problem?

My system is 8.0-RELEASE, sources taken from cvs today.

All best,
mjb
___
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"

su password prompt ti stdout instead of /dev/tty

[Cyrille Lefevre]

Hi,

su password prompt is displayed to *stdout* instead of */dev/tty*.

# su user
$ su root -c date > /tmp/date 2>&1
(nothing displayed)
$ cat /tmp/date
Password:su: Sorry
$ uname -a
FreeBSD freebsd8.my.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 
21 15:48:17 UTC 2009 
r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386


I suppose this is a getpass() problem ?

Regards,

Cyrille Lefevre
--
mailto:cyrille.lefevre-li...@laposte.net

___
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: Loader, MBR and the boot process

[Robert Noland]

On Mon, 2010-01-25 at 07:57 +1100, Mark Andrews wrote:
> In message , Dan 
> N
> aumov writes:
> > On Sun, Jan 24, 2010 at 5:29 PM, John  wrote:
> > > On Fri, Jan 22, 2010 at 07:02:53AM +0200, Dan Naumov wrote:
> > >> On Fri, Jan 22, 2010 at 6:49 AM, Dan Naumov  wrote=
> > :
> > >> > On Fri, Jan 22, 2010 at 6:12 AM, Thomas K.  
> > >> > wro=
> > te:
> > >> >> On Fri, Jan 22, 2010 at 05:57:23AM +0200, Dan Naumov wrote:
> > >> >>
> > >> >> Hi,
> > >> >>
> > >> >>> I recently found a nifty "FreeBSD ZFS root installation script" and
> > >> >>> been reworking it a bit to suit my needs better, including changing =
> > it
> > >> >>> from GPT to MBR partitioning. However, I was stumped, even though I
> > >> >>> had done everything right (or so I thought), the system would get
> > >> >>> stuck at Loader and refuse to go anywhere. After trying over a dozen
> > >> >>
> > >> >> probably this line is the cause:
> > >> >>
> > >> >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s1a skip=3D1 seek=
> > =3D1024
> > >> >>
> > >> >> Unless by "swap first" you meant the on-disk location, and not the
> > >> >> partition letter. If swap is partition "a", you're writing the loader
> > >> >> into swapspace.
> > >> >>
> > >> >>
> > >> >> Regards,
> > >> >> Thomas
> > >> >
> > >> > At first you made me feel silly, but then I decided to double-check, I
> > >> > uncommented the swap line in the partitioning part again, ensured I
> > >> > was writing the bootloader to "${TARGETDISK}"s1b and ran the script.
> > >> > Same problem, hangs at loader. Again, if I comment out the swap,
> > >> > giving the entire slice to ZFS and then write the bootloader to
> > >> > "${TARGETDISK}"s1a, run the script, everything works.
> > >>
> > >> I have also just tested creating 2 slices, like this:
> > >>
> > >> gpart create -s mbr "${TARGETDISK}"
> > >> gpart add -s 3G -t freebsd "${TARGETDISK}"
> > >> gpart create -s BSD "${TARGETDISK}"s1
> > >> gpart add -t freebsd-swap "${TARGETDISK}"s1
> > >>
> > >> gpart add -t freebsd "${TARGETDISK}"
> > >> gpart create -s BSD "${TARGETDISK}"s2
> > >> gpart add -t freebsd-zfs "${TARGETDISK}"s2
> > >>
> > >> gpart set -a active -i 2 "${TARGETDISK}"
> > >> gpart bootcode -b /mnt2/boot/boot0 "${TARGETDISK}"
> > >>
> > >>
> > >> and later:
> > >>
> > >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s2 count=3D1
> > >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s2a skip=3D1 seek=3D=
> > 1024
> > >>
> > >>
> > >> Putting the swap into it's own slice and then putting FreeBSD into
> > >> it's own slice worked fine. So why the hell can't they both coexist in
> > >> 1 slice if the swap comes first?
> > >
> > > I know what the answer to this USED to be, but I don't know if it is
> > > still true (obviously, I think so, I or wouldn't waste your time).
> > >
> > > The filesystem code is all carefully written to avoid the very
> > > first few sector of the partition. =A0That's because the partition
> > > table is there for the first filesystem of the slice (or disk).
> > > That's a tiny amout of space wasted, because it's also skipped on
> > > all the other filesystems even though there's not actually anything
> > > there, but it was a small inefficency, even in the 70's.
> > >
> > > Swap does not behave that way. =A0SWAP will begin right at the slice
> > > boundry, with 0 offset. =A0As long as it's not the first partition, no
> > > harm, no foul. =A0If it IS the first partition, you just nuked your parti=
> > tion
> > > table. =A0As long as SWAP owns the slice, again, no harm, no foul, but
> > > if there were filesystems BEHIND it, you just lost 'em.
> > >
> > > That's the way it always used to be, and I think it still is. =A0SWAP can
> > > only be first if it is the ONLY thing using that slice (disk), otherwise,
> > > you need a filesystem first to protect the partition table.
> > > --
> > >
> > > John Lind
> > > j...@starfire.mn.org
> > 
> > This explanation does sound logical, but holy crap, if this is the
> > case, you'd think there would be bells, whistles and huge red label
> > warnings in EVERY FreeBSD installation / partitioning guide out there
> > warning people to not put swap first (unless given a dedicated slice)
> > under any circumstances. The warnings were nowhere to be seen and lots
> > of pointy hair first greyed and were then lost during the process of
> > me trying to figure out why my system would install but wouldn't boot.
> 
> >From "man bsdlabel".
> 
>  offset  The offset of the start of the partition from the beginning of
>  the drive in sectors, or * to have bsdlabel calculate the correct
>  offset to use (the end of the previous partition plus one, ignor-
>  ing partition `c'.  For partition `c', * will be interpreted as
>  an offset of 0.  The first partition should start at offset 16,
>  because the first 16 sectors are reserved for metadata.

Ok, now this has my attention... My gut feeling right now is that this
is 

Re: su password prompt ti stdout instead of /dev/tty

[Glen Barber]

Hi,

Cyrille Lefevre wrote: 
> 
> Hi,
> 
> su password prompt is displayed to *stdout* instead of */dev/tty*.
> 
> # su user
> $ su root -c date > /tmp/date 2>&1
> (nothing displayed)
> $ cat /tmp/date
> Password:su: Sorry
> $ uname -a
> FreeBSD freebsd8.my.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 
> 21 15:48:17 UTC 2009 
> r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
> 
> I suppose this is a getpass() problem ?
> 

I cannot reproduce this.  In fact,

su root -c date > /tmp/date

hangs waiting for input.

orion % su root -c date > /tmp/date 
^C
su: Sorry
orion % less /tmp/date 
Password:
orion % 

Also, you appear to be running an unpatched version of FreeBSD 8.0,
subject to the rtld exploit (among a few others).  I'd suggest upgrading.

For what it's worth:
orion % uname -a
FreeBSD orion 8.0-STABLE FreeBSD 8.0-STABLE #20 r202187: Wed Jan 13
11:51:15 EST 2010 r...@orion:/usr/obj/usr/src/sys/ORION  amd64

Regards,

-- 
Glen Barber
___
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: su password prompt ti stdout instead of /dev/tty

[jhell]

On Sun, 24 Jan 2010 21:57, glen.j.barber@ wrote:

Hi,

Cyrille Lefevre wrote:


Hi,

su password prompt is displayed to *stdout* instead of */dev/tty*.

# su user
$ su root -c date > /tmp/date 2>&1
(nothing displayed)
$ cat /tmp/date
Password:su: Sorry
$ uname -a
FreeBSD freebsd8.my.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov
21 15:48:17 UTC 2009
r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

I suppose this is a getpass() problem ?



This is intended operation as su(1) may not always be affiliated with a 
TTY. This leaves it open for a script to chat with much like what samba 
does with its passwd chat mechanism.




I cannot reproduce this.  In fact,

su root -c date > /tmp/date

hangs waiting for input.

orion % su root -c date > /tmp/date
^C
su: Sorry
orion % less /tmp/date
Password:
orion %



This is essentially what the OP stated was happening except you forgot the 
2>&1.



Also, you appear to be running an unpatched version of FreeBSD 8.0,
subject to the rtld exploit (among a few others).  I'd suggest upgrading.

For what it's worth:
orion % uname -a
FreeBSD orion 8.0-STABLE FreeBSD 8.0-STABLE #20 r202187: Wed Jan 13
11:51:15 EST 2010 r...@orion:/usr/obj/usr/src/sys/ORION  amd64

Regards,







--

 jhell

___
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: su password prompt ti stdout instead of /dev/tty

[jhell]

On Sun, 24 Jan 2010 22:48, jhell@ wrote:


On Sun, 24 Jan 2010 21:57, glen.j.barber@ wrote:

Hi,

Cyrille Lefevre wrote:


Hi,

su password prompt is displayed to *stdout* instead of */dev/tty*.

# su user
$ su root -c date > /tmp/date 2>&1
(nothing displayed)
$ cat /tmp/date
Password:su: Sorry
$ uname -a
FreeBSD freebsd8.my.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov
21 15:48:17 UTC 2009
r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

I suppose this is a getpass() problem ?



This is intended operation as su(1) may not always be affiliated with a TTY. 
This leaves it open for a script to chat with much like what samba does with 
its passwd chat mechanism.




If you mean for the program to appropriately append or overwrite to a file 
you should ( su user -c 'date >output 2>&1' ) instead




I cannot reproduce this.  In fact,

su root -c date > /tmp/date

hangs waiting for input.

orion % su root -c date > /tmp/date
^C
su: Sorry
orion % less /tmp/date
Password:
orion %



This is essentially what the OP stated was happening except you forgot the 
2>&1.



Also, you appear to be running an unpatched version of FreeBSD 8.0,
subject to the rtld exploit (among a few others).  I'd suggest upgrading.

For what it's worth:
orion % uname -a
FreeBSD orion 8.0-STABLE FreeBSD 8.0-STABLE #20 r202187: Wed Jan 13
11:51:15 EST 2010 r...@orion:/usr/obj/usr/src/sys/ORION  amd64

Regards,













--

 jhell

___
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: PCIe audio cards: what is tob be preferred with FreeBSD 8.0/9-CURRENT?

[perryh]

"O. Hartmann"  wrote:
> At this very moment I utilise a M-Audio 5.1 PCI-audio board with
> which I'm really satisfied. My next box doesn't have PCI slots
> at all ... I look for the Soundblaster X-Fi range of PCIe cards, 

It's possible to get an adapter that plugs into a PCIe slot and
provides a PCI slot, which might enable you to continue using
your current card.  I've never actually seen one, so don't know
about the mechanics; it could turn out that it can only be used
by leaving the cover off of the box :(
___
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: em interface slow down on 8.0R

[Nick Rogers]

I am having similar em interface problems with some of my production
machines running older intel 2-port cards, since upgrading from 7.2-RELEASE
to 8.0-RELEASE. The problem is basically, everything works fine, but
periodically the interface "hangs" (tcpdump shows no frames). A reboot or an
ifconfig down followed by an ifconfig up fixes the problem for some time.
Traffic peaks at maybe 20mbit per day and its all 802.1Q VLAN tagged traffic
(about 10 vlan interfaces). When this happens netstat reports only errors
and no packets on the affected interface. Media is set to autoselect. This
is happening about 5-10x per day.

Heres relevant sysctl and ifconfig info.

dev.em.6.%desc: Intel(R) PRO/1000 Network Connection 6.9.14
dev.em.6.%driver: em
dev.em.6.%location: slot=3 function=0
dev.em.6.%pnpinfo: vendor=0x8086 device=0x1079 subvendor=0x8086
subdevice=0x1179 class=0x02
dev.em.6.%parent: pci3
dev.em.6.debug: -1
dev.em.6.stats: -1
dev.em.6.rx_int_delay: 0
dev.em.6.tx_int_delay: 66
dev.em.6.rx_abs_int_delay: 66
dev.em.6.tx_abs_int_delay: 66
dev.em.6.rx_processing_limit: 100

em6: flags=8843 metric 0 mtu 1500
options=9b
ether 00:04:23:cd:47:82
media: Ethernet autoselect (1000baseT )
status: active

On Tue, Jan 5, 2010 at 6:35 PM, Jason Chambers  wrote:

> Hiroki Sato wrote:
> >  Thank you!  I have investigated some more details.  First, I got
> >  something wrong with the affected FreeBSD versions; one I tried was
> >  8.0-STABLE, not 8.0-RELEASE.  So I started to try 8.0R.  A summary of
> >  chips and releases I tried so far is now the following:
> >
> >   7.2R  8.0R  8.0-STABLE
> >  82540EM (chip=0x100e8086, rev=0x02)  OKOKtoo slow[1]
> >  82541PI (chip=0x107c8086, rev=0x05)  OK? OK
>
>
> Running 8.0R I've noticed the same problem with this card (0x107c8086).
>   Duplex and speed are manually set at full/1000.
>
>
> e...@pci0:3:3:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05
> hdr=0x00
>vendor = 'Intel Corporation'
>device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)'
>class  = network
>subclass   = ethernet
>
>
> Regards,
>
> --Jason
> ___
> 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"
>
___
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: ports/packages management in jail

[Justin Head]

On 1/24/10, Maciej Jan Broniarz  wrote:
> Hi,
>
> I am running a server with several jails. They were created using
> ezjail. What is the best way, to allow jail internal admin to manage
> ports/packages by himself?
> By default ezjail shares ports tree between basejail and otherjails. Is
> there a way for each jail to have a separate ports tree?
>
Inside the jail just rm the symlinked /usr/ports and then recreate
/usr/ports as a regular directory.  After that a simple portsnap to
grab the ports tree.
___
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: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance

[Bob Friesenhahn]

On Mon, 25 Jan 2010, Dan Naumov wrote:


I've checked with the manufacturer and it seems that the Sil3124 in
this NAS is indeed a PCI card. More info on the card in question is
available at http://green-pcs.co.uk/2009/01/28/tranquil-bbs2-those-pci-cards/
I have the card described later on the page, the one with 4 SATA ports
and no eSATA. Alright, so it being PCI is probably a bottleneck in
some ways, but that still doesn't explain the performance THAT bad,
considering that same hardware, same disks, same disk controller push
over 65mb/s in both reads and writes in Win2008. And agian, I am
pretty sure that I've had "close to expected" results when I was


The slow PCI bus and this card look like the bottleneck to me. 
Remember that your Win2008 tests were with just one disk, your zfs 
performance with just one disk was similar to Win2008, and your zfs 
performance with a mirror was just under 1/2 that.


I don't think that your performance results are necessarily out of 
line for the hardware you are using.


On an old Sun SPARC workstation with retrofitted 15K RPM drives on 
Ultra-160 SCSI channel, I see a zfs mirror write performance of 
67,317KB/second and a read performance of 124,347KB/second.  The 
drives themselves are capable of 100MB/second range performance. 
Similar to yourself, I see 1/2 the write performance due to bandwidth 
limitations.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
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: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance

[Alexander Motin]

Dan Naumov wrote:
> On Mon, Jan 25, 2010 at 2:14 AM, Dan Naumov  wrote:
>> On Sun, Jan 24, 2010 at 11:53 PM, Alexander Motin  wrote:
>>> Dan Naumov wrote:
 This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and
 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the
 bonnie results. It also sadly seems to confirm the very slow speed :(
 The disks are attached to a 4-port Sil3124 controller and again, my
 Windows benchmarks showing 65mb/s+ were done on exact same machine,
 with same disks attached to the same controller. Only difference was
 that in Windows the disks weren't in a mirror configuration but were
 tested individually. I do understand that a mirror setup offers
 roughly the same write speed as individual disk, while the read speed
 usually varies from "equal to individual disk speed" to "nearly the
 throughput of both disks combined" depending on the implementation,
 but there is no obvious reason I am seeing why my setup offers both
 read and write speeds roughly 1/3 to 1/2 of what the individual disks
 are capable of. Dmesg shows:

 atapci0:  port 0x1000-0x100f mem
 0x90108000-0x9010807f,0x9010-0x90107fff irq 21 at device 0.0 on
 pci4
 ad8: 1907729MB  at ata4-master SATA300
 ad10: 1907729MB  at ata5-master SATA300
>>> 8.0-RELEASE, and especially 8-STABLE provide alternative, much more
>>> functional driver for this controller, named siis(4). If your SiI3124
>>> card installed into proper bus (PCI-X or PCIe x4/x8), it can be really
>>> fast (up to 1GB/s was measured).
>>>
>>> --
>>> Alexander Motin
>> Sadly, it seems that utilizing the new siis driver doesn't do much good:
>>
>> Before utilizing siis:
>>
>> iozone -s 4096M -r 512 -i0 -i1
>>random
>> randombkwd   record   stride
>>  KB  reclen   write rewritereadrereadread
>> writeread  rewrite read   fwrite frewrite   fread  freread
>> 4194304 512   28796   287665161050695
>>
>> After enabling siis in loader.conf (and ensuring the disks show up as ada):
>>
>> iozone -s 4096M -r 512 -i0 -i1
>>
>>random
>> randombkwd   record   stride
>>  KB  reclen   write rewritereadrereadread
>> writeread  rewrite read   fwrite frewrite   fread  freread
>> 4194304 512   28781   288974721450540
> 
> Just to add to the numbers above, exact same benchmark, on 1 disk
> (detached 2nd disk from the mirror) while using the siis driver:
> 
> random
> randombkwd   record   stride
>   KB  reclen   write rewritereadrereadread
> writeread  rewrite read   fwrite frewrite   fread  freread
>  4194304 512   57760   563716886774047

If both parts of mirror uses same controller, it doubles it's bus
traffic. That may reduce bandwidth twice.

The main benefit of siis(4) is a command queuing. You should receive
more benefits on multithread random I/O.

-- 
Alexander Motin
___
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: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance

[Dan Naumov]

On Mon, Jan 25, 2010 at 7:33 AM, Bob Friesenhahn
 wrote:
> On Mon, 25 Jan 2010, Dan Naumov wrote:
>>
>> I've checked with the manufacturer and it seems that the Sil3124 in
>> this NAS is indeed a PCI card. More info on the card in question is
>> available at
>> http://green-pcs.co.uk/2009/01/28/tranquil-bbs2-those-pci-cards/
>> I have the card described later on the page, the one with 4 SATA ports
>> and no eSATA. Alright, so it being PCI is probably a bottleneck in
>> some ways, but that still doesn't explain the performance THAT bad,
>> considering that same hardware, same disks, same disk controller push
>> over 65mb/s in both reads and writes in Win2008. And agian, I am
>> pretty sure that I've had "close to expected" results when I was
>
> The slow PCI bus and this card look like the bottleneck to me. Remember that
> your Win2008 tests were with just one disk, your zfs performance with just
> one disk was similar to Win2008, and your zfs performance with a mirror was
> just under 1/2 that.
>
> I don't think that your performance results are necessarily out of line for
> the hardware you are using.
>
> On an old Sun SPARC workstation with retrofitted 15K RPM drives on Ultra-160
> SCSI channel, I see a zfs mirror write performance of 67,317KB/second and a
> read performance of 124,347KB/second.  The drives themselves are capable of
> 100MB/second range performance. Similar to yourself, I see 1/2 the write
> performance due to bandwidth limitations.
>
> Bob

There is lots of very sweet irony in my particular situiation.
Initially I was planning to use a single X25-M 80gb SSD in the
motherboard sata port for the actual OS installation as well as to
dedicate 50gb of it to a become a designaed L2ARC vdev for my ZFS
mirrors. The SSD attached to the motherboard port would be recognized
only as a SATA150 device for some reason, but I was still seeing
150mb/s throughput and sub 0.1 ms latencies on that disk simply
because of how crazy good the X25-M's are. However I ended up having
very bad issues with the Icydock 2,5" to 3,5" converter jacket I was
using to keep/fit the SSD in the system and it would randomly drop
write IO on heavy load due to bad connectors. Having finally figured
out the cause of my OS installations to the SSD going belly up during
applying updates, I decided to move the SSD to my desktop and use it
there instead, additionally thinking that my perhaps my idea of the
SSD was crazy overkill for what I need the system to do. Ironically
now that I am seeing how horrible the performance is when I am
operating on the mirror through this PCI card, I realize that
actually, my idea was pretty bloody brilliant, I just didn't really
know why at the time.

An L2ARC device on the motherboard port would really help me with
random read IO, but to work around the utterly poor write performance,
I would also need a dedicaled SLOG ZIL device. The catch is that while
L2ARC devices and be removed from the pool at will (should the device
up and die all of a sudden), the dedicated ZILs cannot and currently a
"missing" ZIL device will render the pool it's included in be unable
to import and become inaccessible. There is some work happening in
Solaris to implement removing SLOGs from a pool, but that work hasn't
yet found it's way in FreeBSD yet.


- Sincerely,
Dan Naumov

- Sincerely,
Dan Naumov
___
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"