Re: csup in repomirror mode dumps core @ stable/8
On Thu, Sep 02, 2010 at 03:59:07AM +0400, Dmitry Morozovsky wrote: Dear colleagues, some 2 days ago my repo mirror (stable/8...@amd64) starts dumping core on copying repo: ... SetAttrs CVSROOT-src/Emptydir Edit CVSROOT-src/access,v Segmentation fault (core dumped) deleting files from sup/cvsroot-all/ did not help unfortunately, quick usual `make -DDEBUG_FLAGS=-g' in /usr/src/usr.bin/csup does not work, and I did not dig into this deeply yet, so trace are without parameters: (gdb) bt #0 0x00410676 in rcsdelta_addlog () #1 0x00412b15 in rcsparse_run () #2 0x00412453 in rcsfile_frompath () #3 0x00417c45 in updater_rcsedit () #4 0x00419a59 in updater_batch () #5 0x0041a1d1 in updater () #6 0x004158c4 in thread_start () #7 0x000800a1c511 in pthread_getprio () from /lib/libthr.so.3 #8 0x in ?? () Cannot access memory at address 0x7f1fa000 I see it here too on both a 7.2 and 8-stable machine. It looks like something in CVSROOT-src/access,v confuse it because moving that file away make the crash go away. I still have the old access,v if somebody is interested. A diff does not show anything wierd that I can see. John -- John Hay -- j...@meraka.csir.co.za / j...@freebsd.org --- /tmp/access,v-csup.crash2010-07-31 16:57:51.0 +0200 +++ /home/freebsd-cvs/CVSROOT-src/access,v 2010-08-30 22:31:11.0 +0200 @@ -1,10 +1,15 @@ -head 1.941; +head 1.942; access; symbols; locks; strict; comment@# @; +1.942 +date 2010.08.30.20.30.48;author rpaulo; state Exp; +branches; +next 1.941; + 1.941 date 2010.07.31.14.57.38;author philip; state Exp; branches; @@ -4715,11 +4720,13 @@ @@ -1.941 +1.942 log -...@svn rev 210685 on 2010-07-31 14:57:38Z by philip +...@svn rev 212009 on 2010-08-30 20:30:48Z by rpaulo -Take cbzimmer's commit bit into safekeeping per his request. +Please welcome Dimitry Andric (dim@@) as a src committer. Dimitry will be +work on Clang for now. +ed@@ is a co-mentor. Approved by: core @ @@ -4789,6 +4796,7 @@ des dfr dg +dim dougb dumbbell dwhite @@ -4972,6 +4980,19 @@ @ +1.941 +log +...@svn rev 210685 on 2010-07-31 14:57:38Z by philip + +Take cbzimmer's commit bit into safekeeping per his request. + +Approved by: core +@ +text +...@d66 1 +@ + + 1.940 log @SVN rev 210462 on 2010-07-25 10:06:56Z by philip ___ 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: csup in repomirror mode dumps core @ stable/8
On Thu, Sep 02, 2010 at 07:56:31AM +0200, John Hay wrote: On Thu, Sep 02, 2010 at 03:59:07AM +0400, Dmitry Morozovsky wrote: Dear colleagues, some 2 days ago my repo mirror (stable/8...@amd64) starts dumping core on copying repo: ... SetAttrs CVSROOT-src/Emptydir Edit CVSROOT-src/access,v Segmentation fault (core dumped) deleting files from sup/cvsroot-all/ did not help unfortunately, quick usual `make -DDEBUG_FLAGS=-g' in /usr/src/usr.bin/csup does not work, and I did not dig into this deeply yet, so trace are without parameters: This won't work. You need to do: make DEBUG_FLAGS=-g3 -ggdb -O0 The important part is not using -D. make.conf variables aren't exported into the compiler environment (I'm not phrasing this eloquently because I don't know how to describe it). The rest of the gcc arguments I provided are highly recommended (especially -O0, otherwise you probably won't get access to any variable data). I can confirm this works, by the way. Look closely at the cc line (past the initial -O2 -pipe -march=nocona). cc -O2 -pipe -march=nocona -I. -I/usr/src/usr.bin/csup/../../contrib/csup -DHAVE_FFLAGS -DNDEBUG -ggdb -g3 -O0 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /usr/src/usr.bin/csup/../../contrib/csup/updater.c -- | 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
NFS and mount_nullfs, kernel panic?
I have a machine which works as a prison for a couple of jails. That particular machine has its /usr/ports, /usr/ports/distfiles, and /usr/ports/packages mounted via NFS from another FreeBSD machine. The machine that crases also nullmounts those filesystems into each jail. I'm not completly sure that this is the reason the machine crashes, but i suspect that is the reason. What can I do to figure it how? What kind of debugging knobs do I need to apply to learn more about the problem? -- chs, ___ 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: csup in repomirror mode dumps core @ stable/8
On Thu, Sep 02, 2010 at 03:59:07AM +0400, Dmitry Morozovsky wrote: Dear colleagues, some 2 days ago my repo mirror (stable/8...@amd64) starts dumping core on copying repo: ... SetAttrs CVSROOT-src/Emptydir Edit CVSROOT-src/access,v Segmentation fault (core dumped) deleting files from sup/cvsroot-all/ did not help unfortunately, quick usual `make -DDEBUG_FLAGS=-g' in /usr/src/usr.bin/csup does not work, and I did not dig into this deeply yet, so trace are without parameters: I think it should be DEBUG_FLAGS=-g and not -D pgpmHR1fWSTWG.pgp Description: PGP signature
Re: 8.1-PRERELEASE: CPU packages not detected correctly
on 01/09/2010 21:26 Jung-uk Kim said the following: On Friday 27 August 2010 03:36 pm, Jung-uk Kim wrote: [3] AMD is working on an SMT-capable CPU (code-named Bulldozer) and my patch won't work on them. If anyone has a Bulldozer sample, please look into it. I checked AMD website today and found out a new CPUID Spec. Rev. 2.34 was just released: http://support.amd.com/us/Embedded_TechDocs/25481.pdf They have added CPUID 0x801d and 0x801e to detect topology, it seems. Also, CPUID 0x8001 %ecx bit 22 (TopologyExtensions) tells you whether the above CPUID functions are supported. Interesting... Yeah, I've heard that they are adding SMT capabilities in Bulldozer processors, so I guess they have to change CPU topology detection indicators. -- Andriy Gapon ___ 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: igb related(?) panics on 7.3-STABLE
On Mon, Aug 30, 2010 at 05:22:47AM -0700, Jeremy Chadwick wrote:
On Mon, Aug 30, 2010 at 04:08:45AM -0700, Jeremy Chadwick wrote:
Bcc:
Subject: Re: igb related(?) panics on 7.3-STABLE
Reply-To:
In-Reply-To: 20100830094631.gd12...@core.byshenk.net
{snip}
My apologies -- somehow my mail client completely broke the Subject line
and pulled it from another thread. I'm not quite sure how mutt managed
to do that, but probably an extraneous newline when editing mail
headers, e.g. PEBKAC.
As an informational followup on this issue, I've updated the problem
machine to 8-STABLE (FreeBSD 8.1-STABLE #7: Mon Aug 23 13:01:15 CEST 2010)
and the problem seems to have gone away.
I had a journal overflow this morning, but that is a different problem,
and I think that it should be fixable via tuning a bit.
--
greg byshenk - gbysh...@byshenk.net - Leiden, NL
___
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: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable.
On Wed, 1 Sep 2010, Ivan Voras wrote: On 09/01/10 15:08, jan.gr...@bristol.ac.uk wrote: I'm running -STABLE with a kde-derived desktop. This setup (which is pretty standard) is providing abysmal interactive performance on an eight-core machine whenever I try to do anything CPU-intensive (such as building a port). Basically, trying to build anything from ports rapidly renders everything else so non-interactive in the eyes of the scheduler that, for instance, switching between virtual desktops (I have six of them in reasonably frequent use) takes about a minute of painful waiting on redraws to complete. Are you sure this is about the scheduler or maybe bad X11 drivers? Not 100%, but mostly convinced; I've just started looking at this. It's my first stab at what might be going on. X11 performance is usually pretty snappy. There's no paging pressure at all. Once I pay attention to any particular window, the scheduler rapidly (like, in 15 agonising seconds or so) decides that the processes associated with that particular window are interactive and performance there picks up again. But it only takes 10 seconds (not timed; ballpark figures) or so of inattention for a window's processes to lapse back into a low-priority state, with the attendant performance problems. windows in X11 have nothing to do with the scheduler (contrary to MS Windows where the OS actually re-nices processes whose windows have focus) - here you are just interacting with a process. Yup, and it does seem that by interacting with the process, things'll start to pick up again - for the processes associated with that window. On the other hand, I have noticed that a 2xQuad-core machine I have access too has more X11 interactivity problems than this single quad-core machine, though again not as serious as yours. I don't know why this is. From the hardware side it might be the shared FSB or from the software side it might be the scheduler. If you want to try something I think it's easier for you to disable one CPU in BIOS or pin X.org and its descendant processes to CPUs of a single socket than to diagnose scheduler problems. but compared to the performance under sched_4bsd, what I'm seeing is an atrocious user experience. It would be best if you could quantify this in some way. I have no idea how. Yeah, I realised that my report was this doesn't work [very well]! which is fairly terrible when it comes to tracking things down; mostly, I was hoping to prompt none, some or lots of same heres to see if the problem was commonly seen. Also (as you're aware) a desktop environment is a complex beast, and putting numbers against look and feel is tricky - however in this situation, I can get numbers from a wall-clock, the behaviour is that pronounced. I'll certainly try getting the whole X tree onto a single socket, to see if that makes any difference. I'll certainly have a stab with your suggestion - thanks Ivan. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Q: What's yellow and equivalent to the axiom of choice? A: Zorn's lemon. ___ 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: GSSAPI (for OpenLDAP) on FreeBSD 8?
Am 01.09.2010 18:33, schrieb Jan Henrik Sylvester: I have got problems with GSSAPI authentication to OpenLDAP: ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) Did you run kinit to obtain tickets? You didn't mention that. ___ 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: csup in repomirror mode dumps core @ stable/8
On Thu, 2 Sep 2010, Kostik Belousov wrote: KB On Thu, Sep 02, 2010 at 03:59:07AM +0400, Dmitry Morozovsky wrote: KB Dear colleagues, KB KB some 2 days ago my repo mirror (stable/8...@amd64) starts dumping core on copying KB repo: KB KB ... KB SetAttrs CVSROOT-src/Emptydir KB Edit CVSROOT-src/access,v KB Segmentation fault (core dumped) KB KB deleting files from sup/cvsroot-all/ did not help KB KB unfortunately, quick usual `make -DDEBUG_FLAGS=-g' in /usr/src/usr.bin/csup KB does not work, and I did not dig into this deeply yet, so trace are without KB parameters: KB I think it should be DEBUG_FLAGS=-g and not -D Yes, surely you're right. BTW, I can confirm moving away access,v file helps avoiding core. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable.
on 02/09/2010 12:08 jan.gr...@bristol.ac.uk said the following: On Wed, 1 Sep 2010, Ivan Voras wrote: On 09/01/10 15:08, jan.gr...@bristol.ac.uk wrote: I'm running -STABLE with a kde-derived desktop. This setup (which is pretty standard) is providing abysmal interactive performance on an eight-core machine whenever I try to do anything CPU-intensive (such as building a port). Basically, trying to build anything from ports rapidly renders everything else so non-interactive in the eyes of the scheduler that, for instance, switching between virtual desktops (I have six of them in reasonably frequent use) takes about a minute of painful waiting on redraws to complete. Are you sure this is about the scheduler or maybe bad X11 drivers? Not 100%, but mostly convinced; I've just started looking at this. It's my first stab at what might be going on. X11 performance is usually pretty snappy. There's no paging pressure at all. From my experience: 1. system with Athlon II X2 250 CPU and onboard AMD graphics - no issues with interaction between buildworld and GUI with all KDE4 effects enabled (OpenGL). 2. system with comparable Core2 Duo CPU and onboard Intel graphics (G33) - enabling OpenGL desktop effects in KDE4 leads to the consequences like what you describe. With all GUI bells and whistles disabled the system behaves quite like the AMD system. -- Andriy Gapon ___ 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: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable.
On Thu, 2 Sep 2010, Andriy Gapon wrote: on 02/09/2010 12:08 jan.gr...@bristol.ac.uk said the following: On Wed, 1 Sep 2010, Ivan Voras wrote: On 09/01/10 15:08, jan.gr...@bristol.ac.uk wrote: I'm running -STABLE with a kde-derived desktop. This setup (which is pretty standard) is providing abysmal interactive performance on an eight-core machine whenever I try to do anything CPU-intensive (such as building a port). Basically, trying to build anything from ports rapidly renders everything else so non-interactive in the eyes of the scheduler that, for instance, switching between virtual desktops (I have six of them in reasonably frequent use) takes about a minute of painful waiting on redraws to complete. Are you sure this is about the scheduler or maybe bad X11 drivers? Not 100%, but mostly convinced; I've just started looking at this. It's my first stab at what might be going on. X11 performance is usually pretty snappy. There's no paging pressure at all. From my experience: 1. system with Athlon II X2 250 CPU and onboard AMD graphics - no issues with interaction between buildworld and GUI with all KDE4 effects enabled (OpenGL). 2. system with comparable Core2 Duo CPU and onboard Intel graphics (G33) - enabling OpenGL desktop effects in KDE4 leads to the consequences like what you describe. With all GUI bells and whistles disabled the system behaves quite like the AMD system. All desktop effects are disabled. The graphics are from an nVidia GeForce 8500 GT (G86) with the X.org driver. (It's not _just_ desktop behaviour that's affected, though: the box runs a number of small headless [interactive] server processes which also appear to get rapidly starved of CPU time.) The behaviour isn't visible with the 4bsd scheduler; stuff generally remains snappy and responsive. I'll keep poking around and see if I can get to the bottom of it. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Rereleasing dolphins into the wild since 1998. ___ 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: GSSAPI (for OpenLDAP) on FreeBSD 8?
On 01/-10/-28163 20:59, Matthias Andree wrote: Am 01.09.2010 18:33, schrieb Jan Henrik Sylvester: I have got problems with GSSAPI authentication to OpenLDAP: ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) Did you run kinit to obtain tickets? You didn't mention that. Yes, I did, and klist shows the tgt and the ldap ticket -- the latter only after the call. You do get a Local error and not Other if you have no ticket. (And the ldap ticket is in /etc/krb5.keytab on the ldap server and owner by ldap.) Thanks, Jan Henrik ___ 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: GSSAPI (for OpenLDAP) on FreeBSD 8?
On Wed, Sep 01, 2010 at 06:33:03PM +0200, Jan Henrik Sylvester wrote: I have got problems with GSSAPI authentication to OpenLDAP: ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) There were at least two discussions, multiple bug reports, and patches about broken GSSAPI on FreeBSD 8, the longest (I found) starting here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057734.html After reading through these discussions, I do not know what the proper fix is -- I would like to change as little as possible introducing SASL authentication to a (production) OpenLDAP server. I have got: An i386 kerberos server, a ldap server in a jail on i386, some amd64 clients -- all running 8.1-RELEASE. Eventually there need to be some Debian/Ubuntu clients using GSSAPI/SASL, too. What do I need to fix? Just the ldap server? Is it enough to change the jail or does the host needs to be patches, too? Or do I need to fix the client, too? The kerberos server? From the discussion, multiple fixes were possible. Patching libgssapi and reinstalling everything depending on it (what?), installing the heimdal-1.0 port (while FreeBSD 8 comes with heimdal-1.1), installing an unofficial heimdal-1.2 port, ... Is that correct? Anything new after the discussion in July? From the discussion, some patches should already be in 8-STABLE, but I could not find the revision (after 8.1-RELEASE). If I upgraded the ldap jail to 8-STABLE, I guess the host needs to be updated, too. Hence I would prefer to just change ports or update single libraries. Does anyone have OpenLDAP+GSSAPI running on FreeBSD 8? With the libgssapi patch? With the heimdal-1.2 port? Can you please try the patch I proposed and see if it improves your situation? Thanks. http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057830.html -- | 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: GSSAPI (for OpenLDAP) on FreeBSD 8?
-- From: Jan Henrik Sylvester m...@janh.de Sent: Wednesday, September 01, 2010 7:33 PM To: stable-list freebsd freebsd-stable@freebsd.org Subject: GSSAPI (for OpenLDAP) on FreeBSD 8? Does anyone have OpenLDAP+GSSAPI running on FreeBSD 8? With the libgssapi patch? With the heimdal-1.2 port? I got running and fully functional Heimdal/GSSAPI setup with Benjamins patch from http://www.freebsd.org/cgi/query-pr.cgi?pr=147454cat=kern, although I didn't test it with LDAP. Jeremys patch as far as I know removes the symptom, but it doesn't fix the cause, which is completely missing heimdal code in the base system preventing the functional operation of heimdal. -Reko ___ 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: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable.
Hello, My machine has a similar behavior. For instance, during intensive workload (portupgrade), everything is quite not-responsive. I made an alias of portupgrade, nice -n 5 portupgrade, that solves the problem just in that particular case. My system is AMD Athlon(tm) 64 Processor 3000+ (1809.28-MHz 686-class CPU) with openGL effects disabled, KDE as desktop environment. There is an interesting mib kern.sched.interact. But I don't know the meaning of it (my value is 30). Cheers, Luca On 09/02/2010 12:46, jan.gr...@bristol.ac.uk wrote: On Thu, 2 Sep 2010, Andriy Gapon wrote: on 02/09/2010 12:08 jan.gr...@bristol.ac.uk said the following: On Wed, 1 Sep 2010, Ivan Voras wrote: On 09/01/10 15:08, jan.gr...@bristol.ac.uk wrote: I'm running -STABLE with a kde-derived desktop. This setup (which is pretty standard) is providing abysmal interactive performance on an eight-core machine whenever I try to do anything CPU-intensive (such as building a port). Basically, trying to build anything from ports rapidly renders everything else so non-interactive in the eyes of the scheduler that, for instance, switching between virtual desktops (I have six of them in reasonably frequent use) takes about a minute of painful waiting on redraws to complete. Are you sure this is about the scheduler or maybe bad X11 drivers? Not 100%, but mostly convinced; I've just started looking at this. It's my first stab at what might be going on. X11 performance is usually pretty snappy. There's no paging pressure at all. From my experience: 1. system with Athlon II X2 250 CPU and onboard AMD graphics - no issues with interaction between buildworld and GUI with all KDE4 effects enabled (OpenGL). 2. system with comparable Core2 Duo CPU and onboard Intel graphics (G33) - enabling OpenGL desktop effects in KDE4 leads to the consequences like what you describe. With all GUI bells and whistles disabled the system behaves quite like the AMD system. All desktop effects are disabled. The graphics are from an nVidia GeForce 8500 GT (G86) with the X.org driver. (It's not _just_ desktop behaviour that's affected, though: the box runs a number of small headless [interactive] server processes which also appear to get rapidly starved of CPU time.) The behaviour isn't visible with the 4bsd scheduler; stuff generally remains snappy and responsive. I'll keep poking around and see if I can get to the bottom of it. -- Mit herzlichen Grüßen, Luca Pizzamiglio Systementwicklung BALLY WULFF Entertainment GmbH Maybachufer 48-51 12045 Berlin Phone: +49(30)62002 149 ___ 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
AMD64 Buildworld error in i386-elf
Source is current as at 0030 on 2nd Sept. and I'm seeing this buildworld error: === gnu/lib/csu (obj,depend,all,install) sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.o /usr/obj/usr/src/lib32/usr/lib32/crtbegin.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.o /usr/obj/usr/src/lib32/usr/lib32/crtend.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbeginT.o /usr/obj/usr/src/lib32/usr/lib32/crtbeginT.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.So /usr/obj/usr/src/lib32/usr/lib32/crtbeginS.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.So /usr/obj/usr/src/lib32/usr/lib32/crtendS.o === lib/csu/i386-elf (obj,depend,all,install) ld -m elf_i386_fbsd -Y P,/usr/obj/usr/src/lib32/usr/lib32 -o gcrt1.o -r crt1_s.o gcrt1_c.o ld: Relocatable linking with relocations from format elf64-x86-64 (gcrt1_c.o) to format elf32-i386-freebsd (gcrt1.o) is not supported *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 /usr/src % uname -a FreeBSD aylee.number6 8.1-STABLE FreeBSD 8.1-STABLE #0: Tue Jul 27 08:48:05 EST 2010 r...@aylee.number6:/usr/obj/usr/src/sys/AYLEE amd64 thanks in advance rob ___ 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
Extending your zfs pool with multiple devices
I have a small problem that I am trying to work out a solution for. Imagine you create a NAS box. Fill a small server with 5 hard drives, zfs them with raidz or whatever, create your pools and then shear this to the network using samba. Simple NAS box for your network to put their files and they just connenct to \\nas1 This box is now full, my problem is that I could create a 2nd NAS box and people use \\nas1 and \\nas2 but it's not very use friendly. Can I somehow build a 2nd box which is identicle, but extend my pools into nas2. I was thinking something like exporting the nas2 drives via iscsi and then nas1 add's the drives to the pool...or something similar. I find that with any NAS whether its home build or shop bought you will eventually run out of space, and sure you can replace the HDD's with bigger ones but you will see run out of space, and having multiple locations, in my mind, is not very elegant. I cannot simply add more HDD's to the box as well as it's at full capacity 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: 8-stable crashes in vmware (possible em driver issue?)
On 02/25/10 01:23, Ivan Voras wrote: Ivan Voras wrote: I have a fairly recent 8-stable machine running under VMWare ESXi 3.5 (amd64 guest), which apparently crashes every few days from the same causes: em0: discard frame w/o packet header em0: discard frame w/o packet header em0: discard frame w/o packet header Panic string: sbsndptr: sockbuf 0xff007cca8c20 and mbuf 0xff00490a6400 clashing In case someone is interested or has an idea - on this machine I have multiple crashed cores with similarily strange problems all connected with networking and/or the em driver: ... It looks like the most probable culprit are stf (6to4) support and/or something dealing with stf routing (the machine was a stf gateway for a small subnet). When disabled, the crashes stop. ___ 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: GSSAPI (for OpenLDAP) on FreeBSD 8?
On 09/02/2010 13:50, Jeremy Chadwick wrote: On Wed, Sep 01, 2010 at 06:33:03PM +0200, Jan Henrik Sylvester wrote: I have got problems with GSSAPI authentication to OpenLDAP: ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) There were at least two discussions, multiple bug reports, and patches about broken GSSAPI on FreeBSD 8, the longest (I found) starting here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057734.html After reading through these discussions, I do not know what the proper fix is -- I would like to change as little as possible introducing SASL authentication to a (production) OpenLDAP server. I have got: An i386 kerberos server, a ldap server in a jail on i386, some amd64 clients -- all running 8.1-RELEASE. Eventually there need to be some Debian/Ubuntu clients using GSSAPI/SASL, too. What do I need to fix? Just the ldap server? Is it enough to change the jail or does the host needs to be patches, too? Or do I need to fix the client, too? The kerberos server? From the discussion, multiple fixes were possible. Patching libgssapi and reinstalling everything depending on it (what?), installing the heimdal-1.0 port (while FreeBSD 8 comes with heimdal-1.1), installing an unofficial heimdal-1.2 port, ... Is that correct? Anything new after the discussion in July? From the discussion, some patches should already be in 8-STABLE, but I could not find the revision (after 8.1-RELEASE). If I upgraded the ldap jail to 8-STABLE, I guess the host needs to be updated, too. Hence I would prefer to just change ports or update single libraries. Does anyone have OpenLDAP+GSSAPI running on FreeBSD 8? With the libgssapi patch? With the heimdal-1.2 port? Can you please try the patch I proposed and see if it improves your situation? Thanks. http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057830.html I had already tried the gss_release_buffer patch. It fixes that crash doing the GSSAPI operation from i386 and brings i386 in par with amd64 -- to the error message I mentioned above. I have also tried the change to /usr/bin/krb5-config before building OpenLDAP -- with no effect, either. I have not tried the big libgssapi patch from kern/147454 as I was hoping to do a smaller change. Cheers, Jan Henrik ___ 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: GSSAPI (for OpenLDAP) on FreeBSD 8?
On 09/02/2010 14:30, Reko Turja wrote: -- From: Jan Henrik Sylvester m...@janh.de Sent: Wednesday, September 01, 2010 7:33 PM To: stable-list freebsd freebsd-stable@freebsd.org Subject: GSSAPI (for OpenLDAP) on FreeBSD 8? Does anyone have OpenLDAP+GSSAPI running on FreeBSD 8? With the libgssapi patch? With the heimdal-1.2 port? I got running and fully functional Heimdal/GSSAPI setup with Benjamins patch from http://www.freebsd.org/cgi/query-pr.cgi?pr=147454cat=kern, although I didn't test it with LDAP. Still my question, do I only have to patch the ldap server or the client doing gssapi ldap queries -- or even the kerberos server? Would a heimdal port be an alternative? Would that only have to be running on the ldap server or the client, too? Sorry, my understanding of gssapi is limited. Thanks, Jan Henrik ___ 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
[releng_8_0 tinderbox] failure on amd64/amd64
TB --- 2010-09-02 13:37:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 13:37:58 - starting RELENG_8_0 tinderbox run for amd64/amd64 TB --- 2010-09-02 13:37:58 - cleaning the object tree TB --- 2010-09-02 13:39:09 - cvsupping the source tree TB --- 2010-09-02 13:39:09 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/amd64/amd64/supfile TB --- 2010-09-02 14:11:01 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:11:01 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:11:01 - 1.06 user 45.49 system 1983.73 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-amd64-amd64.full ___ 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
[releng_8_0 tinderbox] failure on arm/arm
TB --- 2010-09-02 13:37:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 13:37:58 - starting RELENG_8_0 tinderbox run for arm/arm TB --- 2010-09-02 13:37:58 - cleaning the object tree TB --- 2010-09-02 13:38:29 - cvsupping the source tree TB --- 2010-09-02 13:38:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/arm/arm/supfile TB --- 2010-09-02 14:12:31 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:12:31 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:12:31 - 0.60 user 22.95 system 2073.61 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-arm-arm.full ___ 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
[releng_8_0 tinderbox] failure on i386/pc98
TB --- 2010-09-02 13:37:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 13:37:58 - starting RELENG_8_0 tinderbox run for i386/pc98 TB --- 2010-09-02 13:37:58 - cleaning the object tree TB --- 2010-09-02 13:38:57 - cvsupping the source tree TB --- 2010-09-02 13:38:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/i386/pc98/supfile TB --- 2010-09-02 14:13:19 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:13:19 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:13:19 - 1.03 user 39.16 system 2121.23 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-i386-pc98.full ___ 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
[releng_8_0 tinderbox] failure on i386/i386
TB --- 2010-09-02 13:37:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 13:37:58 - starting RELENG_8_0 tinderbox run for i386/i386 TB --- 2010-09-02 13:37:58 - cleaning the object tree TB --- 2010-09-02 13:38:59 - cvsupping the source tree TB --- 2010-09-02 13:38:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/i386/i386/supfile TB --- 2010-09-02 14:17:22 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:17:22 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:17:22 - 1.04 user 40.66 system 2364.02 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-i386-i386.full ___ 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
[releng_8_0 tinderbox] failure on ia64/ia64
TB --- 2010-09-02 14:11:02 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:11:02 - starting RELENG_8_0 tinderbox run for ia64/ia64 TB --- 2010-09-02 14:11:02 - cleaning the object tree TB --- 2010-09-02 14:11:29 - cvsupping the source tree TB --- 2010-09-02 14:11:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/ia64/ia64/supfile TB --- 2010-09-02 14:46:20 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:46:20 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:46:20 - 0.80 user 23.23 system 2117.91 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-ia64-ia64.full ___ 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
[releng_8_0 tinderbox] failure on powerpc/powerpc
TB --- 2010-09-02 14:13:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:13:19 - starting RELENG_8_0 tinderbox run for powerpc/powerpc TB --- 2010-09-02 14:13:19 - cleaning the object tree TB --- 2010-09-02 14:13:47 - cvsupping the source tree TB --- 2010-09-02 14:13:47 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/powerpc/powerpc/supfile TB --- 2010-09-02 14:48:22 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:48:22 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:48:22 - 0.77 user 21.16 system 2102.57 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-powerpc-powerpc.full ___ 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
[releng_8_0 tinderbox] failure on sparc64/sparc64
TB --- 2010-09-02 14:17:22 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:17:22 - starting RELENG_8_0 tinderbox run for sparc64/sparc64 TB --- 2010-09-02 14:17:22 - cleaning the object tree TB --- 2010-09-02 14:17:40 - cvsupping the source tree TB --- 2010-09-02 14:17:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/sparc64/sparc64/supfile TB --- 2010-09-02 14:51:46 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:51:46 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:51:46 - 0.68 user 12.12 system 2064.38 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-sparc64-sparc64.full ___ 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
[releng_8_0 tinderbox] failure on mips/mips
TB --- 2010-09-02 14:12:31 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:12:31 - starting RELENG_8_0 tinderbox run for mips/mips TB --- 2010-09-02 14:12:31 - cleaning the object tree TB --- 2010-09-02 14:12:46 - cvsupping the source tree TB --- 2010-09-02 14:12:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/mips/mips/supfile TB --- 2010-09-02 14:52:22 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:52:22 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:52:22 - 0.55 user 12.10 system 2390.79 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-mips-mips.full ___ 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.1R ZFS almost locking up system
In the last episode (Sep 01), Tim Bishop said: On Tue, Aug 31, 2010 at 10:58:29AM -0500, Dan Nelson wrote: In the last episode (Aug 31), Tim Bishop said: It happened again this Saturday (clearly something in the weekly periodic run is triggering the issue). procstat -kk shows the following for processes doing something zfs related (where zfs related means the string 'zfs' in the procstat -kk output): 0 100084 kernel zfs_vn_rele_task mi_switch+0x16f sleepq_wait+0x42 _sleep+0x31c taskqueue_thread_loop+0xb7 fork_exit+0x118 fork_trampoline+0xe 5 100031 zfskern arc_reclaim_thre mi_switch+0x16f sleepq_timedwait+0x42 _cv_timedwait+0x129 arc_reclaim_thread+0x2d1 fork_exit+0x118 fork_trampoline+0xe 5 100032 zfskern l2arc_feed_threa mi_switch+0x16f sleepq_timedwait+0x42 _cv_timedwait+0x129 l2arc_feed_thread+0x1be fork_exit+0x118 fork_trampoline+0xe 5 100085 zfskern txg_thread_enter mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_thread_wait+0x79 txg_quiesce_thread+0xb5 fork_exit+0x118 fork_trampoline+0xe 5 100086 zfskern txg_thread_enter mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 zio_wait+0x61 dsl_pool_sync+0xea spa_sync+0x355 txg_sync_thread+0x195 fork_exit+0x118 fork_trampoline+0xe 17 100040 syncer -mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c zil_commit+0x416 zfs_sync+0xa6 sync_fsync+0x184 sync_vnode+0x16b sched_sync+0x1c9 fork_exit+0x118 fork_trampoline+0xe 2210 100156 syslogd -mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 3500 100177 syslogd -mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 3783 100056 syslogd -mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 4064 100165 mysqld initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 closef+0x3b kern_close+0x14d syscall+0x1e7 Xfast_syscall+0xe1 4441 100224 python2.6initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 100227 python2.6initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 4445 100228 python2.6initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 4446 100229 python2.6initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 4447 100089 python2.6initial thread mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 5352 100270 mutt -mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c zil_commit+0x416 zfs_freebsd_fsync+0xd7 null_bypass+0xd3 fsync+0x161 syscall+0x1e7 Xfast_syscall+0xe1 52686 100200 tarsnap -mi_switch+0x16f sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc
[releng_8_1 tinderbox] failure on amd64/amd64
TB --- 2010-09-02 14:46:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:46:20 - starting RELENG_8_1 tinderbox run for amd64/amd64 TB --- 2010-09-02 14:46:20 - cleaning the object tree TB --- 2010-09-02 14:46:45 - cvsupping the source tree TB --- 2010-09-02 14:46:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/amd64/amd64/supfile TB --- 2010-09-02 15:21:43 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 15:21:43 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 15:21:43 - 0.80 user 14.66 system 2123.57 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-amd64-amd64.full ___ 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
[releng_8_1 tinderbox] failure on i386/pc98
TB --- 2010-09-02 14:52:22 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:52:22 - starting RELENG_8_1 tinderbox run for i386/pc98 TB --- 2010-09-02 14:52:22 - cleaning the object tree TB --- 2010-09-02 14:52:39 - cvsupping the source tree TB --- 2010-09-02 14:52:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/i386/pc98/supfile TB --- 2010-09-02 15:26:02 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 15:26:02 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 15:26:02 - 0.61 user 8.32 system 2019.98 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-i386-pc98.full ___ 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
[releng_8_1 tinderbox] failure on arm/arm
TB --- 2010-09-02 14:48:22 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:48:22 - starting RELENG_8_1 tinderbox run for arm/arm TB --- 2010-09-02 14:48:22 - cleaning the object tree TB --- 2010-09-02 14:48:28 - cvsupping the source tree TB --- 2010-09-02 14:48:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/arm/arm/supfile TB --- 2010-09-02 15:26:21 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 15:26:21 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 15:26:21 - 0.30 user 4.77 system 2279.44 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-arm-arm.full ___ 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: [releng_8_0 tinderbox] failure on mips/mips
The cvsup server the tinder boxes update from is getting some more disk space installed. It should be able back up in another 45min or so. ---Mike At 10:52 AM 9/2/2010, FreeBSD Tinderbox wrote: TB --- 2010-09-02 14:12:31 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:12:31 - starting RELENG_8_0 tinderbox run for mips/mips TB --- 2010-09-02 14:12:31 - cleaning the object tree TB --- 2010-09-02 14:12:46 - cvsupping the source tree TB --- 2010-09-02 14:12:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/mips/mips/supfile TB --- 2010-09-02 14:52:22 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 14:52:22 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 14:52:22 - 0.55 user 12.10 system 2390.79 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-mips-mips.full ___ 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 Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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
[releng_8_1 tinderbox] failure on i386/i386
TB --- 2010-09-02 14:51:46 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 14:51:46 - starting RELENG_8_1 tinderbox run for i386/i386 TB --- 2010-09-02 14:51:46 - cleaning the object tree TB --- 2010-09-02 14:52:02 - cvsupping the source tree TB --- 2010-09-02 14:52:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/i386/i386/supfile TB --- 2010-09-02 15:28:33 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 15:28:33 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 15:28:33 - 0.56 user 10.76 system 2206.35 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-i386-i386.full ___ 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
[releng_8_1 tinderbox] failure on ia64/ia64
TB --- 2010-09-02 15:21:43 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 15:21:43 - starting RELENG_8_1 tinderbox run for ia64/ia64 TB --- 2010-09-02 15:21:43 - cleaning the object tree TB --- 2010-09-02 15:21:58 - cvsupping the source tree TB --- 2010-09-02 15:21:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/ia64/ia64/supfile TB --- 2010-09-02 15:55:41 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 15:55:41 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 15:55:41 - 0.56 user 9.05 system 2037.13 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-ia64-ia64.full ___ 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
[releng_8_1 tinderbox] failure on powerpc/powerpc
TB --- 2010-09-02 15:26:21 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 15:26:21 - starting RELENG_8_1 tinderbox run for powerpc/powerpc TB --- 2010-09-02 15:26:21 - cleaning the object tree TB --- 2010-09-02 15:26:41 - cvsupping the source tree TB --- 2010-09-02 15:26:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/powerpc/powerpc/supfile TB --- 2010-09-02 16:00:01 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 16:00:01 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 16:00:01 - 0.48 user 9.36 system 2019.63 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-powerpc-powerpc.full ___ 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
[releng_8_1 tinderbox] failure on mips/mips
TB --- 2010-09-02 15:26:03 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 15:26:03 - starting RELENG_8_1 tinderbox run for mips/mips TB --- 2010-09-02 15:26:03 - cleaning the object tree TB --- 2010-09-02 15:26:09 - cvsupping the source tree TB --- 2010-09-02 15:26:09 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/mips/mips/supfile TB --- 2010-09-02 16:03:18 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 16:03:18 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 16:03:18 - 0.30 user 4.59 system 2235.22 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-mips-mips.full ___ 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
[releng_8_1 tinderbox] failure on sparc64/sparc64
TB --- 2010-09-02 15:28:33 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 15:28:33 - starting RELENG_8_1 tinderbox run for sparc64/sparc64 TB --- 2010-09-02 15:28:33 - cleaning the object tree TB --- 2010-09-02 15:28:46 - cvsupping the source tree TB --- 2010-09-02 15:28:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/sparc64/sparc64/supfile TB --- 2010-09-02 16:04:41 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 16:04:41 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 16:04:41 - 0.62 user 8.91 system 2167.56 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-sparc64-sparc64.full ___ 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
[releng_8 tinderbox] failure on amd64/amd64
TB --- 2010-09-02 15:55:41 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 15:55:41 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2010-09-02 15:55:41 - cleaning the object tree TB --- 2010-09-02 15:56:02 - cvsupping the source tree TB --- 2010-09-02 15:56:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/amd64/amd64/supfile TB --- 2010-09-02 16:33:00 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 16:33:00 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 16:33:00 - 0.76 user 10.60 system 2239.22 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full ___ 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
[releng_8 tinderbox] failure on arm/arm
TB --- 2010-09-02 16:00:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 16:00:01 - starting RELENG_8 tinderbox run for arm/arm TB --- 2010-09-02 16:00:01 - cleaning the object tree TB --- 2010-09-02 16:00:08 - cvsupping the source tree TB --- 2010-09-02 16:00:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/arm/arm/supfile TB --- 2010-09-02 16:38:08 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 16:38:08 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 16:38:08 - 0.30 user 4.76 system 2286.32 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-arm-arm.full ___ 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
[releng_8 tinderbox] failure on i386/pc98
TB --- 2010-09-02 16:04:41 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 16:04:41 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2010-09-02 16:04:41 - cleaning the object tree TB --- 2010-09-02 16:04:52 - cvsupping the source tree TB --- 2010-09-02 16:04:52 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2010-09-02 16:40:36 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 16:40:36 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 16:40:36 - 0.62 user 8.16 system 2155.63 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full ___ 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
[releng_8 tinderbox] failure on i386/i386
TB --- 2010-09-02 16:03:18 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 16:03:18 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2010-09-02 16:03:18 - cleaning the object tree TB --- 2010-09-02 16:03:35 - cvsupping the source tree TB --- 2010-09-02 16:03:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2010-09-02 16:42:24 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 16:42:24 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 16:42:24 - 0.55 user 8.98 system 2345.92 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full ___ 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: Extending your zfs pool with multiple devices
You need an HP SAS expander card in the new box, and an HBA in your primary box with external ports to hook it into. Then the drives in the other box will show up as local drives on your primary box. You don't even need an operating system on the second box, it just needs enough hardware in it to supply power to the SAS expander. On Thu, Sep 2, 2010 at 9:22 AM, Michal mic...@sharescope.co.uk wrote: I have a small problem that I am trying to work out a solution for. Imagine you create a NAS box. Fill a small server with 5 hard drives, zfs them with raidz or whatever, create your pools and then shear this to the network using samba. Simple NAS box for your network to put their files and they just connenct to \\nas1 This box is now full, my problem is that I could create a 2nd NAS box and people use \\nas1 and \\nas2 but it's not very use friendly. Can I somehow build a 2nd box which is identicle, but extend my pools into nas2. I was thinking something like exporting the nas2 drives via iscsi and then nas1 add's the drives to the pool...or something similar. I find that with any NAS whether its home build or shop bought you will eventually run out of space, and sure you can replace the HDD's with bigger ones but you will see run out of space, and having multiple locations, in my mind, is not very elegant. I cannot simply add more HDD's to the box as well as it's at full capacity 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 -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.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
[releng_8 tinderbox] failure on ia64/ia64
TB --- 2010-09-02 16:33:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 16:33:00 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2010-09-02 16:33:00 - cleaning the object tree TB --- 2010-09-02 16:33:16 - cvsupping the source tree TB --- 2010-09-02 16:33:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/ia64/ia64/supfile TB --- 2010-09-02 17:05:58 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 17:05:58 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 17:05:58 - 0.58 user 7.76 system 1977.35 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full ___ 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
[releng_8 tinderbox] failure on mips/mips
TB --- 2010-09-02 16:38:08 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 16:38:08 - starting RELENG_8 tinderbox run for mips/mips TB --- 2010-09-02 16:38:08 - cleaning the object tree TB --- 2010-09-02 16:38:15 - cvsupping the source tree TB --- 2010-09-02 16:38:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/mips/mips/supfile TB --- 2010-09-02 17:11:40 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 17:11:40 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 17:11:40 - 0.27 user 4.62 system 2012.45 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full ___ 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
[releng_8 tinderbox] failure on powerpc/powerpc
TB --- 2010-09-02 16:40:37 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 16:40:37 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2010-09-02 16:40:37 - cleaning the object tree TB --- 2010-09-02 16:40:50 - cvsupping the source tree TB --- 2010-09-02 16:40:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2010-09-02 17:16:28 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 17:16:28 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 17:16:28 - 0.48 user 8.31 system 2151.91 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full ___ 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
[releng_8 tinderbox] failure on sparc64/sparc64
TB --- 2010-09-02 16:42:24 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-02 16:42:24 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2010-09-02 16:42:24 - cleaning the object tree TB --- 2010-09-02 16:42:36 - cvsupping the source tree TB --- 2010-09-02 16:42:36 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2010-09-02 17:16:33 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-02 17:16:33 - ERROR: unable to cvsup the source tree TB --- 2010-09-02 17:16:33 - 0.54 user 8.34 system 2049.27 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full ___ 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: AMD64 Buildworld error in i386-elf
On 2010-09-02 14:50, Rob Byrnes wrote: Source is current as at 0030 on 2nd Sept. and I'm seeing this buildworld error: === gnu/lib/csu (obj,depend,all,install) sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.o /usr/obj/usr/src/lib32/usr/lib32/crtbegin.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.o /usr/obj/usr/src/lib32/usr/lib32/crtend.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbeginT.o /usr/obj/usr/src/lib32/usr/lib32/crtbeginT.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.So /usr/obj/usr/src/lib32/usr/lib32/crtbeginS.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.So /usr/obj/usr/src/lib32/usr/lib32/crtendS.o === lib/csu/i386-elf (obj,depend,all,install) ld -m elf_i386_fbsd -Y P,/usr/obj/usr/src/lib32/usr/lib32 -o gcrt1.o -r crt1_s.o gcrt1_c.o ld: Relocatable linking with relocations from format elf64-x86-64 (gcrt1_c.o) to format elf32-i386-freebsd (gcrt1.o) is not supported *** Error code 1 What is the contents of your /etc/make.conf and /etc/src.conf ? ___ 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: Extending your zfs pool with multiple devices
[regarding getting more disks in a machine] On Thu, Sep 2, 2010 at 12:47 PM, Joshua Boyd boy...@jbip.net wrote: You need an HP SAS expander card in the new box, and an HBA in your primary box with external ports to hook it into. Then the drives in the other box will show up as local drives on your primary box. You don't even need an operating system on the second box, it just needs enough hardware in it to supply power to the SAS expander. An inexpensive option are SATA port replicators. Think SATA switch or hub. 1:4 is common and cheap. I have a motherboard with intel ICH10 chipset. It commonly provides 6 ports. This chipset is happy to configure port replicators. Meaning you can put 24 drives on this motherboard. Be warned that many SATA chipsets (even plugin cards) will not work with port replicators... But the ICH10 does and it makes a wonderfully cheap ZFS server. With 1.5T disks, I find that the 4 to 1 multipliers have a small effect on speed. The 4 drives I have on the multipler are saturated at 100% a little bit more than the drives directly connected. Essentially you have 3 gigabit for 4 drives instead of 3 gigabit for 1 drive. The ICH10 motherboard ports can be connected to the back of your system by cables and faceplaces that deliver eSATA connectors. I have my drives in a case that delivers eSATA (or USB). One USB for 4 drives was a dog, but the eSATA conneciton works well. ___ 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: Extending your zfs pool with multiple devices
On Thu, Sep 02, 2010 at 04:56:04PM -0400, Zaphod Beeblebrox wrote:
[regarding getting more disks in a machine]
On Thu, Sep 2, 2010 at 12:47 PM, Joshua Boyd boy...@jbip.net wrote:
You need an HP SAS expander card in the new box, and an HBA in your primary
box with external ports to hook it into.
Then the drives in the other box will show up as local drives on your
primary box.
You don't even need an operating system on the second box, it just needs
enough hardware in it to supply power to the SAS expander.
An inexpensive option are SATA port replicators. Think SATA switch or
hub. 1:4 is common and cheap.
I have a motherboard with intel ICH10 chipset. It commonly provides 6
ports. This chipset is happy to configure port replicators. Meaning
you can put 24 drives on this motherboard.
...
With 1.5T disks, I find that the 4 to 1 multipliers have a small
effect on speed. The 4 drives I have on the multipler are saturated
at 100% a little bit more than the drives directly connected.
Essentially you have 3 gigabit for 4 drives instead of 3 gigabit for 1
drive.
1:4 SATA replicators impose a bottleneck on the overall bandwidth
available between the replicator and the disks attached, as you stated.
Diagram:
ICH10
|||___ (SATA300) Port 0, Disk 0
|| (SATA300) Port 1, Disk 1
|_ (SATA300) Port 2, eSATA Replicator
(SATA300) Port 0, Disk 2
|||_ (SATA300) Port 1, Disk 3
||__ (SATA300) Port 2, Disk 4
|___ (SATA300) Port 3, Disk 5
If Disks 2 through 5 are decent disks (pushing 100MB/sec), essentially
you have 100*4 = 400MB/sec worth of bandwidth being shoved across a
300MB/sec link. That's making the assumption the disks attached are
magnetic and not SSD, and not taking into consideration protocol
overhead.
Given the evolutionary rate of hard disks and SSDs, replicators are (in
my opinion) not a viable solution mid or long-term.
Even Silicon Image's products at this point are starting to force a 1:2
ratio on the replicators, probably to address the bottleneck issue:
http://www.siliconimage.com/products/product.aspx?pid=154
http://www.siliconimage.com/products/product.aspx?pid=155
A better choice is a SATA multilane HBA, which are usually PCIe-based
with a single connector on the back of the HBA which splits out to
multiple disks (usually 4, but sometimes more).
An ideal choice is ane Areca ARC-1300 series SAS-based PCIe x4 multilane
adapters, which provides SATA300 to each individual disk and uses PCIe
x4 (which can handle about 1GByte/sec in each direction, so 2GByte/sec
total)...
http://www.areca.com.tw/products/sasnoneraid.htm
...but there doesn't appear to be driver support for FreeBSD for this
series of controller (arcmsr(4) doesn't mention the ARC-1300 series). I
also don't know what Areca means on their site when they say
BSD/FreeBSD (will be available with 6Gb/s Host Adapter), given that
none of the ARC-1300 series cards are SATA600.
If people are more focused on total number of devices (disks) that are
available, then they should probably be looking at dropping a pretty
penny on a low-end filer. Otherwise, consider replacing the actual hard
disks themselves with drives of a higher capacity.
/soapbox
--
| 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: Extending your zfs pool with multiple devices
On Fri, Sep 3, 2010 at 12:08 AM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Thu, Sep 02, 2010 at 04:56:04PM -0400, Zaphod Beeblebrox wrote: With 1.5T disks, I find that the 4 to 1 multipliers have a small effect on speed. The 4 drives I have on the multipler are saturated at 100% a little bit more than the drives directly connected. Essentially you have 3 gigabit for 4 drives instead of 3 gigabit for 1 drive. 1:4 SATA replicators impose a bottleneck on the overall bandwidth available between the replicator and the disks attached, as you stated. Diagram: ICH10 |||___ (SATA300) Port 0, Disk 0 || (SATA300) Port 1, Disk 1 |_ (SATA300) Port 2, eSATA Replicator (SATA300) Port 0, Disk 2 |||_ (SATA300) Port 1, Disk 3 ||__ (SATA300) Port 2, Disk 4 |___ (SATA300) Port 3, Disk 5 If Disks 2 through 5 are decent disks (pushing 100MB/sec), essentially you have 100*4 = 400MB/sec worth of bandwidth being shoved across a 300MB/sec link. That's making the assumption the disks attached are magnetic and not SSD, and not taking into consideration protocol overhead. A better choice is a SATA multilane HBA, which are usually PCIe-based with a single connector on the back of the HBA which splits out to multiple disks (usually 4, but sometimes more). That's just connector-foo. The cards are still very expensive. Many ZFS loads don't saturate disks ... or don't saturate them consistently. I just built several systems with one port per disk --- and those cards tended towards $100/port. 1:4 replicators are less than $10/port and the six port motherboards don't seem to add any cost (4 or 6 SATA ports seem standard now). My point is: if you're building a database server and speed is all you care about, then one port per disk makes sense. If you are building a pile of disk and you're on a budget, port replicators are a good solution. ___ 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: Extending your zfs pool with multiple devices
geom_gate - ggated(8) Not going to be fast though (sorry for bad reply, mobile gmail sucks) -- O ascii ribbon campaign - stop html mail - www.asciiribbon.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
