From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 7 15:21:53 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C5E51065676 for ; Sun, 7 Sep 2008 15:21:53 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id 193758FC14 for ; Sun, 7 Sep 2008 15:21:53 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id 627AD5C5B; Sun, 7 Sep 2008 11:07:47 -0400 (EDT) Date: Sun, 7 Sep 2008 11:07:47 -0400 From: Wesley Shields To: jT Message-ID: <20080907150747.GB62357@atarininja.org> References: <9f8af95f0809061626q22bc8f60i48fd95b32cef3d04@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9f8af95f0809061626q22bc8f60i48fd95b32cef3d04@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers Subject: Re: 256-byte inode support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2008 15:21:53 -0000 On Sat, Sep 06, 2008 at 07:26:27PM -0400, jT wrote: > hackers, > > since tytso had updated ext3 -- i've noticed that i can't use my > 265-byte inode ext3 drives -- is there any effort to update it? If > not -- if you know where i should attempt to start please let me know > so i can start working on support (i have a few other people i know > interested in this) -- thanks and hope everyone is well There was a PR submitted for it and eventually a patch added to the PR. I've tested the patch given in the URL at the port and it works. We will start to see more of this as the newer version becomes more common in the wild. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124621 Would be nice to see this fixed in 7.1 but it may be too late for that. -- WXS From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 7 19:44:17 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1BED1065677 for ; Sun, 7 Sep 2008 19:44:17 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by mx1.freebsd.org (Postfix) with ESMTP id AF8B38FC08 for ; Sun, 7 Sep 2008 19:44:17 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: (qmail 30042 invoked from network); 7 Sep 2008 19:44:17 -0000 Received: from april.chuckr.org (HELO april.telenix.org) (chuckr@[66.92.151.30]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 7 Sep 2008 19:44:17 -0000 Message-ID: <48C42EC5.9040201@telenix.org> Date: Sun, 07 Sep 2008 15:43:01 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.6 (X11/20071107) MIME-Version: 1.0 To: FreeBSD-Hackers X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: keyboard questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2008 19:44:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have gotten my project, which was to make an Xorg driver for my ultra-cheapy UC-Logic graphic tablet working to a great extent, including scaling the cursor movement both with and without the optional function key areas that rim the tablet area. So, my next job is to figure out how, on FreeBSD, should I configure and dispatch these things. They AREN'T to be limited, at all, to being function keys, I want them even to include the possibility of kicking off programs (or maybe shell scripts?). So, knowing absolutely zero about interfacing keyboards on FreeBSD, could I get a VERY minimal description, enough so that I could begin reading all of the man pages (and include files) involved, and get this last part going? Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjELsUACgkQz62J6PPcoOnOnQCfWE6Sr7x6gaN8C28HO5/a7tOP JCIAn2abiL5Q/whTM+bHCx3E0FWWpHF1 =JDfG -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 8 08:30:59 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 518D7106564A; Mon, 8 Sep 2008 08:30:59 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0CAFA8FC25; Mon, 8 Sep 2008 08:30:58 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 6FFB015D4BE; Mon, 8 Sep 2008 04:14:43 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 08 Sep 2008 04:14:43 -0400 X-Sasl-enc: W6YzLZU8rsIh4fw2lgRJbY1xgUIGE4Lg4w6YWPZ7FYLU 1220861683 Received: from [192.168.1.235] (76-191-150-176.dsl.dynamic.sonic.net [76.191.150.176]) by mail.messagingengine.com (Postfix) with ESMTPSA id D03B83D41A; Mon, 8 Sep 2008 04:14:41 -0400 (EDT) Message-ID: <48C4DEEF.7070201@freebsd.org> Date: Mon, 08 Sep 2008 01:14:39 -0700 From: Darren Reed User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Marius Strobl References: <3c1674c90808211442t707966fq29997b53a70ed2f7@mail.gmail.com> <20080822113317.GD32539@server.vk2pj.dyndns.org> <48AEA699.10903@FreeBSD.org> <20080822201603.GA14444@alchemy.franken.de> In-Reply-To: <20080822201603.GA14444@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sun4v@freebsd.org, freebsd-stable@freebsd.org, Kip Macy , freebsd-hackers@freebsd.org, freebsd-sun4v@freebsd.org, FreeBSD Current Subject: Re: the future of sun4v X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 08:30:59 -0000 Marius Strobl wrote: > On Fri, Aug 22, 2008 at 01:44:25PM +0200, Kris Kennaway wrote: > > Peter Jeremy wrote: > > >[Replies re-directed to freebsd-sun4v] > > > > > >On 2008-Aug-21 14:42:55 -0700, Kip Macy wrote: > > >>I believe that there is a general expectation by freebsd users and > > >>developers that unsupported code should not be in CVS. Although sun4v > > >>is a very interesting platform for developers doing SMP work, I simply > > >>do not have the time or energy to maintain it. If someone else would > > >>like to step up and try his hand I would be supportive of his efforts. > > >>In the likely event that no one steps forward by the time that 7.1 is > > >>released I will ask that it be moved to the Attic. > > > > > >Since there are no other current SPARC CPUs that FreeBSD can run on > > >(the US-II has been obsolete for about 6 years and FreeBSD won't run > > >on any more recent sun4u chips), that will also remove the > > >justification for maintaining a SPARC64 port. > > > > > >I don't have the knowledge or available time to maintain the sun4v > > >port by myself but would be happy to be part of a team doing so. One > > >impediment I have is that I don't have a T-1 or T-2 system that I can > > >dedicate to FreeBSD. I could work on FreeBSD in a guest domain - but > > >since FreeBSD doesn't support either the virtual disk or virtual > > >network, actually getting FreeBSD running there presents somewhat of a > > >challenge. > > > > > > > There are two t1000 systems in the freebsd.org cluster that are > > available for people to work on. Rink Springer has also expressed > > interest in this. > > > > Perhaps Kip can explain some more about what things he looked at, but > > the most serious bugs might be in pmap or perhaps trap handling. > > Operationally, things like buildworld -jN die quickly with random > > signals, kernel traps, etc. > > > > Kris > > > > P.S. It looks like marius has made progress on US III but sun4u is still > > an architectural dead end. > > Well, let's see what architecture the upcoming Rock CPUs are; > judging their feature list they appear to be a continuation of > the Fujitsu sun4u line rather than a successor of UST1/2 :) > That's inaccurate. Rock is meant to be very compatible with sun4v, although I don't know if uname will say "sun4v" or something else...but you will need a bug-free sun4v operating system to run them (which is to say that various bugs in the solaris sun4v support needed to get fixed rather than left...) The critical issue for freebsd (and any operating system for that matter) on rock is how well does the kernel scale to a system with that many concurrent threads? Darren From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 8 11:16:18 2008 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19DB01065675; Mon, 8 Sep 2008 11:16:18 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id C9EC08FC24; Mon, 8 Sep 2008 11:16:17 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 170B12087; Mon, 8 Sep 2008 13:16:17 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 01996844B4; Mon, 8 Sep 2008 13:16:16 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ruslan Ermilov References: <20080904124653.GK72107@obiwan.tataz.chchile.org> <20080904135200.GC31289@alpha.local> <86ljy857zz.fsf@ds4.des.no> <20080904141705.GL72107@obiwan.tataz.chchile.org> <86hc8w55mr.fsf@ds4.des.no> <20080904154138.GM72107@obiwan.tataz.chchile.org> <8663pbzp97.fsf@ds4.des.no> <20080905070028.GN72107@obiwan.tataz.chchile.org> <20080905140204.GA6498@edoofus.dev.vega.ru> Date: Mon, 08 Sep 2008 13:16:16 +0200 In-Reply-To: <20080905140204.GA6498@edoofus.dev.vega.ru> (Ruslan Ermilov's message of "Fri, 5 Sep 2008 18:02:04 +0400") Message-ID: <86r67uevlr.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@FreeBSD.org, Jeremie Le Hen Subject: Re: Creation of the NO_SSP build knob X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 11:16:18 -0000 Ruslan Ermilov writes: > There's no possibility to easily make what you want, i.e., disable > SSP for some parts of the tree. Doing it for particular makefiles > OTOH should be pretty easy, by starting a makefile with the > following two lines: That's not "what Jeremie wants", that's what the Makefiles already do. Parts of the tree *can't* be built with SSP enabled, and the Makefiles set WITHOUT_SSP to disable it. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 8 13:08:33 2008 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E37F8106566C; Mon, 8 Sep 2008 13:08:33 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by mx1.freebsd.org (Postfix) with ESMTP id 9F6938FC1D; Mon, 8 Sep 2008 13:08:33 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp3-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp3-g19.free.fr (Postfix) with ESMTP id 1CA1017B56C; Mon, 8 Sep 2008 15:08:32 +0200 (CEST) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp3-g19.free.fr (Postfix) with ESMTP id D4B9E17B594; Mon, 8 Sep 2008 15:08:31 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 24C7F9B497; Mon, 8 Sep 2008 13:01:00 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 0C8004089; Mon, 8 Sep 2008 15:01:00 +0200 (CEST) Date: Mon, 8 Sep 2008 15:01:00 +0200 From: Jeremie Le Hen To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20080908130059.GA55001@obiwan.tataz.chchile.org> References: <20080904124653.GK72107@obiwan.tataz.chchile.org> <20080904135200.GC31289@alpha.local> <86ljy857zz.fsf@ds4.des.no> <20080904141705.GL72107@obiwan.tataz.chchile.org> <86hc8w55mr.fsf@ds4.des.no> <20080904154138.GM72107@obiwan.tataz.chchile.org> <8663pbzp97.fsf@ds4.des.no> <20080905070028.GN72107@obiwan.tataz.chchile.org> <20080905140204.GA6498@edoofus.dev.vega.ru> <86r67uevlr.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86r67uevlr.fsf@ds4.des.no> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Jeremie Le Hen , Ruslan Ermilov , freebsd-hackers@FreeBSD.org Subject: Creation of the NO_SSP build knob X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 13:08:34 -0000 Hello Dag-Erling, On Mon, Sep 08, 2008 at 01:16:16PM +0200, Dag-Erling Smørgrav wrote: > Ruslan Ermilov writes: > > There's no possibility to easily make what you want, i.e., disable > > SSP for some parts of the tree. Doing it for particular makefiles > > OTOH should be pretty easy, by starting a makefile with the > > following two lines: > > That's not "what Jeremie wants", that's what the Makefiles already do. > Parts of the tree *can't* be built with SSP enabled, and the Makefiles > set WITHOUT_SSP to disable it. That's what the Makefiles already do indeed. Please excuse me if my english wasn't good enough to express it correctly. You are right to say that parts of the tree can't be build with SSP enabled. IMHO, the problem lies in the way it's enforced: using WITH_SSP shouldn't lead to a build error. The patch I sent along my reply to Ruslan corrects this. By the way, I think WITH_*/WITHOUT_* options should be user-only options and shouldn't be used in the source tree. This would avoid this kind of problem. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 8 13:47:23 2008 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 631771065679; Mon, 8 Sep 2008 13:47:23 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id D45808FC14; Mon, 8 Sep 2008 13:47:22 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id m88DlKis074927; Mon, 8 Sep 2008 15:47:20 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id m88DlK8T074926; Mon, 8 Sep 2008 15:47:20 +0200 (CEST) (envelope-from olli) Date: Mon, 8 Sep 2008 15:47:20 +0200 (CEST) Message-Id: <200809081347.m88DlK8T074926@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, koitsu@FreeBSD.ORG In-Reply-To: <20080905143915.GA60002@icarus.home.lan> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 08 Sep 2008 15:47:20 +0200 (CEST) Cc: Subject: Re: Extending find(1) to support -printf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, koitsu@FreeBSD.ORG List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 13:47:23 -0000 Jeremy Chadwick wrote: > On Fri, Sep 05, 2008 at 03:12:53AM -0700, Jeremy Chadwick wrote: > > Also, some folks on #bsdports asked why I was bothering with this in the > > first place: mutt supports backticks to run shell commands inside of > > a muttrc file. See "Building a list of mailboxes on the fly" below: > > > > http://wiki.mutt.org/?ConfigTricks > > > > Note the find ... -printf '%h ' method. I can accomplish (just > > about) the same using `echo $HOME/Maildir/*`, but if I want to > > exclude an entry, I can't use | grep -v, because mutt doesn't support > > pipes within backticks. :-) > > Follow-up: > > mutt's backtick support does in fact respect pipes. My echo|grep -v was > doing exactly what I requested: the grep -v was removing all output of > the echo, since echo returned the results in a space-delimited format, > not one per line. Hence, "mailboxes" was being executed without any > arguments. > > Equally as frustrating, mutt's backtick support will only honour the > first line of input. If a backticked command returns multiple lines, > only the first is read; the rest are ignored. Well, you can convert back and forth between spaces and newlines with tr(1): echo * | tr ' ' '\n' | grep -v whatever | tr '\n' ' ' It's not pretty, but it should work. Note that ls(1) prints one file name per line, so you can simplify the above line like this: ls | grep -v whatever | tr '\n' ' ' By the way, I often use zsh in such cases. It supports "extended globbing", for example, the wildcard expression *~*.(gz|bz2) matches all files _except_ the ones that end with .gz or .bz2. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl is worse than Python because people wanted it worse. -- Larry Wall From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 8 15:49:36 2008 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A5C910656EB for ; Mon, 8 Sep 2008 15:49:36 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1A9C08FC2B for ; Mon, 8 Sep 2008 15:49:35 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id m88FnVmI080210; Mon, 8 Sep 2008 17:49:32 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id m88FnTX9080209; Mon, 8 Sep 2008 17:49:29 +0200 (CEST) (envelope-from olli) Date: Mon, 8 Sep 2008 17:49:29 +0200 (CEST) Message-Id: <200809081549.m88FnTX9080209@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, jpiccari@bblocked.org In-Reply-To: <15d3bc360809051940t70f0b884mb9a80132acc50b45@mail.gmail.com> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 08 Sep 2008 17:49:32 +0200 (CEST) Cc: Subject: Re: Temp files in /etc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, jpiccari@bblocked.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 15:49:36 -0000 Joshua Piccari wrote: > I am setting up a few jails and I want them all to use the same /etc files > (with the exception of the files related to the password files and > databases), so I mounted a shared /etc folder as a nullfs with read-only > permissions. The problem is that using utilities like pw or chpass create > temporary files in /etc and that file system is mounted read-only. > So is there a way to force any utilities that create temp files in /etc to > use another location, something like /usr/local/etc for example? I had exactly the same problem. I wrote a small patch that solves it: http://www.secnetix.de/olli/FreeBSD/jail-passwd/ Please read the "instructions.txt" file first, then download the appropriate patch file. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd With Perl you can manipulate text, interact with programs, talk over networks, drive Web pages, perform arbitrary precision arithmetic, and write programs that look like Snoopy swearing. From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 8 17:55:54 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D0C3106566B; Mon, 8 Sep 2008 17:55:54 +0000 (UTC) (envelope-from danm@prime.gushi.org) Received: from prime.gushi.org (prime.gushi.org [72.9.101.130]) by mx1.freebsd.org (Postfix) with ESMTP id 2EF728FC13; Mon, 8 Sep 2008 17:55:53 +0000 (UTC) (envelope-from danm@prime.gushi.org) Received: from prime.gushi.org (localhost [127.0.0.1]) by prime.gushi.org (8.14.1/8.14.1) with ESMTP id m88HS5tH090981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Sep 2008 13:28:11 -0400 (EDT) (envelope-from danm@prime.gushi.org) X-DKIM: Sendmail DKIM Filter v2.7.2 prime.gushi.org m88HS5tH090981 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=prime.gushi.org; s=primegushiorg; t=1220877424; bh=COAKehMcyCDURsP/uRejHTxmDz8yiPNEM u5lzAsLYD4=; h=Date:From:To:Subject:Message-ID:MIME-Version: Content-Type; b=kDpyEHc2/RPiWVKT7RS5BWNlrv6JAwS70woOx1wWUfuP65mb8I sv3CjZShNb7JhV6zXh5avOV6pc/Uz0uefiCQ== X-DomainKeys: Sendmail DomainKeys Filter v1.0.0 prime.gushi.org m88HS5tH090981 DomainKey-Signature: a=rsa-sha1; s=primegushiorg; d=prime.gushi.org; c=nofws; q=dns; h=received:date:from:to:subject:message-id:user-agent: mime-version:content-type; b=lrxFPzl/pFhIOqcY6HcRzIz+xDICPgCawK1oqAbtMfNqxOXYghjc0g6zZIo1/rPEH orWs7STvaCBXVx846DveQ== Received: (from danm@localhost) by prime.gushi.org (8.14.1/8.13.8/Submit) id m88HRxMa090855; Mon, 8 Sep 2008 13:27:59 -0400 (EDT) (envelope-from danm) Date: Mon, 8 Sep 2008 13:27:59 -0400 (EDT) From: "Dan Mahoney, System Admin" To: hackers@freebsd.org, questions@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (prime.gushi.org [127.0.0.1]); Mon, 08 Sep 2008 12:37:04 +0000 (UTC) X-Mailman-Approved-At: Mon, 08 Sep 2008 18:13:48 +0000 Cc: Subject: IPFW uid logging... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 17:55:54 -0000 Hey all, I have the following rule set up in ipfw to limit the exposure of bad php scripts and trojans that try to send mail directly. allow tcp from any to any dst-port 25 uid root deny log tcp from any to any dst-port 25 out However, the log messages I get look like this: Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 Sep 8 13:21:16 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 202.12.31.144:25 out via em0 Sep 8 13:21:16 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58131 209.85.133.27:25 out via em0 Sep 8 13:21:28 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 Sep 8 13:21:32 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58131 209.85.133.27:25 out via em0 Sep 8 13:22:45 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:65313 64.202.166.12:25 out via em0 Sep 8 13:22:45 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:65313 64.202.166.12:25 out via em0 Sep 8 13:22:46 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:65313 64.202.166.12:25 out via em0 Sep 8 13:22:49 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:65313 64.202.166.12:25 out via em0 Which is to say, they don't include the UID -- and I have several hundred sites, each with its own UID. Yes, I could go ahead and set up a thousand "deny" rules, one for each UID -- but being able to log this info (since it IS being checked) would be great. Thoughts? -Dan Mahoney -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 8 19:41:50 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BEC4106564A for ; Mon, 8 Sep 2008 19:41:50 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id C84B98FC14 for ; Mon, 8 Sep 2008 19:41:49 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id m88JBoio031315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 8 Sep 2008 14:11:50 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.2/Submit) id m88Ip7LT079705; Mon, 8 Sep 2008 13:51:07 -0500 (CDT) (envelope-from dan) Date: Mon, 8 Sep 2008 13:51:06 -0500 From: Dan Nelson To: "Dan Mahoney, System Admin" Message-ID: <20080908185106.GB6629@dan.emsphone.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 7.0-STABLE User-Agent: Mutt/1.5.18 (2008-05-17) Cc: hackers@freebsd.org, questions@freebsd.org Subject: Re: IPFW uid logging... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 19:41:50 -0000 In the last episode (Sep 08), Dan Mahoney, System Admin said: > I have the following rule set up in ipfw to limit the exposure of bad > php scripts and trojans that try to send mail directly. > > allow tcp from any to any dst-port 25 uid root > deny log tcp from any to any dst-port 25 out > > However, the log messages I get look like this: > > Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 > Sep 8 13:21:16 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 202.12.31.144:25 out via em0 > > Which is to say, they don't include the UID -- and I have several hundred > sites, each with its own UID. > > Yes, I could go ahead and set up a thousand "deny" rules, one for > each UID -- but being able to log this info (since it IS being > checked) would be great. It should be possible to add a couple more arguments to ipfw_log() so that ipfw_chk() can pass it the ugid_lookup flag and a pointer to the fw_ugid_cache struct. Then you can edit ipfw_log to print the contents of that struct if ugid_lookup==1. That would result in the logging of uid for any failed packet that had to go through a uid check on the way to the deny rule. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 8 19:55:01 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FD0F1065674; Mon, 8 Sep 2008 19:55:01 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id 215AA8FC17; Mon, 8 Sep 2008 19:55:00 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m88JswBH022437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Sep 2008 05:54:59 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m88JsvvH012991; Tue, 9 Sep 2008 05:54:57 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m88JsvNh012990; Tue, 9 Sep 2008 05:54:57 +1000 (EST) (envelope-from peter) Date: Tue, 9 Sep 2008 05:54:57 +1000 From: Peter Jeremy To: Darren Reed Message-ID: <20080908195457.GD15376@server.vk2pj.dyndns.org> References: <3c1674c90808211442t707966fq29997b53a70ed2f7@mail.gmail.com> <20080822113317.GD32539@server.vk2pj.dyndns.org> <48AEA699.10903@FreeBSD.org> <20080822201603.GA14444@alchemy.franken.de> <48C4DEEF.7070201@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5LiOUhUlsRX0HDkW" Content-Disposition: inline In-Reply-To: <48C4DEEF.7070201@freebsd.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org, Kip Macy , freebsd-sun4v@freebsd.org Subject: Re: the future of sun4v X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 19:55:01 -0000 --5LiOUhUlsRX0HDkW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [cc list trimmed] On 2008-Sep-08 01:14:39 -0700, Darren Reed wrote: >The critical issue for freebsd (and any operating system for >that matter) on rock is how well does the kernel scale to a >system with that many concurrent threads? Right now it doesn't. And based on some previous threads, there is a lot of redesign to do before it can. But stability needs to come before scalability. There's no point in FreeBSD pretending it can support some arbitrary number of CPUs when it panics due to races in one of the CPU subsystems - which is my understanding of the current sun4v state. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --5LiOUhUlsRX0HDkW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjFgxEACgkQ/opHv/APuIfMpACgvrMTawiIxmUTlZpHyobVSSCB MhYAoIoMncY72LEhXX3BCPuJmyxsP7lF =K28Y -----END PGP SIGNATURE----- --5LiOUhUlsRX0HDkW-- From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 8 20:04:01 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA0F4106566C; Mon, 8 Sep 2008 20:04:01 +0000 (UTC) (envelope-from danm@prime.gushi.org) Received: from prime.gushi.org (prime.gushi.org [72.9.101.130]) by mx1.freebsd.org (Postfix) with ESMTP id 02C0C8FC0A; Mon, 8 Sep 2008 20:04:00 +0000 (UTC) (envelope-from danm@prime.gushi.org) Received: from prime.gushi.org (localhost [127.0.0.1]) by prime.gushi.org (8.14.1/8.14.1) with ESMTP id m88K3VXK010707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Sep 2008 16:03:40 -0400 (EDT) (envelope-from danm@prime.gushi.org) X-DKIM: Sendmail DKIM Filter v2.7.2 prime.gushi.org m88K3VXK010707 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=prime.gushi.org; s=primegushiorg; t=1220886765; bh=6m3esLtDj8Vobpe0WsCx6ze73I62g+3j4 m/sgkuM+O8=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID: References:MIME-Version:Content-Type; b=JhFPpDAuyjkypM6yVUXiW18bP/ E2GOUZvVSvL1jZT3WTOd2mxCWiKSynHcPf0mm0/NHUFBYRM7QC9a9eNHKb+A== X-DomainKeys: Sendmail DomainKeys Filter v1.0.0 prime.gushi.org m88K3VXK010707 DomainKey-Signature: a=rsa-sha1; s=primegushiorg; d=prime.gushi.org; c=nofws; q=dns; h=received:date:from:to:cc:subject:in-reply-to:message-id: references:user-agent:mime-version:content-type; b=SMLhxfT5E36iNipxb69A5FyBhtA9fET+JaqSPRRDrr0KXdMYqyVIxutuKI2JxkboC BGzc6LzsSd91MIb3izRYw== Received: (from danm@localhost) by prime.gushi.org (8.14.1/8.13.8/Submit) id m88K3TbV010683; Mon, 8 Sep 2008 16:03:29 -0400 (EDT) (envelope-from danm) Date: Mon, 8 Sep 2008 16:03:29 -0400 (EDT) From: "Dan Mahoney, System Admin" To: Dan Nelson In-Reply-To: <20080908185106.GB6629@dan.emsphone.com> Message-ID: References: <20080908185106.GB6629@dan.emsphone.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (prime.gushi.org [127.0.0.1]); Mon, 08 Sep 2008 15:12:45 +0000 (UTC) X-Mailman-Approved-At: Mon, 08 Sep 2008 20:17:00 +0000 Cc: hackers@freebsd.org, questions@freebsd.org Subject: Re: IPFW uid logging... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 20:04:01 -0000 On Mon, 8 Sep 2008, Dan Nelson wrote: > In the last episode (Sep 08), Dan Mahoney, System Admin said: >> I have the following rule set up in ipfw to limit the exposure of bad >> php scripts and trojans that try to send mail directly. >> >> allow tcp from any to any dst-port 25 uid root >> deny log tcp from any to any dst-port 25 out >> >> However, the log messages I get look like this: >> >> Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 >> Sep 8 13:21:16 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 202.12.31.144:25 out via em0 >> >> Which is to say, they don't include the UID -- and I have several hundred >> sites, each with its own UID. >> >> Yes, I could go ahead and set up a thousand "deny" rules, one for >> each UID -- but being able to log this info (since it IS being >> checked) would be great. > > It should be possible to add a couple more arguments to ipfw_log() so > that ipfw_chk() can pass it the ugid_lookup flag and a pointer to the > fw_ugid_cache struct. Then you can edit ipfw_log to print the contents > of that struct if ugid_lookup==1. That would result in the logging of > uid for any failed packet that had to go through a uid check on the way > to the deny rule. Okay, so if it's fairly easy to do, the question would be "since I don't feel right hacking in this change myself -- how could I propose this as a feature?" It's not a BUG per-se, but I think it could be useful to others as well. -Dan -- Pika Pika Pika! -Pikachu, of Pokemon fame. --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 8 21:23:52 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2223A106567E for ; Mon, 8 Sep 2008 21:23:52 +0000 (UTC) (envelope-from gballet@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id CDD888FC21 for ; Mon, 8 Sep 2008 21:23:51 +0000 (UTC) (envelope-from gballet@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so945123yxb.13 for ; Mon, 08 Sep 2008 14:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=v2cUPpINgUJmYrsfSFKmcRa0ztUrsXALk0otgXIc7Qg=; b=aQ0cirVgVSSwEHuT+oYCO788bOHKAY5ewfLaEtdOueBOuLEA8FHX7ONsqFgZ/ahZgN 1r+dG4C4gtRQx4eyOn8PK1GDPulFEG6r3r/CUjWYmZ9dxw7A0A0P5RfHgnDkKnXptvE2 S5UT606DFRaqbL+mZpbedWRS7F3TQdPRRnXSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=XEoVvkpUzvzB7Tv6js2MtFB1ZFOEOf20qyXJCoKR4xySFVvZ5cb7oshMz8PRyt3sla djaxe7uYQxlT6Hz2+BTaUA1cS+6bqPTJykDVJW3zE9e5LJASHuMPQURymsoGvBYhq7oB I2U74BhpdbQ5fsnzLuGETFcID7+mOnocwLm+o= Received: by 10.187.202.7 with SMTP id e7mr2968304faq.8.1220909029543; Mon, 08 Sep 2008 14:23:49 -0700 (PDT) Received: by 10.187.209.12 with HTTP; Mon, 8 Sep 2008 14:23:49 -0700 (PDT) Message-ID: Date: Mon, 8 Sep 2008 21:23:49 +0000 From: "Guillaume Ballet" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [PATCH] Extending the ddb command set X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 21:23:52 -0000 Hello hackers, I sent a patch some time ago, allowing modules to extend the ddb command set. I just realized the link I provided then was in French so that might have discouraged people from going any further. I have therefore posted it here. Also, since I would like this patch to be committed at some point, I have written a man page that I also enclosed. Comments are welcome. The man page: .Dd August 27, 2008 .Dt DB_COMMAND 9 .Os .Sh NAME .Nm DB_COMMAND , .Nm DB_SHOW_COMMAND , .Nm DB_SHOW_ALL_COMMAND .Nd Extends the ddb command set. .Sh SYNOPSIS .In ddb/ddb.h .Fo DB_COMMAND .Fa command_name .Fa command_function .Fc .Fn DB_SHOW_COMMAND "command_name" "command_function" .Fn DB_SHOW_ALL_COMMAND "command_name" "command_function" .Sh DESCRIPTION .Pp The .Fn DB_COMMAND macro adds .Fa command_name to the list of top-level commands. Invoking .Fa command_name from ddb will call .Fa command_function . .Pp The .Fn DB_SHOW_COMMAND and .Fn DB_SHOW_ALL_COMMAND are roughly equivalent to .Fn DB_COMMAND but in these cases, .Fa command_name is a sub-command of the ddb .Sy show command and .Sy show all command, respectively. .Pp The general command syntax: .Cm command Ns Op Li \&/ Ns Ar modifier .Ar address Ns Op Li , Ns Ar count , translates into the following parameters for .Fa command_function : .Bl -tag .It Fa addr The address passed to the command as an argument. .It Fa have_addr A boolean value that is true if the addr field is valid. .It Fa count The number of quad words starting at offset .Fa addr that the command must process. .It Fa modif A pointer to the string of modifiers. That is, a series of symbols used to pass some options to the command. For example, the .Sy examine command will display words in decimal form if it is passed the modifier "d". .El .Sh EXAMPLE In your module, the command is declared as: .Pp .Bd -literal DB_COMMAND(mycmd, my_cmd_func) { if (have_addr) db_printf("Calling my command with address %p\\n", addr); } .Ed .Pp Then, when in ddb: .Pp .Bd -literal .Bf Sy db> mycmd 0x1000 Calling my command with address 0x1000 db> .Ef .Ed .Sh "SEE ALSO" .Xr ddb 4 .Sh AUTHOR This manual page was written by .An Guillaume Ballet Aq gballet@gmail.com . And the patch: --- ./ddb/db_command.c.orig 2008-08-19 00:56:41.000000000 +0200 +++ ./ddb/db_command.c 2008-08-24 20:59:41.000000000 +0200 @@ -45,6 +45,7 @@ #include #include #include +#include #include #include @@ -76,78 +77,68 @@ static db_cmdfcn_t db_watchdog; /* + * Array containing all command 'tables'. See ddb.h. + */ +static struct command_table db_command_tables[DB_COMMAND_TABLES_SIZE] = { + STAILQ_HEAD_INITIALIZER(db_command_tables[DB_COMMAND_TABLES_DEFAULT]), + STAILQ_HEAD_INITIALIZER(db_command_tables[DB_COMMAND_TABLES_SHOW]), + STAILQ_HEAD_INITIALIZER(db_command_tables[DB_COMMAND_TABLES_SHOW_ALL]) +}; + +/* * 'show' commands */ static struct command db_show_all_cmds[] = { - { "procs", db_ps, 0, 0 }, - { (char *)0 } -}; - -static struct command_table db_show_all_table = { - db_show_all_cmds + { { NULL }, "procs", db_ps, 0, 0 } }; static struct command db_show_cmds[] = { - { "all", 0, 0, &db_show_all_table }, - { "registers", db_show_regs, 0, 0 }, - { "breaks", db_listbreak_cmd, 0, 0 }, - { "threads", db_show_threads, 0, 0 }, - { (char *)0, } + { { NULL }, "all", 0, 0, &db_command_tables[DB_COMMAND_TABLES_SHOW_ALL] }, + { { NULL }, "registers", db_show_regs, 0, 0 }, + { { NULL }, "breaks", db_listbreak_cmd, 0, 0 }, + { { NULL }, "threads", db_show_threads, 0, 0 } }; -static struct command_table db_show_table = { - db_show_cmds, - SET_BEGIN(db_show_cmd_set), - SET_LIMIT(db_show_cmd_set) -}; - static struct command db_commands[] = { - { "print", db_print_cmd, 0, 0 }, - { "p", db_print_cmd, 0, 0 }, - { "examine", db_examine_cmd, CS_SET_DOT, 0 }, - { "x", db_examine_cmd, CS_SET_DOT, 0 }, - { "search", db_search_cmd, CS_OWN|CS_SET_DOT, 0 }, - { "set", db_set_cmd, CS_OWN, 0 }, - { "write", db_write_cmd, CS_MORE|CS_SET_DOT, 0 }, - { "w", db_write_cmd, CS_MORE|CS_SET_DOT, 0 }, - { "delete", db_delete_cmd, 0, 0 }, - { "d", db_delete_cmd, 0, 0 }, - { "break", db_breakpoint_cmd, 0, 0 }, - { "b", db_breakpoint_cmd, 0, 0 }, - { "dwatch", db_deletewatch_cmd, 0, 0 }, - { "watch", db_watchpoint_cmd, CS_MORE,0 }, - { "dhwatch", db_deletehwatch_cmd, 0, 0 }, - { "hwatch", db_hwatchpoint_cmd, 0, 0 }, - { "step", db_single_step_cmd, 0, 0 }, - { "s", db_single_step_cmd, 0, 0 }, - { "continue", db_continue_cmd, 0, 0 }, - { "c", db_continue_cmd, 0, 0 }, - { "until", db_trace_until_call_cmd,0, 0 }, - { "next", db_trace_until_matching_cmd,0, 0 }, - { "match", db_trace_until_matching_cmd,0, 0 }, - { "trace", db_stack_trace, CS_OWN, 0 }, - { "t", db_stack_trace, CS_OWN, 0 }, - { "alltrace", db_stack_trace_all, 0, 0 }, - { "where", db_stack_trace, CS_OWN, 0 }, - { "bt", db_stack_trace, CS_OWN, 0 }, - { "call", db_fncall, CS_OWN, 0 }, - { "show", 0, 0, &db_show_table }, - { "ps", db_ps, 0, 0 }, - { "gdb", db_gdb, 0, 0 }, - { "halt", db_halt, 0, 0 }, - { "reboot", db_reset, 0, 0 }, - { "reset", db_reset, 0, 0 }, - { "kill", db_kill, CS_OWN, 0 }, - { "watchdog", db_watchdog, 0, 0 }, - { "thread", db_set_thread, CS_OWN, 0 }, - { (char *)0, } -}; - -static struct command_table db_command_table = { - db_commands, - SET_BEGIN(db_cmd_set), - SET_LIMIT(db_cmd_set) + { { NULL }, "print", db_print_cmd, 0, 0 }, + { { NULL }, "p", db_print_cmd, 0, 0 }, + { { NULL }, "examine", db_examine_cmd, CS_SET_DOT, 0 }, + { { NULL }, "x", db_examine_cmd, CS_SET_DOT, 0 }, + { { NULL }, "search", db_search_cmd, CS_OWN|CS_SET_DOT, 0 }, + { { NULL }, "set", db_set_cmd, CS_OWN, 0 }, + { { NULL }, "write", db_write_cmd, CS_MORE|CS_SET_DOT, 0 }, + { { NULL }, "w", db_write_cmd, CS_MORE|CS_SET_DOT, 0 }, + { { NULL }, "delete", db_delete_cmd, 0, 0 }, + { { NULL }, "d", db_delete_cmd, 0, 0 }, + { { NULL }, "break", db_breakpoint_cmd, 0, 0 }, + { { NULL }, "b", db_breakpoint_cmd, 0, 0 }, + { { NULL }, "dwatch", db_deletewatch_cmd, 0, 0 }, + { { NULL }, "watch", db_watchpoint_cmd, CS_MORE,0 }, + { { NULL }, "dhwatch", db_deletehwatch_cmd, 0, 0 }, + { { NULL }, "hwatch", db_hwatchpoint_cmd, 0, 0 }, + { { NULL }, "step", db_single_step_cmd, 0, 0 }, + { { NULL }, "s", db_single_step_cmd, 0, 0 }, + { { NULL }, "continue", db_continue_cmd, 0, 0 }, + { { NULL }, "c", db_continue_cmd, 0, 0 }, + { { NULL }, "until", db_trace_until_call_cmd,0, 0 }, + { { NULL }, "next", db_trace_until_matching_cmd,0, 0 }, + { { NULL }, "match", db_trace_until_matching_cmd,0, 0 }, + { { NULL }, "trace", db_stack_trace, CS_OWN, 0 }, + { { NULL }, "t", db_stack_trace, CS_OWN, 0 }, + { { NULL }, "alltrace", db_stack_trace_all, 0, 0 }, + { { NULL }, "where", db_stack_trace, CS_OWN, 0 }, + { { NULL }, "bt", db_stack_trace, CS_OWN, 0 }, + { { NULL }, "call", db_fncall, CS_OWN, 0 }, + { { NULL }, "show", 0, 0, &db_command_tables[DB_COMMAND_TABLES_SHOW] }, + { { NULL }, "ps", db_ps, 0, 0 }, + { { NULL }, "gdb", db_gdb, 0, 0 }, + { { NULL }, "halt", db_halt, 0, 0 }, + { { NULL }, "reboot", db_reset, 0, 0 }, + { { NULL }, "reset", db_reset, 0, 0 }, + { { NULL }, "kill", db_kill, CS_OWN, 0 }, + { { NULL }, "watchdog", db_watchdog, 0, 0 }, + { { NULL }, "thread", db_set_thread, CS_OWN, 0 } }; static struct command *db_last_command = 0; @@ -189,6 +180,73 @@ struct command_table *cmd_table); /* + * Initialize command tables using the commands declared above. + */ +void +db_cmd_init() +{ + int cnt; + + for (cnt=0; cnt<(sizeof(db_commands) / sizeof(struct command)); cnt++) + STAILQ_INSERT_TAIL(&db_command_tables[DB_COMMAND_TABLES_DEFAULT], + &(db_commands[cnt]), + next); + for (cnt=0; cnt<(sizeof(db_show_cmds) / sizeof(struct command)); cnt++) + STAILQ_INSERT_TAIL(&db_command_tables[DB_COMMAND_TABLES_SHOW], + &(db_show_cmds[cnt]), + next); + for (cnt=0; cnt<(sizeof(db_show_all_cmds) / sizeof(struct command)); cnt++) + STAILQ_INSERT_TAIL(&db_command_tables[DB_COMMAND_TABLES_SHOW_ALL], + &(db_show_all_cmds[cnt]), + next); +} + +/* + * Called by modules through SYSINIT to extend the command set. + */ +void db_command_register(list_index, cmd) + int list_index; + struct command *cmd; +{ + if (list_index >= DB_COMMAND_TABLES_SIZE) + panic("Attempting to add a debugger command to an invalid list!"); + +#if 0 + /* Check that the command is not already present. */ + struct command *scmd; + STAILQ_FOREACH(scmd, &(db_command_tables[list_index]), next) { + if (!strcmp(cmd->name, scmd->name)) + panic("The command %s already exists!", cmd->name); + } +#endif + + if (cmd != NULL) { + STAILQ_INSERT_TAIL(&(db_command_tables[list_index]), + cmd, next); + } +} + +/* + * Called by SYSUNINIT. Revert what has been done above. + */ +void db_command_unregister(table_index, command_name) + int table_index; + char *command_name; +{ + struct command *cmd; + + STAILQ_FOREACH(cmd, &(db_command_tables[table_index]), next) { + if (!strcmp(command_name,cmd->name)) { + STAILQ_REMOVE(&(db_command_tables[table_index]), + cmd, + command, + next); + break; + } + } +} + +/* * Helper function to match a single command. */ static void @@ -236,23 +294,15 @@ struct command_table *table; struct command **cmdp; /* out */ { - struct command *cmd; - struct command **aux_cmdp; - int result = CMD_NONE; + struct command *cmd; + int result = CMD_NONE; - for (cmd = table->table; cmd->name != 0; cmd++) { - db_cmd_match(name, cmd, cmdp, &result); + STAILQ_FOREACH(cmd,table,next) { + db_cmd_match(name,cmd,cmdp,&result); if (result == CMD_UNIQUE) - return (CMD_UNIQUE); + break; } - if (table->aux_tablep != NULL) - for (aux_cmdp = table->aux_tablep; - aux_cmdp < table->aux_tablep_end; - aux_cmdp++) { - db_cmd_match(name, *aux_cmdp, cmdp, &result); - if (result == CMD_UNIQUE) - return (CMD_UNIQUE); - } + if (result == CMD_NONE) { /* check for 'help' */ if (name[0] == 'h' && name[1] == 'e' @@ -266,19 +316,11 @@ db_cmd_list(table) struct command_table *table; { - register struct command *cmd; - register struct command **aux_cmdp; + register struct command *cmd; - for (cmd = table->table; cmd->name != 0; cmd++) { - db_printf("%-12s", cmd->name); - db_end_line(12); - } - if (table->aux_tablep == NULL) - return; - for (aux_cmdp = table->aux_tablep; aux_cmdp < table->aux_tablep_end; - aux_cmdp++) { - db_printf("%-12s", (*aux_cmdp)->name); - db_end_line(12); + STAILQ_FOREACH(cmd, table, next) { + db_printf("%-12s", cmd->name); + db_end_line(12); } } @@ -287,7 +329,7 @@ struct command **last_cmdp; /* IN_OUT */ struct command_table *cmd_table; { - struct command *cmd; + struct command *cmd = NULL; int t; char modif[TOK_STRING_SIZE]; db_expr_t addr, count; @@ -450,7 +492,7 @@ db_printf("db> "); (void) db_read_line(); - db_command(&db_last_command, &db_command_table); + db_command(&db_last_command, &(db_command_tables[DB_COMMAND_TABLES_DEFAULT])); } } --- ./ddb/ddb.h.orig 2008-08-19 01:04:24.000000000 +0200 +++ ./ddb/ddb.h 2008-08-23 21:53:28.000000000 +0200 @@ -39,6 +39,9 @@ #include /* type definitions */ +#include /* STAILQ_* */ +#include /* SYSINIT */ + #ifndef DB_MAXARGS #define DB_MAXARGS 10 #endif @@ -53,23 +56,38 @@ char *modif); #define DB_COMMAND(cmd_name, func_name) \ - DB_FUNC(cmd_name, func_name, db_cmd_set, 0, NULL) + DB_FUNC(cmd_name, func_name, DB_COMMAND_TABLES_DEFAULT, 0, NULL) #define DB_SHOW_COMMAND(cmd_name, func_name) \ - DB_FUNC(cmd_name, func_name, db_show_cmd_set, 0, NULL) + DB_FUNC(cmd_name, func_name, DB_COMMAND_TABLES_SHOW, 0, NULL) +#define DB_SHOW_ALL_COMMAND(cmd_name, func_name) \ + DB_FUNC(cmd_name, func_name, DB_COMMAND_TABLES_SHOW_ALL, 0, NULL) -#define DB_SET(cmd_name, func_name, set, flag, more) \ -static const struct command __CONCAT(cmd_name,_cmd) = { \ - __STRING(cmd_name), \ - func_name, \ - flag, \ - more \ -}; \ -TEXT_SET(set, __CONCAT(cmd_name,_cmd)) +/* + * At the moment, there are three command "tables" on the system: + * - One for simple commands, whose list one can get by typing 'help' + * at debugger prompt. + * - One for sub-commands of 'show'. + * - The last one for sub-commands of 'show all'. + * All these tables are stored in an array, and the constants defined + * hereafter give the offset in the array at which the head for each + * table can be found. + */ +enum { + DB_COMMAND_TABLES_DEFAULT, + DB_COMMAND_TABLES_SHOW, + DB_COMMAND_TABLES_SHOW_ALL, + DB_COMMAND_TABLES_SIZE +}; + +struct command; -#define DB_FUNC(cmd_name, func_name, set, flag, more) \ +/* + * Declare the function func_name, which is handling db command + * cmd_name) + */ +#define DB_FUNC(cmd_name, func_name, list, flag, more) \ static db_cmdfcn_t func_name; \ - \ -DB_SET(cmd_name, func_name, set, flag, more); \ +DB_SET(cmd_name, func_name, list, flag, more); \ \ static void \ func_name(addr, have_addr, count, modif) \ @@ -78,6 +96,35 @@ db_expr_t count; \ char *modif; +/* + * Add command 'cmd_name' to the command table, along + * with the SYSINIT functions to load and unload it. + */ +#define DB_SET(cmd_name, func_name, list, flag, more) \ +static struct command __CONCAT(cmd_name,_cmd) = { \ + { NULL }, \ + __STRING(cmd_name), \ + func_name, \ + flag, \ + more \ +}; \ + \ +static void __CONCAT(cmd_name,_db_cmd_add)(void*); \ +static void __CONCAT(cmd_name,_db_cmd_rm)(void*); \ + \ +static void __CONCAT(cmd_name,_db_cmd_add)(void *arg __unused) \ +{ \ + db_command_register(list, &__CONCAT(cmd_name,_cmd)); \ +} \ + \ +static void __CONCAT(cmd_name,_db_cmd_rm)(void *arg __unused) \ +{ \ + db_command_unregister(list,__STRING(cmd_name)); \ +} \ + \ +SYSINIT(cmd_name, SI_SUB_KLD, SI_ORDER_ANY, __CONCAT(cmd_name,_db_cmd_add), NULL); \ +SYSUNINIT(cmd_name, SI_SUB_KLD, SI_ORDER_ANY, __CONCAT(cmd_name,_db_cmd_rm), NULL); + extern db_expr_t db_maxoff; extern int db_indent; extern int db_inst_count; @@ -124,6 +171,9 @@ int db_trace_thread(struct thread *, int); int db_value_of_name(const char *name, db_expr_t *valuep); int db_write_bytes(vm_offset_t addr, size_t size, char *data); +void db_cmd_init(void); +void db_command_register(int, struct command *); +void db_command_unregister(int, char *); db_cmdfcn_t db_breakpoint_cmd; db_cmdfcn_t db_continue_cmd; @@ -147,17 +197,17 @@ db_cmdfcn_t db_write_cmd; /* - * Command table. + * Declare command table type. It is actually a linked list, so + * as to allow for runtime extensions to the table. */ -struct command; - -struct command_table { - struct command *table; - struct command **aux_tablep; - struct command **aux_tablep_end; -}; +STAILQ_HEAD(command_table, command); +/* + * Command table entry. + */ struct command { + STAILQ_ENTRY(command) /* Pointer to the next entry in the */ + next; /* command table */ char * name; /* command name */ db_cmdfcn_t *fcn; /* function to call */ int flag; /* extra info: */ --- ./ddb/db_main.c.orig 2008-08-20 00:35:51.000000000 +0200 +++ ./ddb/db_main.c 2008-08-20 00:36:37.000000000 +0200 @@ -182,6 +182,8 @@ } } db_add_symbol_table(NULL, NULL, "kld", NULL); + + db_cmd_init(); return (1); /* We're the default debugger. */ } --- ./dev/aic7xxx/aic79xx_osm.c.orig 2008-08-21 02:42:04.000000000 +0200 +++ ./dev/aic7xxx/aic79xx_osm.c 2008-08-21 02:42:33.000000000 +0200 @@ -1423,7 +1423,7 @@ } } -DB_FUNC(ahd_out, ahd_ddb_out, db_cmd_set, CS_MORE, NULL) +DB_FUNC(ahd_out, ahd_ddb_out, DB_COMMAND_TABLES_DEFAULT, CS_MORE, NULL) { db_expr_t old_value; db_expr_t new_value; --- ./gnu/fs/xfs/FreeBSD/support/kdb.c.orig 2008-08-24 16:47:00.000000000 +0200 +++ ./gnu/fs/xfs/FreeBSD/support/kdb.c 2008-08-24 16:47:30.000000000 +0200 @@ -12,7 +12,7 @@ #include #ifdef DDB -DB_FUNC(xfs, xfs_ddb_cmd, db_cmd_set, CS_MORE, NULL) +DB_FUNC(xfs, xfs_ddb_cmd, DB_COMMAND_TABLES_DEFAULT, CS_MORE, NULL) { db_error("No commands registered.\n"); } --- ./kern/subr_sleepqueue.c.orig 2008-08-23 15:54:34.000000000 +0200 +++ ./kern/subr_sleepqueue.c 2008-08-21 21:49:13.000000000 +0200 @@ -983,5 +983,5 @@ } /* Alias 'show sleepqueue' to 'show sleepq'. */ -DB_SET(sleepqueue, db_show_sleepqueue, db_show_cmd_set, 0, NULL); +DB_SET(sleepqueue, db_show_sleepqueue, DB_COMMAND_TABLES_SHOW, 0, NULL); #endif From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 8 22:46:47 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFBFB1065670 for ; Mon, 8 Sep 2008 22:46:47 +0000 (UTC) (envelope-from prvs=1137c17701=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 6F6738FC08 for ; Mon, 8 Sep 2008 22:46:46 +0000 (UTC) (envelope-from prvs=1137c17701=killing@multiplay.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1220912887; x=1221517687; q=dns/txt; h=Received: Message-ID:From:To:Subject:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; bh=W/7NU2cCEAMwdm9POMY52uou6L2JjG3vc2 l31Suohqg=; b=YHeRkAb689lJEsHfUXeIHUTAOiAwny62mqHACCuszUk32FaptX t39EPYnX18heu70dY+CI7bYCAtB+NGrcSED5mYaL+dTpH+y3CAG+Uq+mWyr4aBu4 hiEMFNhpkBlAsAAwMQp5ByeQfZEnQrRcz5+hxtuwXs7M1MjWbVUj/bVm8= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-14.7 required=6.0 tests=BAYES_00, FORGED_MUA_OUTLOOK, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.8 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v9.6.6) with ESMTP id md50006153981.msg for ; Mon, 08 Sep 2008 23:28:06 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 85.236.106.102 X-Return-Path: prvs=1137c17701=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-ID: From: "Steven Hartland" To: Date: Mon, 8 Sep 2008 23:27:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 08 Sep 2008 23:28:07 +0100 X-MDAV-Processed: mail1.multiplay.co.uk, Mon, 08 Sep 2008 23:28:07 +0100 Subject: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 22:46:48 -0000 I've been trying to install FreeBSD 7.0-RELEASE amd64 on a Dell M600 Blade but it hangs just after initialising the isa bus. I've tried a number of things and the only thing that I can get to work is the i386 build which boots into the installer without issue. Has anyone had any experience with the Dell M600 blade on amd64 or had the amd64 build hang at this point before. I don't have access to the machines to try new things with ATM as we needed them in production so was forced to install ubuntu to get then live but I should get them back for more testing next week some time so wanted to see if anyone had any experience with this or a similar issue? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 9 00:58:41 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 878491065672 for ; Tue, 9 Sep 2008 00:58:41 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5228FC1B for ; Tue, 9 Sep 2008 00:58:41 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id CKZx1a00N0mlR8UA4Qih0Z; Tue, 09 Sep 2008 00:42:41 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id CQif1a00C4v8bD78XQighF; Tue, 09 Sep 2008 00:42:40 +0000 X-Authority-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=xoyE5_GXF_tzVR8gcjMA:9 a=_q_A6HagQHOpviBBsZoA:7 a=DZvys8ATxA-CsvyVMVC_WsGj0FMA:4 a=EoioJ0NPDVgA:10 a=9jdOw6BcRw0A:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 8B01017B84E; Mon, 8 Sep 2008 17:42:39 -0700 (PDT) Date: Mon, 8 Sep 2008 17:42:39 -0700 From: Jeremy Chadwick To: "Dan Mahoney, System Admin" Message-ID: <20080909004239.GA82283@icarus.home.lan> References: <20080908185106.GB6629@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: hackers@freebsd.org, Dan Nelson , questions@freebsd.org Subject: Re: IPFW uid logging... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2008 00:58:41 -0000 On Mon, Sep 08, 2008 at 04:03:29PM -0400, Dan Mahoney, System Admin wrote: > On Mon, 8 Sep 2008, Dan Nelson wrote: > >> In the last episode (Sep 08), Dan Mahoney, System Admin said: >>> I have the following rule set up in ipfw to limit the exposure of bad >>> php scripts and trojans that try to send mail directly. >>> >>> allow tcp from any to any dst-port 25 uid root >>> deny log tcp from any to any dst-port 25 out >>> >>> However, the log messages I get look like this: >>> >>> Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 >>> Sep 8 13:21:16 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 202.12.31.144:25 out via em0 >>> >>> Which is to say, they don't include the UID -- and I have several hundred >>> sites, each with its own UID. >>> >>> Yes, I could go ahead and set up a thousand "deny" rules, one for >>> each UID -- but being able to log this info (since it IS being >>> checked) would be great. >> >> It should be possible to add a couple more arguments to ipfw_log() so >> that ipfw_chk() can pass it the ugid_lookup flag and a pointer to the >> fw_ugid_cache struct. Then you can edit ipfw_log to print the contents >> of that struct if ugid_lookup==1. That would result in the logging of >> uid for any failed packet that had to go through a uid check on the way >> to the deny rule. > > Okay, so if it's fairly easy to do, the question would be "since I don't > feel right hacking in this change myself -- how could I propose this as a > feature?" It's not a BUG per-se, but I think it could be useful to > others as well. send-pr it. Category=kern, Class=change-request. Reference this thread in the Fix section: http://lists.freebsd.org/pipermail/freebsd-hackers/2008-September/025920.html FWIW, I think it's also a good idea. The output formatting of the log line might need to be adjusted "carefully" though, since any programs which grep on a very strict regex will start failing. I'm inclined to recommend the string ", UID xxx" be appended to the existing string, e.g. Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0, UID 6592 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 9 00:43:45 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5E981065741 for ; Tue, 9 Sep 2008 00:43:45 +0000 (UTC) (envelope-from Daan@vehosting.nl) Received: from VM01.VEHosting.nl (vm01.vehosting.nl [85.17.51.140]) by mx1.freebsd.org (Postfix) with ESMTP id 685EE8FC1A for ; Tue, 9 Sep 2008 00:43:45 +0000 (UTC) (envelope-from Daan@vehosting.nl) Received: from [192.168.45.10] (dhcp-077-250-050-082.chello.nl [77.250.50.82]) (authenticated bits=0) by VM01.VEHosting.nl (8.13.8/8.13.8) with ESMTP id m890Nu56075806; Tue, 9 Sep 2008 02:23:56 +0200 (CEST) (envelope-from Daan@vehosting.nl) From: Daan Vreeken Organization: VEHosting - Vitsch Electronics To: freebsd-hackers@freebsd.org Date: Tue, 9 Sep 2008 02:23:45 +0200 User-Agent: KMail/1.9.7 References: <20080908185106.GB6629@dan.emsphone.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809090223.46472.Daan@vehosting.nl> x-ve-auth-version: mi-1.0.3 2008-05-30 - Copyright (c) 2008 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.Vitsch.net X-Mailman-Approved-At: Tue, 09 Sep 2008 01:20:56 +0000 Cc: "Dan Mahoney, System Admin" , Dan Nelson Subject: Re: IPFW uid logging... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2008 00:43:46 -0000 Hi Dan, Dan and the list, On Monday 08 September 2008 22:03:29 Dan Mahoney, System Admin wrote: > On Mon, 8 Sep 2008, Dan Nelson wrote: > > In the last episode (Sep 08), Dan Mahoney, System Admin said: > >> I have the following rule set up in ipfw to limit the exposure of bad > >> php scripts and trojans that try to send mail directly. > >> > >> allow tcp from any to any dst-port 25 uid root > >> deny log tcp from any to any dst-port 25 out > >> > >> However, the log messages I get look like this: > >> > >> Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP > >> 72.9.101.130:58117 209.85.133.114:25 out via em0 Sep 8 13:21:16 > >> prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 > >> 202.12.31.144:25 out via em0 > >> > >> Which is to say, they don't include the UID -- and I have several > >> hundred sites, each with its own UID. > >> > >> Yes, I could go ahead and set up a thousand "deny" rules, one for > >> each UID -- but being able to log this info (since it IS being > >> checked) would be great. > > > > It should be possible to add a couple more arguments to ipfw_log() so > > that ipfw_chk() can pass it the ugid_lookup flag and a pointer to the > > fw_ugid_cache struct. Then you can edit ipfw_log to print the contents > > of that struct if ugid_lookup==1. That would result in the logging of > > uid for any failed packet that had to go through a uid check on the way > > to the deny rule. > > Okay, so if it's fairly easy to do, the question would be "since I don't > feel right hacking in this change myself -- how could I propose this as a > feature?" It's not a BUG per-se, but I think it could be useful to others > as well. I own a webhosting company and here too every domain gets it's own user, so I like this proposal. I've hacked together a first try, which seems to be working. A patch (against -HEAD) can be found here : http://vehosting.nl/pub_diffs/ip_fw2.c_uid_2008_09_09.diff Improvements / tips / comments are welcome ;-) -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 9 05:42:01 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B3FC106564A for ; Tue, 9 Sep 2008 05:42:01 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id E74B08FC15 for ; Tue, 9 Sep 2008 05:42:00 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id m895C0TJ049508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Sep 2008 00:12:00 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.2/Submit) id m894ocks097506; Mon, 8 Sep 2008 23:50:38 -0500 (CDT) (envelope-from dan) Date: Mon, 8 Sep 2008 23:50:37 -0500 From: Dan Nelson To: Daan Vreeken Message-ID: <20080909045037.GC6629@dan.emsphone.com> References: <20080908185106.GB6629@dan.emsphone.com> <200809090223.46472.Daan@vehosting.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809090223.46472.Daan@vehosting.nl> X-OS: FreeBSD 7.0-STABLE User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org, "Dan Mahoney, System Admin" Subject: Re: IPFW uid logging... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2008 05:42:01 -0000 In the last episode (Sep 09), Daan Vreeken said: > On Monday 08 September 2008 22:03:29 Dan Mahoney, System Admin wrote: > > On Mon, 8 Sep 2008, Dan Nelson wrote: > > > In the last episode (Sep 08), Dan Mahoney, System Admin said: > > >> I have the following rule set up in ipfw to limit the exposure > > >> of bad php scripts and trojans that try to send mail directly. > > >> > > >> allow tcp from any to any dst-port 25 uid root > > >> deny log tcp from any to any dst-port 25 out > > >> > > >> However, the log messages I get look like this: > > >> > > >> Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 > > >> Sep 8 13:21:16 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 202.12.31.144:25 out via em0 > > >> > > >> Which is to say, they don't include the UID -- and I have > > >> several hundred sites, each with its own UID. > > >> > > >> Yes, I could go ahead and set up a thousand "deny" rules, one > > >> for each UID -- but being able to log this info (since it IS > > >> being checked) would be great. > > > > > > It should be possible to add a couple more arguments to > > > ipfw_log() so that ipfw_chk() can pass it the ugid_lookup flag > > > and a pointer to the fw_ugid_cache struct. Then you can edit > > > ipfw_log to print the contents of that struct if ugid_lookup==1. > > > That would result in the logging of uid for any failed packet > > > that had to go through a uid check on the way to the deny rule. > > > > Okay, so if it's fairly easy to do, the question would be "since I > > don't feel right hacking in this change myself -- how could I > > propose this as a feature?" It's not a BUG per-se, but I think it > > could be useful to others as well. > > Hi Dan, Dan and the list, > > I own a webhosting company and here too every domain gets it's own > user, so I like this proposal. I've hacked together a first try, > which seems to be working. A patch (against -HEAD) can be found here: > > http://vehosting.nl/pub_diffs/ip_fw2.c_uid_2008_09_09.diff > > Improvements / tips / comments are welcome ;-) I like it. Maybe print gid as well, since there's an ipfw rule for that too. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 9 07:58:52 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA0FE106566B for ; Tue, 9 Sep 2008 07:58:51 +0000 (UTC) (envelope-from Daan@vehosting.nl) Received: from VM01.VEHosting.nl (vm01.vehosting.nl [85.17.51.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7FA1B8FC1C for ; Tue, 9 Sep 2008 07:58:51 +0000 (UTC) (envelope-from Daan@vehosting.nl) Received: from [192.168.45.10] (dhcp-077-250-050-082.chello.nl [77.250.50.82]) (authenticated bits=0) by VM01.VEHosting.nl (8.13.8/8.13.8) with ESMTP id m897wgmf086427; Tue, 9 Sep 2008 09:58:42 +0200 (CEST) (envelope-from Daan@vehosting.nl) From: Daan Vreeken Organization: VEHosting - Vitsch Electronics To: freebsd-hackers@freebsd.org Date: Tue, 9 Sep 2008 09:58:34 +0200 User-Agent: KMail/1.9.7 References: <200809090223.46472.Daan@vehosting.nl> <20080909045037.GC6629@dan.emsphone.com> In-Reply-To: <20080909045037.GC6629@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809090958.35448.Daan@vehosting.nl> x-ve-auth-version: mi-1.0.3 2008-05-30 - Copyright (c) 2008 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on VM01.Vitsch.net Cc: "Dan Mahoney, System Admin" , Dan Nelson Subject: Re: IPFW uid logging... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2008 07:58:52 -0000 On Tuesday 09 September 2008 06:50:37 Dan Nelson wrote: > In the last episode (Sep 09), Daan Vreeken said: > > On Monday 08 September 2008 22:03:29 Dan Mahoney, System Admin wrote: > > > On Mon, 8 Sep 2008, Dan Nelson wrote: > > > > In the last episode (Sep 08), Dan Mahoney, System Admin said: > > > >> I have the following rule set up in ipfw to limit the exposure > > > >> of bad php scripts and trojans that try to send mail directly. > > > >> > > > >> allow tcp from any to any dst-port 25 uid root > > > >> deny log tcp from any to any dst-port 25 out > > > >> > > > >> However, the log messages I get look like this: > > > >> > > > >> Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP > > > >> 72.9.101.130:58117 209.85.133.114:25 out via em0 Sep 8 13:21:16 > > > >> prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 > > > >> 202.12.31.144:25 out via em0 > > > >> > > > >> Which is to say, they don't include the UID -- and I have > > > >> several hundred sites, each with its own UID. > > > >> > > > >> Yes, I could go ahead and set up a thousand "deny" rules, one > > > >> for each UID -- but being able to log this info (since it IS > > > >> being checked) would be great. > > > > > > > > It should be possible to add a couple more arguments to > > > > ipfw_log() so that ipfw_chk() can pass it the ugid_lookup flag > > > > and a pointer to the fw_ugid_cache struct. Then you can edit > > > > ipfw_log to print the contents of that struct if ugid_lookup==1. > > > > That would result in the logging of uid for any failed packet > > > > that had to go through a uid check on the way to the deny rule. > > > > > > Okay, so if it's fairly easy to do, the question would be "since I > > > don't feel right hacking in this change myself -- how could I > > > propose this as a feature?" It's not a BUG per-se, but I think it > > > could be useful to others as well. > > > > Hi Dan, Dan and the list, > > > > I own a webhosting company and here too every domain gets it's own > > user, so I like this proposal. I've hacked together a first try, > > which seems to be working. A patch (against -HEAD) can be found here: > > > > http://vehosting.nl/pub_diffs/ip_fw2.c_uid_2008_09_09.diff > > > > Improvements / tips / comments are welcome ;-) > > I like it. Maybe print gid as well, since there's an ipfw rule for > that too. I intentionally left printing the gid out, since a user can be in up to NGROUPS_MAX groups. We could of course only show the one gid that matched... The following (only compile-tested) patch tries to implement that : http://vehosting.nl/pub_diffs/ip_fw2.c_uid_2008_09_09_2.diff I'm not really sure which patch I liked best. The first patch missed a check against (ugid_lookup == -1) though. -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 9 08:34:14 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD8DF1065678 for ; Tue, 9 Sep 2008 08:34:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id A39B38FC1B for ; Tue, 9 Sep 2008 08:34:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7F55146BAD; Tue, 9 Sep 2008 04:34:12 -0400 (EDT) Date: Tue, 9 Sep 2008 09:34:13 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Daan Vreeken In-Reply-To: <200809090223.46472.Daan@vehosting.nl> Message-ID: References: <20080908185106.GB6629@dan.emsphone.com> <200809090223.46472.Daan@vehosting.nl> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, "Dan Mahoney, System Admin" , Dan Nelson Subject: Re: IPFW uid logging... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2008 08:34:14 -0000 On Tue, 9 Sep 2008, Daan Vreeken wrote: >>>> Which is to say, they don't include the UID -- and I have several hundred >>>> sites, each with its own UID. >>>> >>>> Yes, I could go ahead and set up a thousand "deny" rules, one for each >>>> UID -- but being able to log this info (since it IS being checked) would >>>> be great. >>> >>> It should be possible to add a couple more arguments to ipfw_log() so that >>> ipfw_chk() can pass it the ugid_lookup flag and a pointer to the >>> fw_ugid_cache struct. Then you can edit ipfw_log to print the contents of >>> that struct if ugid_lookup==1. That would result in the logging of uid >>> for any failed packet that had to go through a uid check on the way to the >>> deny rule. >> >> Okay, so if it's fairly easy to do, the question would be "since I don't >> feel right hacking in this change myself -- how could I propose this as a >> feature?" It's not a BUG per-se, but I think it could be useful to others >> as well. > > I own a webhosting company and here too every domain gets it's own user, so > I like this proposal. I've hacked together a first try, which seems to be > working. A patch (against -HEAD) can be found here : > > http://vehosting.nl/pub_diffs/ip_fw2.c_uid_2008_09_09.diff > > Improvements / tips / comments are welcome ;-) A few observations generally about the use of connection credential data in the firewall: (1) UID lookups on connections from the firewall are inherently race-prone and unreliable; the stack layering violation means that locks may be acquired independently for the connection lookup at the firewall and socket layers. This non-atomicity may be fairly acceptable in the event that there aren't significant delays in processing, but if you also have DUMMYNET pipes in use then these races may mean significant gaps in time between when a socket is looked up for check vs. use. (2) The performance hit of connection lookups in order to find credentials for received packets may (should) be massive: the input path will look up the connection for each packet multiple times, acquiring contended locks, etc. (3) It's currently not possible to look up the connection associated with several sorts of packets, including ICMP (such as used with PMTU). Note that all of these problems apply to existing uid/gid/jail credential rules, which are considered unreliable and non-performant for the same reasons. Looking at your patch specifically, it seems you don't force the lookup of credential information if it hasn't already being looked up for a credential rule. This should mean that the known problems of (1), (2), and (3) shouldn't be worse than they were before. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 9 11:54:03 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0963B1065671 for ; Tue, 9 Sep 2008 11:54:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id A6C5B8FC2A for ; Tue, 9 Sep 2008 11:54:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Kd1n9-0000Y3-Ec; Tue, 09 Sep 2008 14:53:55 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m89Brqj8072093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Sep 2008 14:53:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m89BrqVK064903; Tue, 9 Sep 2008 14:53:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id m89BrpZ6064900; Tue, 9 Sep 2008 14:53:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 9 Sep 2008 14:53:51 +0300 From: Kostik Belousov To: Wesley Shields Message-ID: <20080909115351.GJ39652@deviant.kiev.zoral.com.ua> References: <9f8af95f0809061626q22bc8f60i48fd95b32cef3d04@mail.gmail.com> <20080907150747.GB62357@atarininja.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="81JctsDUVPekGcy+" Content-Disposition: inline In-Reply-To: <20080907150747.GB62357@atarininja.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1Kd1n9-0000Y3-Ec 7015aa5a1a63fb9547d42812ea71fba9 X-Terabit: YES Cc: freebsd-hackers , jT Subject: Re: 256-byte inode support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2008 11:54:03 -0000 --81JctsDUVPekGcy+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 07, 2008 at 11:07:47AM -0400, Wesley Shields wrote: > On Sat, Sep 06, 2008 at 07:26:27PM -0400, jT wrote: > > hackers, > >=20 > > since tytso had updated ext3 -- i've noticed that i can't use my > > 265-byte inode ext3 drives -- is there any effort to update it? If > > not -- if you know where i should attempt to start please let me know > > so i can start working on support (i have a few other people i know > > interested in this) -- thanks and hope everyone is well >=20 > There was a PR submitted for it and eventually a patch added to the PR. > I've tested the patch given in the URL at the port and it works. We > will start to see more of this as the newer version becomes more common > in the wild. >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/124621 >=20 > Would be nice to see this fixed in 7.1 but it may be too late for that. What was the reason for increasing inode size ? I think it is rather pointless to increase the size without using newly added space for some data. Is inode format the same for the first 128 bytes, and does data at the second 128 bytes should be used to correctly interpret inode ? --81JctsDUVPekGcy+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjGY84ACgkQC3+MBN1Mb4gDMACg9KuiYHtKQ8cgVpmYesyLM+ZH ErwAoMldpcQHetVuTvlLzzm5SIKknWtB =fF4H -----END PGP SIGNATURE----- --81JctsDUVPekGcy+-- From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 9 12:29:11 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CAED1065671 for ; Tue, 9 Sep 2008 12:29:11 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id 0EBEF8FC18 for ; Tue, 9 Sep 2008 12:29:10 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id 60AF15C2D; Tue, 9 Sep 2008 08:29:17 -0400 (EDT) Date: Tue, 9 Sep 2008 08:29:17 -0400 From: Wesley Shields To: Kostik Belousov Message-ID: <20080909122917.GK62357@atarininja.org> References: <9f8af95f0809061626q22bc8f60i48fd95b32cef3d04@mail.gmail.com> <20080907150747.GB62357@atarininja.org> <20080909115351.GJ39652@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080909115351.GJ39652@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers , jT Subject: Re: 256-byte inode support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2008 12:29:11 -0000 On Tue, Sep 09, 2008 at 02:53:51PM +0300, Kostik Belousov wrote: > On Sun, Sep 07, 2008 at 11:07:47AM -0400, Wesley Shields wrote: > > On Sat, Sep 06, 2008 at 07:26:27PM -0400, jT wrote: > > > hackers, > > > > > > since tytso had updated ext3 -- i've noticed that i can't use my > > > 265-byte inode ext3 drives -- is there any effort to update it? If > > > not -- if you know where i should attempt to start please let me know > > > so i can start working on support (i have a few other people i know > > > interested in this) -- thanks and hope everyone is well > > > > There was a PR submitted for it and eventually a patch added to the PR. > > I've tested the patch given in the URL at the port and it works. We > > will start to see more of this as the newer version becomes more common > > in the wild. > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124621 > > > > Would be nice to see this fixed in 7.1 but it may be too late for that. > > What was the reason for increasing inode size ? I think it is rather > pointless to increase the size without using newly added space for some > data. Is inode format the same for the first 128 bytes, and does data > at the second 128 bytes should be used to correctly interpret inode ? I honestly don't know the answer. Though I do agree that it is pointless to increase the size without using the new space. All I know is that I was unable to read an ext filesystem made with -I 256 (which is the default when using the most recent sysutils/e2fsprogs). wxs@ack ~ % truncate -s 1G ext-128 wxs@ack ~ % truncate -s 1G ext-256 wxs@ack ~ % sudo mdconfig -a -t vnode -f ext-128 -s 1G md0 wxs@ack ~ % sudo mdconfig -a -t vnode -f ext-256 -s 1G md1 wxs@ack ~ % sudo kldload ext2fs wxs@ack ~ % mke2fs -I 128 /dev/md0 mke2fs 1.41.0 (10-Jul-2008) mke2fs: Permission denied while trying to determine filesystem size wxs@ack ~ % sudo mke2fs -I 128 /dev/md0 mke2fs 1.41.0 (10-Jul-2008) Filesystem label= OS type: FreeBSD Block size=4096 (log=2) Fragment size=4096 (log=2) 65536 inodes, 262144 blocks 13107 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=268435456 8 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Writing inode tables: done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 27 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. wxs@ack ~ % sudo mke2fs /dev/md1 mke2fs 1.41.0 (10-Jul-2008) Filesystem label= OS type: FreeBSD Block size=4096 (log=2) Fragment size=4096 (log=2) 65536 inodes, 262144 blocks 13107 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=268435456 8 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Writing inode tables: done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 37 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. wxs@ack ~ % sudo mount -t ext2fs /dev/md0 /mnt/ext2-128 wxs@ack ~ % sudo mount -t ext2fs /dev/md1 /mnt/ext2-256 wxs@ack ~ % ls /mnt/ext2-128 lost+found/ wxs@ack ~ % ls /mnt/ext2-256 ls: /mnt/ext2-256: Bad file descriptor wxs@ack ~ % -- WXS From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 9 12:38:03 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81ABA106566B; Tue, 9 Sep 2008 12:38:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 29F9B8FC15; Tue, 9 Sep 2008 12:38:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Kd2Ti-000Bde-Se; Tue, 09 Sep 2008 15:37:55 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m89CblV0074974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Sep 2008 15:37:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m89CblPl093018; Tue, 9 Sep 2008 15:37:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id m89CblfA093012; Tue, 9 Sep 2008 15:37:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 9 Sep 2008 15:37:47 +0300 From: Kostik Belousov To: Wesley Shields Message-ID: <20080909123746.GK39652@deviant.kiev.zoral.com.ua> References: <9f8af95f0809061626q22bc8f60i48fd95b32cef3d04@mail.gmail.com> <20080907150747.GB62357@atarininja.org> <20080909115351.GJ39652@deviant.kiev.zoral.com.ua> <20080909122917.GK62357@atarininja.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MMMIZFJzhAsRj/+" Content-Disposition: inline In-Reply-To: <20080909122917.GK62357@atarininja.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1Kd2Ti-000Bde-Se 9346e5a43fc653a3afde1c6ee6a3b272 X-Terabit: YES Cc: freebsd-hackers , jT Subject: Re: 256-byte inode support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2008 12:38:03 -0000 --3MMMIZFJzhAsRj/+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 09, 2008 at 08:29:17AM -0400, Wesley Shields wrote: > On Tue, Sep 09, 2008 at 02:53:51PM +0300, Kostik Belousov wrote: > > On Sun, Sep 07, 2008 at 11:07:47AM -0400, Wesley Shields wrote: > > > On Sat, Sep 06, 2008 at 07:26:27PM -0400, jT wrote: > > > > hackers, > > > >=20 > > > > since tytso had updated ext3 -- i've noticed that i can't use my > > > > 265-byte inode ext3 drives -- is there any effort to update it? If > > > > not -- if you know where i should attempt to start please let me kn= ow > > > > so i can start working on support (i have a few other people i know > > > > interested in this) -- thanks and hope everyone is well > > >=20 > > > There was a PR submitted for it and eventually a patch added to the P= R. > > > I've tested the patch given in the URL at the port and it works. We > > > will start to see more of this as the newer version becomes more comm= on > > > in the wild. > > >=20 > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/124621 > > >=20 > > > Would be nice to see this fixed in 7.1 but it may be too late for tha= t. > >=20 > > What was the reason for increasing inode size ? I think it is rather > > pointless to increase the size without using newly added space for some > > data. Is inode format the same for the first 128 bytes, and does data > > at the second 128 bytes should be used to correctly interpret inode ? >=20 > I honestly don't know the answer. Though I do agree that it is > pointless to increase the size without using the new space. >=20 > All I know is that I was unable to read an ext filesystem made with -I > 256 (which is the default when using the most recent > sysutils/e2fsprogs). I think it is too dangerous for the user data to commit this patch, without investigating this first. --3MMMIZFJzhAsRj/+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjGbhoACgkQC3+MBN1Mb4g80gCg7CbNJWbG07/8cC2/+TxjTu/i BmQAoM9uYWjQoAF9DBeHU5PWQF3thquG =DAOI -----END PGP SIGNATURE----- --3MMMIZFJzhAsRj/+-- From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 9 12:53:59 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67E2E10656C5 for ; Tue, 9 Sep 2008 12:53:59 +0000 (UTC) (envelope-from kr.lekha@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by mx1.freebsd.org (Postfix) with ESMTP id 3ADD18FC1C for ; Tue, 9 Sep 2008 12:53:58 +0000 (UTC) (envelope-from kr.lekha@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2690832rvf.43 for ; Tue, 09 Sep 2008 05:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=1h7QkLH9m7oKWQU4bbrAE90H0LKfCR8o9dPi12EaF1E=; b=sRd0BRKLhHk9SbNfAOwo/FLs0Q1M7x7tyZzCQdRwEulUnjAaAGuzf08400McjVrYpZ xb2Ztbmpc5Eh7m0mY34mmoVcyBxQgaOlejfB/Em7Ka0FJlp5YgdgwQp3YPyvVeQJqDPK ZNkBwNxodmaZcG0IAYkhlBgNV3CHA2Mwnwy5c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=FyQkHyIoDwuCZ2iRk+IqHR4xD5APiV36fLqtRzSq4IzBC02Lurt2DOFo4wU89p2bUI Zw+seRHg2MNSRDzcQ2DJGbzuVzYF5kTF4F2o60kvo2yZ3hbrNMbUXnyMyBjfg8Y25fQ9 kAYxF3G5Pn28sfvzH0twu7ixj3IzSUcjwoO8E= Received: by 10.141.37.16 with SMTP id p16mr211664rvj.67.1220964837676; Tue, 09 Sep 2008 05:53:57 -0700 (PDT) Received: by 10.141.212.11 with HTTP; Tue, 9 Sep 2008 05:53:57 -0700 (PDT) Message-ID: <96b2ec350809090553q3ba36125nd3da14129da0f2b3@mail.gmail.com> Date: Tue, 9 Sep 2008 13:53:57 +0100 From: "kr Lekha" To: "kr Lekha" , "Rui Paulo" , freebsd-hackers@freebsd.org In-Reply-To: <20080903211459.GA60350@zim.MIT.EDU> MIME-Version: 1.0 References: <96b2ec350809030134j73a61369m35395391a1218975@mail.gmail.com> <20080903095605.GB21178@alpha.local> <96b2ec350809030516y2d6f26d1h3cd7eb39231c4da0@mail.gmail.com> <20080903211459.GA60350@zim.MIT.EDU> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: killing a kthread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2008 12:53:59 -0000 Hi all, thanks very much for your valuable inputs. I found out the way to exit the thread. Problem was psignal(p, SIGKILL); , the p->p_siglist was being reset after propagating this signal to threads associated with this proc. Hence i could poll once in a way if any unhandled signals were in curthread->td_siglist. I am not sure if this is the optimal solution. Please do sugest if you have a better solution Why cant we have signal handlers for kernel threads? when i tried to register one, sigaction returned value 14 and signal handler didnt get registered. Thanks, lekha On Wed, Sep 3, 2008 at 10:14 PM, David Schultz wrote: > On Wed, Sep 03, 2008, kr Lekha wrote: > > I understand when thread finishes it should call kthread_exit(). > > but if this thread was suspended before it finished, it might not be able > to > > call kthread_exit(). > > > > Due to which we still see the thread suspended. I am unable to kill it > > even with killproc / psignal with in the kernel module. > > That's by design. Kernel threads can hold arbitrary kernel > resources, and there's no mechanism to clean up after them > automatically. They are expected to clean up after themselves and > exit gracefully. In your case, you'll need to wake up the > suspended thread and somehow notify it that you want it to > terminate. > From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 9 13:14:35 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9D311065670 for ; Tue, 9 Sep 2008 13:14:35 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id 86DE18FC12 for ; Tue, 9 Sep 2008 13:14:35 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id 249DE5C18; Tue, 9 Sep 2008 09:14:42 -0400 (EDT) Date: Tue, 9 Sep 2008 09:14:42 -0400 From: Wesley Shields To: Kostik Belousov Message-ID: <20080909131442.GL62357@atarininja.org> References: <9f8af95f0809061626q22bc8f60i48fd95b32cef3d04@mail.gmail.com> <20080907150747.GB62357@atarininja.org> <20080909115351.GJ39652@deviant.kiev.zoral.com.ua> <20080909122917.GK62357@atarininja.org> <20080909123746.GK39652@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080909123746.GK39652@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers , jT Subject: Re: 256-byte inode support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2008 13:14:35 -0000 On Tue, Sep 09, 2008 at 03:37:47PM +0300, Kostik Belousov wrote: > On Tue, Sep 09, 2008 at 08:29:17AM -0400, Wesley Shields wrote: > > On Tue, Sep 09, 2008 at 02:53:51PM +0300, Kostik Belousov wrote: > > > On Sun, Sep 07, 2008 at 11:07:47AM -0400, Wesley Shields wrote: > > > > On Sat, Sep 06, 2008 at 07:26:27PM -0400, jT wrote: > > > > > hackers, > > > > > > > > > > since tytso had updated ext3 -- i've noticed that i can't use my > > > > > 265-byte inode ext3 drives -- is there any effort to update it? If > > > > > not -- if you know where i should attempt to start please let me know > > > > > so i can start working on support (i have a few other people i know > > > > > interested in this) -- thanks and hope everyone is well > > > > > > > > There was a PR submitted for it and eventually a patch added to the PR. > > > > I've tested the patch given in the URL at the port and it works. We > > > > will start to see more of this as the newer version becomes more common > > > > in the wild. > > > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124621 > > > > > > > > Would be nice to see this fixed in 7.1 but it may be too late for that. > > > > > > What was the reason for increasing inode size ? I think it is rather > > > pointless to increase the size without using newly added space for some > > > data. Is inode format the same for the first 128 bytes, and does data > > > at the second 128 bytes should be used to correctly interpret inode ? > > > > I honestly don't know the answer. Though I do agree that it is > > pointless to increase the size without using the new space. > > > > All I know is that I was unable to read an ext filesystem made with -I > > 256 (which is the default when using the most recent > > sysutils/e2fsprogs). > > I think it is too dangerous for the user data to commit this patch, > without investigating this first. I think that's a fair assessment to make. The patch is certainly simple enough but I'm not familiar with what it's doing to make an accurate assessment. I know it worked for the simple test case I provided in my previous message. If I can be of any further assistance please let me know. -- WXS From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 9 21:04:44 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F643106564A for ; Tue, 9 Sep 2008 21:04:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B54F68FC1F for ; Tue, 9 Sep 2008 21:04:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m89L4CIi008827; Tue, 9 Sep 2008 17:04:37 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 9 Sep 2008 15:38:08 -0400 User-Agent: KMail/1.9.7 References: <200809041400.04575.marc.loerner@hob.de> In-Reply-To: <200809041400.04575.marc.loerner@hob.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200809091538.08716.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 09 Sep 2008 17:04:37 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8162/Thu Sep 4 12:38:45 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Marc =?iso-8859-1?q?L=F6rner?= Subject: Re: question on asymmetric mtx_[un]lock_sleep X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2008 21:04:44 -0000 On Thursday 04 September 2008 08:00:04 am Marc L=F6rner wrote: > Hello, > I just read through the code of mutexes and turnstiles > and it seems to me that _mtx_lock_sleep and _mtx_unlock_sleep > are some kind of asymmetric when turning SMP and adaptive mutexes > on in kernel-configuration. >=20 > On locking the mutex, we try to "quick" obtain the lock. > If we can't do this, we look, whether some other thread, that's running, > holds the lock and spin until either lock is freed or thread is not runni= ng=20 > anymore. In that case we try again to obtain the lock "quick". > If the thread only stopped running but still holds the lock, we use=20 turnstiles > to wake us up, when the thread unlocks the mutex. > =3D> That seems to be fine and quite symmetric with _mtx_unlock_sleep!! >=20 > But if we're spinning and the other thread gave the mutex free,=20 > we quick-lock the mutex and don't set up a turnstile. >=20 > Now on mtx_unlock_sleep: > - in FreeBSD6/until revision 1.200 turnstiles were tested on existence. > =3D> if turnstile_lookup return NULL we only released the lock quick. >=20 > - But now, it's never tested if turnstile exists instead we broadcast/wak= eup > all threads pending on the turnstile. If this turnstile is NULL =3D> we= =20 access > wrong memory. >=20 > Now my question is: Why can we be sure (in new source) that turnstile_loo= kup=20 > always returns a valid pointer to an turnstile and can use returned point= er=20 > to call turnstile_broadcast? Am I missing something? >=20 > Because it seems that following scenario may occur: > - on locking same scenario as above (=3D> thread1 now holds the lock) > - thread1 is put off the runqueue > - thread2 now tries to quick unlock mutex and sees that thread1 holds it = =3D>=20 > call to mtx_unlock_sleep > - now we try to use turnstile-mechanism and call turnstile_lookup =3D> re= turns=20 > NULL because no thread waits for wakeup =3D> we call turnstile_broadcast = and=20 > crash. Newer locks don't set the CONTESTED flag unless they are actually going to = go=20 to sleep. If they succeed in setting CONTESTED or it is already set when=20 they test for it, then they will block on the turnstile. The turnstile cha= in=20 lock will prevent a concurrent unlock from grabbing the turnstile until the= =20 blocking thread is fully asleep. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 10 08:35:48 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B56FB1065673; Wed, 10 Sep 2008 08:35:48 +0000 (UTC) (envelope-from prvs=1139d62d78=marc.loerner@hob.de) Received: from mailgate.hob.de (mailgate.hob.de [212.185.199.3]) by mx1.freebsd.org (Postfix) with ESMTP id 488068FC2C; Wed, 10 Sep 2008 08:35:48 +0000 (UTC) (envelope-from prvs=1139d62d78=marc.loerner@hob.de) Received: from imap.hob.de (mail2.hob.de [172.25.1.102]) by mailgate.hob.de (Postfix) with ESMTP id D46F45200E6; Wed, 10 Sep 2008 10:19:06 +0200 (CEST) Received: from linux03.hob.de (linux03.hob.de [172.22.0.190]) by imap.hob.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 71D92FD8B0; Wed, 10 Sep 2008 10:19:06 +0200 (CEST) From: Marc =?iso-8859-1?q?L=F6rner?= Organization: hob To: John Baldwin Date: Wed, 10 Sep 2008 10:19:30 +0200 User-Agent: KMail/1.6.2 References: <200809041400.04575.marc.loerner@hob.de> <200809091538.08716.jhb@freebsd.org> In-Reply-To: <200809091538.08716.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200809101019.30453.marc.loerner@hob.de> Cc: freebsd-hackers@freebsd.org Subject: Re: question on asymmetric mtx_[un]lock_sleep X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2008 08:35:48 -0000 On Tuesday 09 September 2008 21:38, John Baldwin wrote: > On Thursday 04 September 2008 08:00:04 am Marc Lörner wrote: > > Hello, > > I just read through the code of mutexes and turnstiles > > and it seems to me that _mtx_lock_sleep and _mtx_unlock_sleep > > are some kind of asymmetric when turning SMP and adaptive mutexes > > on in kernel-configuration. > > > > On locking the mutex, we try to "quick" obtain the lock. > > If we can't do this, we look, whether some other thread, that's running, > > holds the lock and spin until either lock is freed or thread is not > > running anymore. In that case we try again to obtain the lock "quick". > > If the thread only stopped running but still holds the lock, we use > > turnstiles > > > to wake us up, when the thread unlocks the mutex. > > => That seems to be fine and quite symmetric with _mtx_unlock_sleep!! > > > > But if we're spinning and the other thread gave the mutex free, > > we quick-lock the mutex and don't set up a turnstile. > > > > Now on mtx_unlock_sleep: > > - in FreeBSD6/until revision 1.200 turnstiles were tested on existence. > > => if turnstile_lookup return NULL we only released the lock quick. > > > > - But now, it's never tested if turnstile exists instead we > > broadcast/wakeup all threads pending on the turnstile. If this turnstile > > is NULL => we > > access > > > wrong memory. > > > > Now my question is: Why can we be sure (in new source) that > > turnstile_lookup always returns a valid pointer to an turnstile and can > > use returned pointer to call turnstile_broadcast? Am I missing something? > > > > Because it seems that following scenario may occur: > > - on locking same scenario as above (=> thread1 now holds the lock) > > - thread1 is put off the runqueue > > - thread2 now tries to quick unlock mutex and sees that thread1 holds it > > => call to mtx_unlock_sleep > > - now we try to use turnstile-mechanism and call turnstile_lookup => > > returns NULL because no thread waits for wakeup => we call > > turnstile_broadcast and crash. > > Newer locks don't set the CONTESTED flag unless they are actually going to > go to sleep. If they succeed in setting CONTESTED or it is already set > when they test for it, then they will block on the turnstile. The > turnstile chain lock will prevent a concurrent unlock from grabbing the > turnstile until the blocking thread is fully asleep. I see the setting of CONTESTED in case of sleeping in mtx_lock_sleep! But there is still the possibility that mtx_lock_sleep "just" obtains the lock and doesn't set contested-bit! See described case above (we reach first continue in mtx_lock_sleep and test on obtain_lock ends while-loop). Why is this bit not tested in mtx_unlock_sleep? I think, it's still possible that turnstile_lookup returns NULL. And we still have "MPASS(ts != NULL);" in mtx_unlock_sleep that is not turned on for GENERIC-kernel (no INVARIANTS support). And I'm still wondering why the former test on "ts != NULL" went away? Regards, Marc Loerner From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 10 19:07:43 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D0AE106566B for ; Wed, 10 Sep 2008 19:07:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1C3C88FC12 for ; Wed, 10 Sep 2008 19:07:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8AJ7Q6u021256; Wed, 10 Sep 2008 15:07:34 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Marc =?iso-8859-1?q?L=F6rner?= Date: Wed, 10 Sep 2008 14:09:48 -0400 User-Agent: KMail/1.9.7 References: <200809041400.04575.marc.loerner@hob.de> <200809091538.08716.jhb@freebsd.org> <200809101019.30453.marc.loerner@hob.de> In-Reply-To: <200809101019.30453.marc.loerner@hob.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200809101409.49145.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 10 Sep 2008 15:07:34 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-hackers@freebsd.org Subject: Re: question on asymmetric mtx_[un]lock_sleep X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2008 19:07:43 -0000 On Wednesday 10 September 2008 04:19:30 am Marc L=F6rner wrote: > On Tuesday 09 September 2008 21:38, John Baldwin wrote: > > On Thursday 04 September 2008 08:00:04 am Marc L=F6rner wrote: > > > Hello, > > > I just read through the code of mutexes and turnstiles > > > and it seems to me that _mtx_lock_sleep and _mtx_unlock_sleep > > > are some kind of asymmetric when turning SMP and adaptive mutexes > > > on in kernel-configuration. > > > > > > On locking the mutex, we try to "quick" obtain the lock. > > > If we can't do this, we look, whether some other thread, that's runni= ng, > > > holds the lock and spin until either lock is freed or thread is not > > > running anymore. In that case we try again to obtain the lock "quick". > > > If the thread only stopped running but still holds the lock, we use > > > > turnstiles > > > > > to wake us up, when the thread unlocks the mutex. > > > =3D> That seems to be fine and quite symmetric with _mtx_unlock_sleep= !! > > > > > > But if we're spinning and the other thread gave the mutex free, > > > we quick-lock the mutex and don't set up a turnstile. > > > > > > Now on mtx_unlock_sleep: > > > - in FreeBSD6/until revision 1.200 turnstiles were tested on existenc= e. > > > =3D> if turnstile_lookup return NULL we only released the lock quic= k. > > > > > > - But now, it's never tested if turnstile exists instead we > > > broadcast/wakeup all threads pending on the turnstile. If this turnst= ile > > > is NULL =3D> we > > > > access > > > > > wrong memory. > > > > > > Now my question is: Why can we be sure (in new source) that > > > turnstile_lookup always returns a valid pointer to an turnstile and c= an > > > use returned pointer to call turnstile_broadcast? Am I missing=20 something? > > > > > > Because it seems that following scenario may occur: > > > - on locking same scenario as above (=3D> thread1 now holds the lock) > > > - thread1 is put off the runqueue > > > - thread2 now tries to quick unlock mutex and sees that thread1 holds= it > > > =3D> call to mtx_unlock_sleep > > > - now we try to use turnstile-mechanism and call turnstile_lookup =3D> > > > returns NULL because no thread waits for wakeup =3D> we call > > > turnstile_broadcast and crash. > > > > Newer locks don't set the CONTESTED flag unless they are actually going= to > > go to sleep. If they succeed in setting CONTESTED or it is already set > > when they test for it, then they will block on the turnstile. The > > turnstile chain lock will prevent a concurrent unlock from grabbing the > > turnstile until the blocking thread is fully asleep. >=20 > I see the setting of CONTESTED in case of sleeping in mtx_lock_sleep! > But there is still the possibility that mtx_lock_sleep "just" obtains the= =20 lock=20 > and doesn't set contested-bit! See described case above (we reach first=20 > continue in mtx_lock_sleep and test on obtain_lock ends while-loop). In that case the lock won't have a turnstile, so mtx_unlock_sleep() will ne= ver=20 be called. > Why is this bit not tested in mtx_unlock_sleep? If the bit is clear the first attempt to unlock the mutex will succeed, and= =20 mtx_unlock_sleep() won't be called. > I think, it's still possible that turnstile_lookup returns NULL. > And we still have "MPASS(ts !=3D NULL);" in mtx_unlock_sleep that is not > turned on for GENERIC-kernel (no INVARIANTS support). It won't return NULL. > And I'm still wondering why the former test on "ts !=3D NULL" went away? As I mentioned, previously when a thread used to do an adaptive spin, it wo= uld=20 set the CONTESTED flag before spinning. This could result in the case that= a=20 mutex would have CONTESTED set, but not have an associated turnstile. Now= =20 that the adaptive spinning happens earlier before setting CONTESTED, mutexe= s=20 can no longer get into that state. That is, if CONTESTED is set, the mutex= =20 always has an assigned turnstile. If CONTESTED isn't set, then the first=20 attempt to unlock a mutex will succeed, and mtx_unlock_sleep() won't be=20 called at all. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 10 23:37:30 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7039E1065676 for ; Wed, 10 Sep 2008 23:37:30 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 002488FC14 for ; Wed, 10 Sep 2008 23:37:29 +0000 (UTC) (envelope-from artemb@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so660909uge.39 for ; Wed, 10 Sep 2008 16:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=eIXSTcDCTZXxMCmywMp291FtOCD/W8F6R3o4jnQ9MR8=; b=PUHYMfQI7kjTJUhfSzHNf2vlCN8HRMLL0sB94xy0ZzFVJX2O3VTaytgPYQnlOW3qyu LTUmdZASF2M5/hz0L9YdAaesUtQnj8mNkg3psA/KBD8ulkbUrHZNqmIWCCCFc+KS8aX3 63l8fw7a/cKlzDrnYl6Ez2vcVcX/pLPe64qt0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=gHElKbTHtdOlMkdNPg5GPEnyGGOMGQcSp9yF2C8LKKNRpS/YBerNqEWGFG49WtIjec qsnDj5WoC8VN/IAbs5Rt5k+U8Yh7Rp5YtF9zgI5WHKHUSJBtvVjyP8UMF/HLk3AIsmB5 /mQwbt5i+ms+uvh7v2kEMXbwI1PCx00qfEnsQ= Received: by 10.210.28.6 with SMTP id b6mr2259543ebb.60.1221088345922; Wed, 10 Sep 2008 16:12:25 -0700 (PDT) Received: by 10.210.128.7 with HTTP; Wed, 10 Sep 2008 16:12:25 -0700 (PDT) Message-ID: Date: Wed, 10 Sep 2008 16:12:25 -0700 From: "Artem Belevich" Sender: artemb@gmail.com To: "Alan Cox" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 439e3f780f22e249 Cc: freebsd-hackers@freebsd.org Subject: Increasing KVM on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2008 23:37:30 -0000 Alan, Thanks a lot for the patch. I've applied it to RELENG_7 and it seems to work great - "make -j8 buildworld" succeeds, linux emulation seems to work well enough to run linux-sun-jdk14 binaries, ZFS ARC size is bigger, too. So far I didn't see any ZFS-related KVM shortages either. The only problem is that everything is fine as long as vm.kmem_size is set to less or equal to 4096M. As soon as I set it to 4100M or anything larger, kernel crashes on startup. I'm unable to capture exact crash messages as they keep scrolling really fast on the screen for a few seconds until the box reboots. Unfortunately the box does not have built-in serial ports, so the messages are gone before I can see them. :-( Is there a way to bump up KVM size even further - beyond 6GB? I've got a box with 8GB or RAM and would like let ZFS ARC use most of it which would require pretty large vm.kmem_max to fit it in. Thanks, --Artem From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 11 04:28:03 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DB4D106567A for ; Thu, 11 Sep 2008 04:28:03 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 41B268FC0A for ; Thu, 11 Sep 2008 04:28:02 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id DGLD1a0010x6nqcA8GU2pY; Thu, 11 Sep 2008 04:28:02 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id DGU11a00G4v8bD78YGU1gx; Thu, 11 Sep 2008 04:28:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=0Rd2YH6fUOQvkwFQlekA:9 a=L6K6_LiR4vsDFuWi2F4A:7 a=Bi3p0S33P6UKe8ng53KumEo9o_UA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 5092717B81A; Wed, 10 Sep 2008 21:28:01 -0700 (PDT) Date: Wed, 10 Sep 2008 21:28:01 -0700 From: Jeremy Chadwick To: Artem Belevich Message-ID: <20080911042801.GA19245@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org, Alan Cox Subject: Re: Increasing KVM on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 04:28:03 -0000 On Wed, Sep 10, 2008 at 04:12:25PM -0700, Artem Belevich wrote: > Alan, > > Thanks a lot for the patch. I've applied it to RELENG_7 and it seems > to work great - "make -j8 buildworld" succeeds, linux emulation seems > to work well enough to run linux-sun-jdk14 binaries, ZFS ARC size is > bigger, too. So far I didn't see any ZFS-related KVM shortages either. > > The only problem is that everything is fine as long as vm.kmem_size is > set to less or equal to 4096M. As soon as I set it to 4100M or > anything larger, kernel crashes on startup. I'm unable to capture > exact crash messages as they keep scrolling really fast on the screen > for a few seconds until the box reboots. Unfortunately the box does > not have built-in serial ports, so the messages are gone before I can > see them. :-( > > Is there a way to bump up KVM size even further - beyond 6GB? I've got > a box with 8GB or RAM and would like let ZFS ARC use most of it which > would require pretty large vm.kmem_max to fit it in. I was told fairly recently (a few days ago) that the 6GB limit was increased to 512GB on HEAD/CURRENT. The 6GB limit was during a "transitional" phase of addressing the problem. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 11 05:24:50 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACF61106566B for ; Thu, 11 Sep 2008 05:24:50 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 3958C8FC12 for ; Thu, 11 Sep 2008 05:24:49 +0000 (UTC) (envelope-from artemb@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so79502eyi.7 for ; Wed, 10 Sep 2008 22:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=AJnvjT4/njiQ0H7SEcXw0ao7cae9kdfVUWxNXGl6IxA=; b=pyc/IVrW/uNCHHrIng8Jvt7+D+Ffzlo2K2yfFNER2rbhoc0sSvDN6hq18sAe5B2dzQ fUZJg54fSWvxnGfR5yImse3rPSiLT37wqCK+LVcOCF8mzx51O5M66KMLftx3QQDiQtxJ N9oUBUakqFk8GmKdtQKq5iZlVtOnlyofQlFts= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=nP5O9V3ldsfcKJlwocaVLveUcGYSZbhOEeneUxEcGt+4b3XVd1bsupx47LVjDZU2YJ AFQ1T8kuvSwFGdqPfhrUI1mPf+q4LJwqoTRj0ejQKjtkGK8XcM/8VL3D6zO3C6W5kisx UzeqYV8UBt6ayeocXOk0cZBveIdHorA+u2AUg= Received: by 10.210.41.14 with SMTP id o14mr2750364ebo.16.1221110688792; Wed, 10 Sep 2008 22:24:48 -0700 (PDT) Received: by 10.210.128.7 with HTTP; Wed, 10 Sep 2008 22:24:48 -0700 (PDT) Message-ID: Date: Wed, 10 Sep 2008 22:24:48 -0700 From: "Artem Belevich" Sender: artemb@gmail.com To: "Alan Cox" In-Reply-To: <48C8A78C.6070608@cs.rice.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48C8A78C.6070608@cs.rice.edu> X-Google-Sender-Auth: 2ea955c463c95f66 Cc: freebsd-hackers@freebsd.org Subject: Re: Increasing KVM on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 05:24:50 -0000 > SVN rev 180308 on 2008-07-05 19:34:33Z by alc > > Enable the creation of a kmem map larger than 4GB. > Submitted by: Tz-Huan Huang > > Make several variables related to kmem map auto-sizing static. > Found by: CScout I did apply Tz-Huan Huang's patch that he pointed to shortly after you've announced your patch. As far as I can tell it's identical to SVN rev 180308 changes. > Second, there is no room for a kmem map greater than 4GB unless the overall > KVM size is greater than 6GB. Specifically, a >4GB kmem map isn't possible > with 6GB KVM because the kmem map would overlap the kernel's code, data, and > bss segment. > > If you're able to apply the above kern_malloc.c change to your kernel, then > I should be able to describe how to increase your KVM beyond 6GB. I'd be glad to give it a try. -- --Artem From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 11 05:25:42 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 854801065670 for ; Thu, 11 Sep 2008 05:25:42 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 4FE858FC29 for ; Thu, 11 Sep 2008 05:25:42 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 057232C2D2E; Thu, 11 Sep 2008 00:07:26 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7KxbykW8z9YM; Thu, 11 Sep 2008 00:07:25 -0500 (CDT) Received: from [216.63.78.18] (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 2B8852C2D0F; Thu, 11 Sep 2008 00:07:25 -0500 (CDT) Message-ID: <48C8A78C.6070608@cs.rice.edu> Date: Thu, 11 Sep 2008 00:07:24 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20080722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Artem Belevich References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Alan Cox Subject: Re: Increasing KVM on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 05:25:42 -0000 Artem Belevich wrote: >Alan, > >Thanks a lot for the patch. I've applied it to RELENG_7 and it seems >to work great - "make -j8 buildworld" succeeds, linux emulation seems >to work well enough to run linux-sun-jdk14 binaries, ZFS ARC size is >bigger, too. So far I didn't see any ZFS-related KVM shortages either. > >The only problem is that everything is fine as long as vm.kmem_size is >set to less or equal to 4096M. As soon as I set it to 4100M or >anything larger, kernel crashes on startup. I'm unable to capture >exact crash messages as they keep scrolling really fast on the screen >for a few seconds until the box reboots. Unfortunately the box does >not have built-in serial ports, so the messages are gone before I can >see them. :-( > > > There are two underlying causes. First, the size of the kmem map, which holds the kernel's heap, is recorded in a 32-bit int. So, setting vm.kmem_size to 4100M is leading to integer overflow. The following change addresses this issue: sys/kern/kern_malloc.c Revision *1.167*: download - view: text , markup , annotated - select for diffs /Sat Jul 5 19:34:33 2008 UTC/ (2 months ago) by /alc/ Branches: MAIN CVS tags: HEAD Diff to: previous 1.166: preferred , colored Changes since revision 1.166: +11 -11 lines SVN rev 180308 on 2008-07-05 19:34:33Z by alc Enable the creation of a kmem map larger than 4GB. Submitted by: Tz-Huan Huang Make several variables related to kmem map auto-sizing static. Found by: CScout Second, there is no room for a kmem map greater than 4GB unless the overall KVM size is greater than 6GB. Specifically, a >4GB kmem map isn't possible with 6GB KVM because the kmem map would overlap the kernel's code, data, and bss segment. If you're able to apply the above kern_malloc.c change to your kernel, then I should be able to describe how to increase your KVM beyond 6GB. Regards, Alan From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 11 07:39:20 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D07991065674 for ; Thu, 11 Sep 2008 07:39:20 +0000 (UTC) (envelope-from rkramer@mweb.com) Received: from mwbmarshal.mweb.com (mwbmarshal.mweb.com [196.2.141.6]) by mx1.freebsd.org (Postfix) with ESMTP id 6AB358FC17 for ; Thu, 11 Sep 2008 07:39:18 +0000 (UTC) (envelope-from rkramer@mweb.com) Received: from mwbfes2.mweb.com (Not Verified[196.2.141.74]) by mwbmarshal.mweb.com with NetIQ MailMarshal 6.0 Service Pack 1 (v6, 0, 3, 28) id ; Thu, 11 Sep 2008 09:39:16 +0200 Received: from MWBEXCH.mweb.com ([196.2.141.75]) by mwbfes2.mweb.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 09:39:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Sep 2008 09:39:15 +0200 Message-ID: <39DC135F7F0571489196E0B6F5D58B4A03B460D0@MWBEXCH.mweb.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade Thread-Index: AckSBO2MoJKH6X6GRXGan7W/zTzrEgB2x2PQ References: From: "Rudi Kramer - MWEB" To: "Steven Hartland" , X-OriginalArrivalTime: 11 Sep 2008 07:39:16.0094 (UTC) FILETIME=[7E1981E0:01C913E1] Cc: Subject: RE: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 07:39:20 -0000 > Steven Hartland: > > Sent: Tuesday, September 09, 2008 12:28 AM > To: freebsd-hackers@freebsd.org > Subject: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade >=20 > I've been trying to install FreeBSD 7.0-RELEASE amd64 on > a Dell M600 Blade but it hangs just after initialising > the isa bus. >=20 > I've tried a number of things and the only thing that I > can get to work is the i386 build which boots into the > installer without issue. >=20 > Has anyone had any experience with the Dell M600 blade > on amd64 or had the amd64 build hang at this point > before. Hi Steven, We recently purchased a few M600's but haven't got around to loading FBSD on them, we should start installing next week and I will let you know if we run in to any problems. Regards Rudi From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 11 19:35:49 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE7A6106566C for ; Thu, 11 Sep 2008 19:35:49 +0000 (UTC) (envelope-from titanandrews@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 949CD8FC24 for ; Thu, 11 Sep 2008 19:35:48 +0000 (UTC) (envelope-from titanandrews@gmail.com) Received: by gxk10 with SMTP id 10so17180565gxk.19 for ; Thu, 11 Sep 2008 12:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=ZnbJV8CCMo2A6ZejpxjspIGM70YOYePMxENbwPD5TXA=; b=scpYyUlz4Cjxc8WYom0uneca9cWfZrCRCfvgM1RaYLWIcG5sjwXS4OHyknLIjBey/J dk+TM++4o2FyugzSLDBFXyEPo7MW4llPrp4sTkDcpDA7FbvXi6gNgM69DcIqDx0G7uwN Y+pMwD2WCU0IENhFmi3ivXnFBtXB+P/jDaAeo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=B+x2aBNn4YcK5U2yFXHMcAMew+EKWqbIQ/PXtO7pizzMzN6z3fAORDfSYMQfA+o1nR xKqJWnotadyQW8T6AzrWGXguzRIS1TW6lj1s8otyqX5idhQLOtrAxceEx+y5alhBXXcF a9OLbgIa63eZ6/eBdlzR3vyJC8s+mkxCZ9Xes= Received: by 10.100.12.2 with SMTP id 2mr1188719anl.143.1221159995764; Thu, 11 Sep 2008 12:06:35 -0700 (PDT) Received: by 10.100.154.2 with HTTP; Thu, 11 Sep 2008 12:06:35 -0700 (PDT) Message-ID: Date: Thu, 11 Sep 2008 15:06:35 -0400 From: "Barry Andrews" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: loading multi threaded library into executable enabled for single thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 19:35:50 -0000 Hi All, I have a multi-threaded library that is linked against libpthread. When I load this lib into a tclsh process on FreeBSD, I get this error, "Recurse on private mutex". and crash. I understand that I can have this issue when the executable is not linked against libpthread but one of the loaded libs is. Basically, it thinks it's in single threaded mode. I can get around this issue, by doing export LD_PRELOAD=libpthread.so.1, however this is a hack at best. Is there any other way to get around this issue other than linking tclsh with libpthread ( because that's not an option) I thought of re-building libpthread with the offending code commented out, and that did work, however I ran into other issues, so I think it's not a very "safe" option. My feeling is that this is a FreeBSD issue because it's not happening on other platforms, Linux, Solaris. Any suggestions are welcome. Many thanks! -B * * From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 11 19:56:05 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB27D1065676 for ; Thu, 11 Sep 2008 19:56:05 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 305AE8FC15 for ; Thu, 11 Sep 2008 19:56:05 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.2) with ESMTP id m8BJusmC054008; Thu, 11 Sep 2008 14:56:54 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id m8BJus4h054007; Thu, 11 Sep 2008 14:56:54 -0500 (CDT) (envelope-from brooks) Date: Thu, 11 Sep 2008 14:56:54 -0500 From: Brooks Davis To: Barry Andrews Message-ID: <20080911195653.GA53111@lor.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Thu, 11 Sep 2008 14:56:54 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Subject: Re: loading multi threaded library into executable enabled for single thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 19:56:05 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 11, 2008 at 03:06:35PM -0400, Barry Andrews wrote: > Hi All, >=20 > I have a multi-threaded library that is linked against libpthread. When I > load this lib into a tclsh process on FreeBSD, I get this error, "Recurse= on > private mutex". and crash. I understand that I can have this issue when t= he > executable is not linked against libpthread but one of the loaded libs is. > Basically, it thinks it's in single threaded mode. >=20 > I can get around this issue, by doing export LD_PRELOAD=3Dlibpthread.so.1, > however this is a hack at best. Is there any other way to get around this > issue other than linking tclsh with libpthread ( because that's not an > option) >=20 > I thought of re-building libpthread with the offending code commented out, > and that did work, however I ran into other issues, so I think it's not a > very "safe" option. >=20 > My feeling is that this is a FreeBSD issue because it's not happening on > other platforms, Linux, Solaris. >=20 > Any suggestions are welcome. Many thanks! It would be helpful if you could provide: - your FreeBSD version - the output of "ldd libyourlib.so" - the output of "ldd yourprogram" I wouldn't be supprised to find that the program and library are linked aga= inst different threading libraries. If so, one of them will need to be relinked= or you will need to use libmap.conf to cause it to use the other one. -- Brooks --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIyXgFXY6L6fI4GtQRAncEAKCGe+TUZcGZyOlG6EdT9z4oHw5rjwCfe50C 1F5AEnE1U3TeAc005pgi4Tc= =lsGy -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 11 19:56:31 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4922106566C for ; Thu, 11 Sep 2008 19:56:31 +0000 (UTC) (envelope-from jille@quis.cx) Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by mx1.freebsd.org (Postfix) with ESMTP id 466F68FC13 for ; Thu, 11 Sep 2008 19:56:30 +0000 (UTC) (envelope-from jille@quis.cx) Received: (qmail 17947 invoked by uid 0); 11 Sep 2008 19:29:50 -0000 Received: from ip83-113-174-82.adsl2.static.versatel.nl (HELO istud.quis.cx) ([82.174.113.83]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 11 Sep 2008 19:29:50 -0000 Received: from [192.168.1.4] (ille [192.168.1.4]) by istud.quis.cx (Postfix) with ESMTP id BD1B25C1D for ; Thu, 11 Sep 2008 21:29:48 +0200 (CEST) Message-ID: <48C971AC.6080001@quis.cx> Date: Thu, 11 Sep 2008 21:29:48 +0200 From: Jille Timmermans User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: hackers@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: readdir(somefile) returing inconsistent errors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 19:56:31 -0000 Hello, I was looking through some vop_readdir()'s, and noticed an inconsistency between (at least) xfs and unionfs. sys/fs/unionfs/union_vnops.c:1410: if(ap->a_vp->v_type != VDIR) return (ENOTDIR); sys/fs/xfs/FreeBSD/xfs_vnops.c:1001: if(vp->v_type != VDIR) return (EPERM); A little userland script gave me a ENOTDIR when trying to opendir(somefile) (userspace opendir() calling kernelspace readdir()). So I assume the check is made earlier, but shouldn't the xfs code return ENOTDIR in this case ? due to the if-clause above it, you'd say ENOTDIR seems better than EPERM. -- Jille From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 11 19:59:56 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BE571065673 for ; Thu, 11 Sep 2008 19:59:56 +0000 (UTC) (envelope-from jille@quis.cx) Received: from smtp6.versatel.nl (smtp6.versatel.nl [62.58.50.97]) by mx1.freebsd.org (Postfix) with ESMTP id BA6798FC1B for ; Thu, 11 Sep 2008 19:59:55 +0000 (UTC) (envelope-from jille@quis.cx) Received: (qmail 25993 invoked by uid 0); 11 Sep 2008 19:59:52 -0000 Received: from ip83-113-174-82.adsl2.static.versatel.nl (HELO istud.quis.cx) ([82.174.113.83]) (envelope-sender ) by smtp6.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 11 Sep 2008 19:59:52 -0000 Received: from [192.168.1.4] (ille [192.168.1.4]) by istud.quis.cx (Postfix) with ESMTP id C641E5C1D for ; Thu, 11 Sep 2008 21:59:51 +0200 (CEST) Message-ID: <48C978B7.3000803@quis.cx> Date: Thu, 11 Sep 2008 21:59:51 +0200 From: Jille Timmermans User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: hackers@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Filtering items in readdir() with own fs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 19:59:56 -0000 Hello all, I am trying to create a filesystem that works exactly like nullfs, but hides all .svn dirs (and contents) (Yes, I started with svn cp). I've got it working so far that it denies that the dirs and contents exist (grep isn't complaining; so I can finally grep -r through the source). But it would be nice if I can also hide the .svn dirs in dir listings. I have been looking through a few existing filesystems (unionfs, fdescfs, xfs, devfs). None gave me a good way for hiding specific entries in the listing. With some help of unionfs I have created a direct-pass-through using VOP_READDIR(), but I can't filter it with that. I tried using some xfs code, but didn't get any result with that. Can anyone give me a hint on where to start looking for code that could be used with filtering functionality ? Any file or function ? Thanks in advance, -- Jille From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 11 20:31:35 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCDB0106564A for ; Thu, 11 Sep 2008 20:31:35 +0000 (UTC) (envelope-from llc2w@virginia.edu) Received: from fork7.mail.virginia.edu (fork7.mail.Virginia.EDU [128.143.2.177]) by mx1.freebsd.org (Postfix) with ESMTP id 9615B8FC0A for ; Thu, 11 Sep 2008 20:31:35 +0000 (UTC) (envelope-from llc2w@virginia.edu) Received: from localhost (localhost [127.0.0.1]) by fork7.mail.virginia.edu (Postfix) with ESMTP id 37BA11F517A for ; Thu, 11 Sep 2008 16:05:46 -0400 (EDT) Received: from fork7.mail.virginia.edu ([127.0.0.1]) by localhost (fork7.mail.virginia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21967-02 for ; Thu, 11 Sep 2008 16:05:46 -0400 (EDT) Received: from mail-gx0-f10.google.com (mail-gx0-f10.google.com [209.85.217.10]) by fork7.mail.virginia.edu (Postfix) with ESMTP id 129561F5168 for ; Thu, 11 Sep 2008 16:05:46 -0400 (EDT) Received: by mail-gx0-f10.google.com with SMTP id 3so10686143gxk.0 for ; Thu, 11 Sep 2008 13:05:46 -0700 (PDT) Received: by 10.86.66.19 with SMTP id o19mr2454003fga.34.1221163543690; Thu, 11 Sep 2008 13:05:43 -0700 (PDT) Received: by 10.86.31.14 with HTTP; Thu, 11 Sep 2008 13:05:43 -0700 (PDT) Message-ID: <792298050809111305s5a4d4cbcxb56d7756b5af8879@mail.gmail.com> Date: Thu, 11 Sep 2008 16:05:43 -0400 From: "L Campbell" To: "Jille Timmermans" In-Reply-To: <48C978B7.3000803@quis.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48C978B7.3000803@quis.cx> X-UVA-Virus-Scanned: by amavisd-new at fork7.mail.virginia.edu Cc: hackers@freebsd.org Subject: Re: Filtering items in readdir() with own fs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 20:31:36 -0000 Just as a random comment, if you wanted to grep over a svn-managed directory hierarchy, you could simply do -- find . \! -ipath '*/.svn*' | xargs grep -H search_string On Thu, Sep 11, 2008 at 3:59 PM, Jille Timmermans wrote: > Hello all, > > > I am trying to create a filesystem that works exactly like nullfs, but > hides all .svn dirs (and contents) (Yes, I started with svn cp). > I've got it working so far that it denies that the dirs and contents > exist (grep isn't complaining; so I can finally grep -r through the source). > But it would be nice if I can also hide the .svn dirs in dir listings. > > > > I have been looking through a few existing filesystems (unionfs, > fdescfs, xfs, devfs). > None gave me a good way for hiding specific entries in the listing. > With some help of unionfs I have created a direct-pass-through using > VOP_READDIR(), but I can't filter it with that. > I tried using some xfs code, but didn't get any result with that. > > > > Can anyone give me a hint on where to start looking for code that could > be used with filtering functionality ? > Any file or function ? > > > Thanks in advance, > -- Jille > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 11 20:42:49 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2E951065674 for ; Thu, 11 Sep 2008 20:42:49 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8A46C8FC18 for ; Thu, 11 Sep 2008 20:42:49 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m8BKMc4k029952; Thu, 11 Sep 2008 16:22:38 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Thu, 11 Sep 2008 16:22:38 -0400 (EDT) Date: Thu, 11 Sep 2008 16:22:38 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Barry Andrews In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: loading multi threaded library into executable enabled for single thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 20:42:49 -0000 On Thu, 11 Sep 2008, Barry Andrews wrote: > Hi All, > > I have a multi-threaded library that is linked against libpthread. When I > load this lib into a tclsh process on FreeBSD, I get this error, "Recurse on > private mutex". and crash. I understand that I can have this issue when the > executable is not linked against libpthread but one of the loaded libs is. > Basically, it thinks it's in single threaded mode. This must be an older version of FreeBSD. I think you must link your application (tclsh or whatever) against libpthread in order for this to work. The libc functions won't get properly overloaded by their equivalents in libpthread unless you do this. -- DE From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 11 23:12:22 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B45F9106564A for ; Thu, 11 Sep 2008 23:12:22 +0000 (UTC) (envelope-from prvs=114023f9f1=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 2744C8FC26 for ; Thu, 11 Sep 2008 23:12:21 +0000 (UTC) (envelope-from prvs=114023f9f1=killing@multiplay.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1221174010; x=1221778810; q=dns/txt; h=Received: Message-ID:From:To:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=Pyk1ByOc/NsDceA71kBYm zhoXAuAZ5TwU/UAakGoPa8=; b=PQE6yaeI9PIH2rwGFfOFNj3Vckh9IQzGbAB2m Eq/4OztdXOT/F6wCfp4syVTwP1HyuJI8W+PI3FaxCm23G6Cw2I4FXpuPcxwHCYLa IuxUsZ6xtYZe4qiAIQx+QsYYy6+0hzEC9aFCTgXsUxs3icUBRQl8GMvcB/KFtxxx GhdbD8= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-14.7 required=6.0 tests=BAYES_00, FORGED_MUA_OUTLOOK, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.8 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v9.6.6) with ESMTP id md50006180097.msg for ; Fri, 12 Sep 2008 00:00:09 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 85.236.106.102 X-Return-Path: prvs=114023f9f1=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-ID: From: "Steven Hartland" To: "Rudi Kramer - MWEB" , References: <39DC135F7F0571489196E0B6F5D58B4A03B460D0@MWBEXCH.mweb.com> Date: Fri, 12 Sep 2008 00:00:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 12 Sep 2008 00:00:09 +0100 X-MDAV-Processed: mail1.multiplay.co.uk, Fri, 12 Sep 2008 00:00:10 +0100 Cc: Subject: Re: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 23:12:22 -0000 Thanks Rudi, would really like to get is sorted as they would make ideal app servers. ----- Original Message ----- From: "Rudi Kramer - MWEB" Hi Steven, We recently purchased a few M600's but haven't got around to loading FBSD on them, we should start installing next week and I will let you know if we run in to any problems. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 00:13:26 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A66A106566B for ; Fri, 12 Sep 2008 00:13:26 +0000 (UTC) (envelope-from titanandrews@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id 131A08FC0C for ; Fri, 12 Sep 2008 00:13:25 +0000 (UTC) (envelope-from titanandrews@gmail.com) Received: by an-out-0708.google.com with SMTP id b33so77527ana.13 for ; Thu, 11 Sep 2008 17:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=GUe3/lc5mo2qJOzT020fvNOqc1ocOdlIbj8KV5UiMYU=; b=vfE4NzD87MYQV4r+Iqg3fkaohUBr0PKrXl7r1XWx5ajlKX3VpbM7WybMlam/ugE/CV P2Agmut8+JSlU3w+dzUfubKWG8sV3ykb3wpamNauyWR/OjuDq3PoXHJYrr6NBE5A2I8t Ne6pOjHIf1gKCb4TUFsI2DcR8ht/SFLr4IcPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=IJ+QPe5IAG3cjcxwAm40MnHZlZ7QXiYX2n6kFcAc81E/GXBlvhNlZtkOm8mYBdZ5o+ +R1wBrW4dJrpzkwxIQ1xoSWALpH5HSfXtMaZXzDowgubxGKmZcgYK8ON7KAlDEeNoKH/ 1P66VyWEW6D3OGXpHEwYn7Lbvm67wiay+Z64M= Received: by 10.100.106.1 with SMTP id e1mr4471860anc.34.1221178405302; Thu, 11 Sep 2008 17:13:25 -0700 (PDT) Received: by 10.100.154.2 with HTTP; Thu, 11 Sep 2008 17:13:25 -0700 (PDT) Message-ID: Date: Thu, 11 Sep 2008 20:13:25 -0400 From: "Barry Andrews" To: "Brooks Davis" In-Reply-To: <20080911195653.GA53111@lor.one-eyed-alien.net> MIME-Version: 1.0 References: <20080911195653.GA53111@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: loading multi threaded library into executable enabled for single thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 00:13:26 -0000 FreeBSD version 5.5 output of ldd for my lib is: libbase.so: libutils.so => ./libutils.so (0x287e0000) libACE.so.5.5.6 => ./libACE.so.5.5.6 (0x2882d000) libxerces-c.so.27 => ./libxerces-c.so.27 (0x28976000) libsqlite3.so.8 => ./libsqlite3.so.8 (0x28d23000) libboost_regex-gcc40-mt-d-1_34.so.1.34.0 => ./libboost_regex-gcc40-mt-d-1_34.so.1.34.0 (0x28d76000) libstdc++.so.6 => ./libstdc++.so.6 (0x28e82000) libm.so.3 => /lib/libm.so.3 (0x28f53000) libgcc_s.so.1 => ./libgcc_s.so.1 (0x28f6e000) libpthread.so.1 => /usr/lib/libpthread.so.1 (0x28f78000) libc.so.5 => /lib/libc.so.5 (0x28079000) output of ldd for tclsh is: libtcl84.so.1 => /usr/local/lib/libtcl84.so.1 (0x28076000) libm.so.3 => /lib/libm.so.3 (0x28114000) libc.so.5 => /lib/libc.so.5 (0x2812f000) On Thu, Sep 11, 2008 at 3:56 PM, Brooks Davis wrote: > On Thu, Sep 11, 2008 at 03:06:35PM -0400, Barry Andrews wrote: > > Hi All, > > > > I have a multi-threaded library that is linked against libpthread. When I > > load this lib into a tclsh process on FreeBSD, I get this error, "Recurse > on > > private mutex". and crash. I understand that I can have this issue when > the > > executable is not linked against libpthread but one of the loaded libs > is. > > Basically, it thinks it's in single threaded mode. > > > > I can get around this issue, by doing export LD_PRELOAD=libpthread.so.1, > > however this is a hack at best. Is there any other way to get around this > > issue other than linking tclsh with libpthread ( because that's not an > > option) > > > > I thought of re-building libpthread with the offending code commented > out, > > and that did work, however I ran into other issues, so I think it's not a > > very "safe" option. > > > > My feeling is that this is a FreeBSD issue because it's not happening on > > other platforms, Linux, Solaris. > > > > Any suggestions are welcome. Many thanks! > > It would be helpful if you could provide: > - your FreeBSD version > - the output of "ldd libyourlib.so" > - the output of "ldd yourprogram" > > I wouldn't be supprised to find that the program and library are linked > against > different threading libraries. If so, one of them will need to be relinked > or > you will need to use libmap.conf to cause it to use the other one. > > -- Brooks > From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 06:26:20 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEAED1065674 for ; Fri, 12 Sep 2008 06:26:20 +0000 (UTC) (envelope-from kmf@fischer.org.za) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id C68D18FC24 for ; Fri, 12 Sep 2008 06:26:18 +0000 (UTC) (envelope-from kmf@fischer.org.za) Received: by fg-out-1718.google.com with SMTP id l26so411425fgb.35 for ; Thu, 11 Sep 2008 23:26:17 -0700 (PDT) Received: by 10.181.2.2 with SMTP id e2mr3169149bki.3.1221199434809; Thu, 11 Sep 2008 23:03:54 -0700 (PDT) Received: by 10.181.22.9 with HTTP; Thu, 11 Sep 2008 23:03:54 -0700 (PDT) Message-ID: Date: Fri, 12 Sep 2008 08:03:54 +0200 From: "Karl Fischer" To: "Steven Hartland" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <39DC135F7F0571489196E0B6F5D58B4A03B460D0@MWBEXCH.mweb.com> Cc: freebsd-hackers@freebsd.org, Rudi Kramer - MWEB Subject: Re: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 06:26:20 -0000 On Fri, Sep 12, 2008 at 01:00, Steven Hartland wrote: > Thanks Rudi, would really like to get is sorted as they would make > ideal app servers. > > ----- Original Message ----- From: "Rudi Kramer - MWEB" > > > Hi Steven, > > We recently purchased a few M600's but haven't got around to loading > FBSD on them, we should start installing next week and I will let you > know if we run in to any problems. I have the same problem on my M600 Blades has anyone tested the 7.1 Beta and I'm about to purchase more of them. Karl -- -------------------------------------------------- Karl Fischer |_|0|_| "Absence of evidence |_|_|0| is not evidence of absence" |0|0|0| Carl Sagan - http://fischer.org.za - -------------------------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 09:59:04 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A3C61065671 for ; Fri, 12 Sep 2008 09:59:04 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mx0.tdx.com (mx1.tdx.com [62.13.128.202]) by mx1.freebsd.org (Postfix) with ESMTP id 7C9298FC1E for ; Fri, 12 Sep 2008 09:59:03 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) X-Meat-Content: Unsure Received: from Slim64.dmpriest.net.uk (thebrick.dmpriest.net.uk [62.13.130.30]) (authenticated bits=0) by mx0.tdx.com (8.13.8/8.13.8/Kp) with ESMTP id m8CAHgg0095119 for ; Fri, 12 Sep 2008 11:17:42 +0100 (BST) Date: Fri, 12 Sep 2008 10:45:24 +0100 From: Karl Pielorz To: freebsd-hackers@freebsd.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ZFS w/failing drives - any equivalent of Solaris FMA? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 09:59:04 -0000 Hi, Recently, a ZFS pool on my FreeBSD box started showing lots of errors on one drive in a mirrored pair. The pool consists of around 14 drives (as 7 mirrored pairs), hung off of a couple of SuperMicro 8 port SATA controllers (1 drive of each pair is on each controller). One of the drives started picking up a lot of errors (by the end of things it was returning errors pretty much for any reads/writes issued) - and taking ages to complete the I/O's. However, ZFS kept trying to use the drive - e.g. as I attached another drive to the remaining 'good' drive in the mirrored pair, ZFS was still trying to read data off the failed drive (and remaining good one) in order to complete it's re-silver to the newly attached drive. Having posted on the Open Solaris ZFS list - it appears, under Solaris there's an 'FMA Engine' which communicates drive failures and the like to ZFS - advising ZFS when a drive should be marked as 'failed'. Is there anything similar to this on FreeBSD yet? - i.e. Does/can anything on the system tell ZFS "This drives experiencing failures" rather than ZFS just seeing lots of timed out I/O 'errors'? (as appears to be the case). In the end, the failing drive was timing out literally every I/O - I did recover the situation by detaching it from the pool (which hung the machine - probably caused by ZFS having to update the meta-data on all drives, including the failed one). A reboot bought the pool back, minus the 'failed' drive, so enough of the 'detach' must have completed. The newly attached drive completed the re-silver in half an hour (as opposed to an estimated 755 hours and climbing with the other drive still in the pool, limping along). -Kp From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 11:40:55 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF0101065672 for ; Fri, 12 Sep 2008 11:40:55 +0000 (UTC) (envelope-from titanandrews@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 8B1188FC0A for ; Fri, 12 Sep 2008 11:40:55 +0000 (UTC) (envelope-from titanandrews@gmail.com) Received: by gxk10 with SMTP id 10so18543219gxk.19 for ; Fri, 12 Sep 2008 04:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=fLJf9ue1XGX2LC2qrEdmB6+5juyezzVOo0znKWUSaSE=; b=gciOKvJLJu8U/36CDrtMhk1d7og1E2sBsuDhiLiEnhhIMY166VoNenz9ekydbNFs16 zCiu/F4qriRNztWDh5O8OvHuymKffEXK2xPzBBX5v9UfmadnAi9nWRimWCIPgXK7DqZl q49lxUgNZHCAAMNP9bg1mEGUG0yfH5myBj9aI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=KA+dV8ORRd9Vx8SfbQ2yk+vBqQuZNwVNm2X5Oudc3YfJem/1k4POPNSh3S39yGprIi 34nS4OXqvpPPrhm8Qeuani6TFnyuMfeAOCcUQIPODAnglNVvdMp3aT2jwAuPRwTSYJIe lHF3iuRNLac87vwxdKJIGJp18ykJar/RsMrFc= Received: by 10.100.229.14 with SMTP id b14mr5032258anh.43.1221219654335; Fri, 12 Sep 2008 04:40:54 -0700 (PDT) Received: from ?192.168.3.101? ( [71.0.189.248]) by mx.google.com with ESMTPS id 66sm12925028wra.33.2008.09.12.04.40.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Sep 2008 04:40:53 -0700 (PDT) Message-ID: <48CA555A.4050104@gmail.com> Date: Fri, 12 Sep 2008 07:41:14 -0400 From: Barry Andrews User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: loading multi threaded library into executable enabled for single thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 11:40:56 -0000 Do you know if this is documented in Release Notes or Known Issues or somewhere? thanks, B Daniel Eischen wrote: > On Thu, 11 Sep 2008, Barry Andrews wrote: > >> Hi All, >> >> I have a multi-threaded library that is linked against libpthread. >> When I >> load this lib into a tclsh process on FreeBSD, I get this error, >> "Recurse on >> private mutex". and crash. I understand that I can have this issue >> when the >> executable is not linked against libpthread but one of the loaded >> libs is. >> Basically, it thinks it's in single threaded mode. > > This must be an older version of FreeBSD. I think you must > link your application (tclsh or whatever) against libpthread > in order for this to work. The libc functions won't get properly > overloaded by their equivalents in libpthread unless you do > this. > From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 13:10:48 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCA28106567B for ; Fri, 12 Sep 2008 13:10:48 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 7031B8FC28 for ; Fri, 12 Sep 2008 13:10:48 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA05.westchester.pa.mail.comcast.net with comcast id DmlQ1a0070mv7h055pAnA2; Fri, 12 Sep 2008 13:10:47 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA11.westchester.pa.mail.comcast.net with comcast id DpAm1a00R4v8bD73XpAnm7; Fri, 12 Sep 2008 13:10:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=W33fUFesqP8A:10 a=p7sCquAJk-0A:10 a=QycZ5dHgAAAA:8 a=7r2qblK4LXpsiqaa7cUA:9 a=3ZBr7cIvv83aAWLw9ykA:7 a=R4bMjKT2j1v3HNqt5XiFFxi-8I8A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id E444B17B81A; Fri, 12 Sep 2008 06:10:45 -0700 (PDT) Date: Fri, 12 Sep 2008 06:10:45 -0700 From: Jeremy Chadwick To: Barry Andrews Message-ID: <20080912131045.GA56923@icarus.home.lan> References: <48CA555A.4050104@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48CA555A.4050104@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Daniel Eischen , freebsd-hackers@freebsd.org Subject: Re: loading multi threaded library into executable enabled for single thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 13:10:48 -0000 On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote: > Do you know if this is documented in Release Notes or Known Issues or > somewhere? Why would it be an "issue"? gcc -pthread and libpthread linking is documented pretty much everywhere on the web. There isn't anything broken about it, it's how it's done on older FreeBSD. Note that all of this has significantly changed in later FreeBSD versions, and that the 5.x series was deprecated a very long time ago. >> On Thu, 11 Sep 2008, Barry Andrews wrote: >> >>> Hi All, >>> >>> I have a multi-threaded library that is linked against libpthread. >>> When I >>> load this lib into a tclsh process on FreeBSD, I get this error, >>> "Recurse on >>> private mutex". and crash. I understand that I can have this issue >>> when the >>> executable is not linked against libpthread but one of the loaded >>> libs is. >>> Basically, it thinks it's in single threaded mode. >> >> This must be an older version of FreeBSD. I think you must >> link your application (tclsh or whatever) against libpthread >> in order for this to work. The libc functions won't get properly >> overloaded by their equivalents in libpthread unless you do >> this. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 13:21:04 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5EAE1065670 for ; Fri, 12 Sep 2008 13:21:04 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 851828FC14 for ; Fri, 12 Sep 2008 13:21:04 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id Dp7K1a00C1GXsucA4pM4cT; Fri, 12 Sep 2008 13:21:04 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id DpM21a00U4v8bD78TpM36v; Fri, 12 Sep 2008 13:21:03 +0000 X-Authority-Analysis: v=1.0 c=1 a=FEcCtSrf6_wA:10 a=SSZ9KyxJ8eYA:10 a=QycZ5dHgAAAA:8 a=MzONc8gBtlYMkQ8CHR0A:9 a=2IKYoY-TbCJQfB7gm3YRLnJDFmcA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id D50F917B81A; Fri, 12 Sep 2008 06:21:02 -0700 (PDT) Date: Fri, 12 Sep 2008 06:21:02 -0700 From: Jeremy Chadwick To: Karl Pielorz Message-ID: <20080912132102.GB56923@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org Subject: Re: ZFS w/failing drives - any equivalent of Solaris FMA? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 13:21:04 -0000 On Fri, Sep 12, 2008 at 10:45:24AM +0100, Karl Pielorz wrote: > Recently, a ZFS pool on my FreeBSD box started showing lots of errors on > one drive in a mirrored pair. > > The pool consists of around 14 drives (as 7 mirrored pairs), hung off of > a couple of SuperMicro 8 port SATA controllers (1 drive of each pair is > on each controller). > > One of the drives started picking up a lot of errors (by the end of > things it was returning errors pretty much for any reads/writes issued) - > and taking ages to complete the I/O's. > > However, ZFS kept trying to use the drive - e.g. as I attached another > drive to the remaining 'good' drive in the mirrored pair, ZFS was still > trying to read data off the failed drive (and remaining good one) in > order to complete it's re-silver to the newly attached drive. > > Having posted on the Open Solaris ZFS list - it appears, under Solaris > there's an 'FMA Engine' which communicates drive failures and the like to > ZFS - advising ZFS when a drive should be marked as 'failed'. > > Is there anything similar to this on FreeBSD yet? - i.e. Does/can > anything on the system tell ZFS "This drives experiencing failures" > rather than ZFS just seeing lots of timed out I/O 'errors'? (as appears > to be the case). As far as I know, there is no such "standard" mechanism in FreeBSD. If the drive falls off the bus entirely (e.g. detached), I would hope ZFS would notice that. I can imagine it (might) also depend on if the disk subsystem you're using is utilising CAM or not (e.g. disks should be daX not adX); Scott Long might know if something like this is implemented in CAM. I'm fairly certain nothing like this is implemented in ata(4). Ideally, it would be the job of the controller and controller driver to announce to underlying I/O operations fail/success. Do you agree? I hope this "FMA Engine" on Solaris only *tells* underlying pieces of I/O errors, rather than acting on them (e.g. automatically yanking the disk off the bus for you). I'm in no way shunning Solaris, I'm simply saying such a mechanism could be as risky/deadly as it could be useful. > In the end, the failing drive was timing out literally every I/O - I did > recover the situation by detaching it from the pool (which hung the > machine - probably caused by ZFS having to update the meta-data on all > drives, including the failed one). A reboot bought the pool back, minus > the 'failed' drive, so enough of the 'detach' must have completed. > > The newly attached drive completed the re-silver in half an hour (as > opposed to an estimated 755 hours and climbing with the other drive still > in the pool, limping along). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 13:26:39 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E83B7106564A for ; Fri, 12 Sep 2008 13:26:39 +0000 (UTC) (envelope-from titanandrews@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.188]) by mx1.freebsd.org (Postfix) with ESMTP id 917488FC18 for ; Fri, 12 Sep 2008 13:26:39 +0000 (UTC) (envelope-from titanandrews@gmail.com) Received: by rn-out-0910.google.com with SMTP id j71so572008rne.12 for ; Fri, 12 Sep 2008 06:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=8UHH5eLTD/8pv7d9gaHdtRqPylRS81Smy23LkNaAgBo=; b=te7eJxcW3zGfQC+Dg/5dltd3kqFu4/fCEjUMPBMpjyGOoyiMcGI5WbSQl6k/Ok+3uR Bb/LetEbyghPJVteeMRxsbrDCkTro7B0AyT5ISSw7T5DR1mk4ENOoh1FEruyVIFzRlh+ v4jd/Vvs2fuxpXH1UPcggdRLfc9RnDZLJUxmc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=M7OL/k6xVp0ZAAbiUEvpFOCzRzgKbVLGXi/kGgGJQtGnIlwzOoesWXZy6HDrOSzoQW SjOn/ePW99+vorEVUPp85GUUgE8AQNvyHwfC+WNcZ25+D/TdLOG4PXoNkSQVavciULh6 O0HEmxYAMpLQvsrrx5NtT5JJq4e5lgvfc0TWo= Received: by 10.100.6.13 with SMTP id 13mr5145475anf.83.1221225997635; Fri, 12 Sep 2008 06:26:37 -0700 (PDT) Received: by 10.100.45.6 with HTTP; Fri, 12 Sep 2008 06:26:37 -0700 (PDT) Message-ID: Date: Fri, 12 Sep 2008 09:26:37 -0400 From: "Barry Andrews" To: "Jeremy Chadwick" In-Reply-To: <20080912131045.GA56923@icarus.home.lan> MIME-Version: 1.0 References: <48CA555A.4050104@gmail.com> <20080912131045.GA56923@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Daniel Eischen , freebsd-hackers@freebsd.org Subject: Re: loading multi threaded library into executable enabled for single thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 13:26:40 -0000 I don't understand. If it was not broken, then why did it change in later FreeBSD versions? On Fri, Sep 12, 2008 at 9:10 AM, Jeremy Chadwick wrote: > On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote: > > Do you know if this is documented in Release Notes or Known Issues or > > somewhere? > > Why would it be an "issue"? gcc -pthread and libpthread linking is > documented pretty much everywhere on the web. There isn't anything > broken about it, it's how it's done on older FreeBSD. > > Note that all of this has significantly changed in later FreeBSD > versions, and that the 5.x series was deprecated a very long time ago. > > >> On Thu, 11 Sep 2008, Barry Andrews wrote: > >> > >>> Hi All, > >>> > >>> I have a multi-threaded library that is linked against libpthread. > >>> When I > >>> load this lib into a tclsh process on FreeBSD, I get this error, > >>> "Recurse on > >>> private mutex". and crash. I understand that I can have this issue > >>> when the > >>> executable is not linked against libpthread but one of the loaded > >>> libs is. > >>> Basically, it thinks it's in single threaded mode. > >> > >> This must be an older version of FreeBSD. I think you must > >> link your application (tclsh or whatever) against libpthread > >> in order for this to work. The libc functions won't get properly > >> overloaded by their equivalents in libpthread unless you do > >> this. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 13:51:14 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F1D31065680 for ; Fri, 12 Sep 2008 13:51:14 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id EE5928FC08 for ; Fri, 12 Sep 2008 13:51:13 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id Dpeo1a00D0lTkoCA7prCVF; Fri, 12 Sep 2008 13:51:12 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id DprA1a00N4v8bD78QprAlV; Fri, 12 Sep 2008 13:51:11 +0000 X-Authority-Analysis: v=1.0 c=1 a=W33fUFesqP8A:10 a=p7sCquAJk-0A:10 a=8yVQ4dpiAAAA:8 a=m0bHr2FCAAAA:8 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=tX5ATVMkEZMbQahsdFAA:9 a=vNBzgvwBMZHdyTv62joA:7 a=E44FLyHzg7z6zEUILW2T7uDyDtwA:4 a=EoioJ0NPDVgA:10 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 6A86D17B81A; Fri, 12 Sep 2008 06:51:10 -0700 (PDT) Date: Fri, 12 Sep 2008 06:51:10 -0700 From: Jeremy Chadwick To: Barry Andrews Message-ID: <20080912135110.GA57637@icarus.home.lan> References: <48CA555A.4050104@gmail.com> <20080912131045.GA56923@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Daniel Eischen , freebsd-hackers@freebsd.org Subject: Re: loading multi threaded library into executable enabled for single thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 13:51:14 -0000 On Fri, Sep 12, 2008 at 09:26:37AM -0400, Barry Andrews wrote: > I don't understand. If it was not broken, then why did it change in later > FreeBSD versions? I should be more explicit: the threading library and implementations have changed over time. There was libc_r, then there was libthr, then there was libkse. This is what we call "evolution". :-) http://www.unobvious.com/bsd/freebsd-threads.html http://kerneltrap.org/node/624 http://www.freebsd.org/kse/ The gcc -pthread flag is still there on present-day FreeBSD (6 through HEAD), and *should* be used. You can choose not to use it but you must ensure during linktime that you explicitly link to -lpthread. > On Fri, Sep 12, 2008 at 9:10 AM, Jeremy Chadwick wrote: > > > On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote: > > > Do you know if this is documented in Release Notes or Known Issues or > > > somewhere? > > > > Why would it be an "issue"? gcc -pthread and libpthread linking is > > documented pretty much everywhere on the web. There isn't anything > > broken about it, it's how it's done on older FreeBSD. > > > > Note that all of this has significantly changed in later FreeBSD > > versions, and that the 5.x series was deprecated a very long time ago. > > > > >> On Thu, 11 Sep 2008, Barry Andrews wrote: > > >> > > >>> Hi All, > > >>> > > >>> I have a multi-threaded library that is linked against libpthread. > > >>> When I > > >>> load this lib into a tclsh process on FreeBSD, I get this error, > > >>> "Recurse on > > >>> private mutex". and crash. I understand that I can have this issue > > >>> when the > > >>> executable is not linked against libpthread but one of the loaded > > >>> libs is. > > >>> Basically, it thinks it's in single threaded mode. > > >> > > >> This must be an older version of FreeBSD. I think you must > > >> link your application (tclsh or whatever) against libpthread > > >> in order for this to work. The libc functions won't get properly > > >> overloaded by their equivalents in libpthread unless you do > > >> this. > > > > -- > > | Jeremy Chadwick jdc at 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-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 14:37:05 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 200B5106566C for ; Fri, 12 Sep 2008 14:37:05 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mx0.tdx.com (mx1.tdx.com [62.13.128.202]) by mx1.freebsd.org (Postfix) with ESMTP id 90FD28FC0A for ; Fri, 12 Sep 2008 14:37:04 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) X-Meat-Content: Unsure Received: from Slim64.dmpriest.net.uk (thebrick.dmpriest.net.uk [62.13.130.30]) (authenticated bits=0) by mx0.tdx.com (8.13.8/8.13.8/Kp) with ESMTP id m8CF6se2005874; Fri, 12 Sep 2008 16:06:54 +0100 (BST) Date: Fri, 12 Sep 2008 15:34:30 +0100 From: Karl Pielorz To: Jeremy Chadwick Message-ID: <3BE629D093001F6BA2C6791C@Slim64.dmpriest.net.uk> In-Reply-To: <20080912132102.GB56923@icarus.home.lan> References: <20080912132102.GB56923@icarus.home.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org Subject: Re: ZFS w/failing drives - any equivalent of Solaris FMA? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 14:37:05 -0000 --On 12 September 2008 06:21 -0700 Jeremy Chadwick wrote: > As far as I know, there is no such "standard" mechanism in FreeBSD. If > the drive falls off the bus entirely (e.g. detached), I would hope ZFS > would notice that. I can imagine it (might) also depend on if the disk > subsystem you're using is utilising CAM or not (e.g. disks should be daX > not adX); Scott Long might know if something like this is implemented in > CAM. I'm fairly certain nothing like this is implemented in ata(4). For ATA, at the moment - I don't think it'll notice even if a drive detaches. I think like my system the other day, it'll just keep issuing I/O commands to the drive, even if it's disappeared (it might get much 'quicker failures' if the device has 'gone' to the point of FreeBSD just quickly returning 'fail' for every request). > Ideally, it would be the job of the controller and controller driver to > announce to underlying I/O operations fail/success. Do you agree? > > I hope this "FMA Engine" on Solaris only *tells* underlying pieces of > I/O errors, rather than acting on them (e.g. automatically yanking the > disk off the bus for you). I'm in no way shunning Solaris, I'm simply > saying such a mechanism could be as risky/deadly as it could be useful. Yeah, I guess so - I think the way it's meant to happen (and this is only AFAIK) is that FMA 'detects' a failing drive by applying some configurable policy to it. That policy would also include notifying ZFS, so that ZFS could then decide to stop issuing I/O commands to that device. None of this seems to be in place, at least for ATA under FreeBSD - when a drive goes bad, you can just end up with 'hours' worth of I/O timeouts, until someone intervenes. I did enquire on the Open Solaris list about setting limits for 'errors' in ZFS, which netted me a reply that it's FMA (at least in Solaris) that's responsible for this - it just then informs ZFS of the condition. We don't appear (again at least for ATA) to have anything similar for FreeBSD yet :( -Kp From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 15:00:23 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48CF81065676 for ; Fri, 12 Sep 2008 15:00:23 +0000 (UTC) (envelope-from titanandrews@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id E42128FC12 for ; Fri, 12 Sep 2008 15:00:22 +0000 (UTC) (envelope-from titanandrews@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so94794qwb.7 for ; Fri, 12 Sep 2008 08:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=8thqqAHmDn7GtpAETRSX8T/HPN7VAkTeWgs/LV6rSYA=; b=UoCcoQJqnEkb8s3PqP4DEZyLLk+FmNi6OEyUWR76TpZt0E0TlUYapRvvHWYfVhV5fj zzDQBa7Yo7GpwP5HdVcLUWRlpV80ynGbM0xDVrx0T9snCxKleOFfAR3r3tkywundxAPx z6zrAJdjbmGOUGgT+srNo+MTJGCnqH25wK5rU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=Xzf9n4L+SVncxeZlfcghbHIHKZw2tNX/I5/upI55NMVEBk3pv2VYJggCB6oChfIOWK QhKry+etFQYsMscPep2z5jOTFzwGq6+lXPfxWEQlhT2m/ZCdHQvJUTeZJ297laQ1zG2+ e190IQzRDZPxmoKWzQ3+2+MWQPfe673fiTKIQ= Received: by 10.214.10.4 with SMTP id 4mr4020900qaj.48.1221231621310; Fri, 12 Sep 2008 08:00:21 -0700 (PDT) Received: from ?192.168.3.101? ( [71.0.189.248]) by mx.google.com with ESMTPS id 2sm7814220qwi.5.2008.09.12.08.00.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Sep 2008 08:00:20 -0700 (PDT) Message-ID: <48CA8402.5040207@gmail.com> Date: Fri, 12 Sep 2008 11:00:18 -0400 From: Barry Andrews User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Jeremy Chadwick References: <48CA555A.4050104@gmail.com> <20080912131045.GA56923@icarus.home.lan> <20080912135110.GA57637@icarus.home.lan> In-Reply-To: <20080912135110.GA57637@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Daniel Eischen , freebsd-hackers@freebsd.org Subject: Re: loading multi threaded library into executable enabled for single thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 15:00:23 -0000 Thanks for the links! But I'm not sure what any of this has to do with this particular issue. I have an exe that does not use threads that loads a lib that is linked with libpthread. Why does different threading implementations affect what I am seeing here? Is there no way for this to work in FreeBSD v5.5? Why would this go away if I upgraded to 6.x or better? thanks, B Jeremy Chadwick wrote: > On Fri, Sep 12, 2008 at 09:26:37AM -0400, Barry Andrews wrote: > >> I don't understand. If it was not broken, then why did it change in later >> FreeBSD versions? >> > > I should be more explicit: the threading library and implementations > have changed over time. There was libc_r, then there was libthr, then > there was libkse. This is what we call "evolution". :-) > > http://www.unobvious.com/bsd/freebsd-threads.html > http://kerneltrap.org/node/624 > http://www.freebsd.org/kse/ > > The gcc -pthread flag is still there on present-day FreeBSD (6 through > HEAD), and *should* be used. You can choose not to use it but you must > ensure during linktime that you explicitly link to -lpthread. > > >> On Fri, Sep 12, 2008 at 9:10 AM, Jeremy Chadwick wrote: >> >> >>> On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote: >>> >>>> Do you know if this is documented in Release Notes or Known Issues or >>>> somewhere? >>>> >>> Why would it be an "issue"? gcc -pthread and libpthread linking is >>> documented pretty much everywhere on the web. There isn't anything >>> broken about it, it's how it's done on older FreeBSD. >>> >>> Note that all of this has significantly changed in later FreeBSD >>> versions, and that the 5.x series was deprecated a very long time ago. >>> >>> >>>>> On Thu, 11 Sep 2008, Barry Andrews wrote: >>>>> >>>>> >>>>>> Hi All, >>>>>> >>>>>> I have a multi-threaded library that is linked against libpthread. >>>>>> When I >>>>>> load this lib into a tclsh process on FreeBSD, I get this error, >>>>>> "Recurse on >>>>>> private mutex". and crash. I understand that I can have this issue >>>>>> when the >>>>>> executable is not linked against libpthread but one of the loaded >>>>>> libs is. >>>>>> Basically, it thinks it's in single threaded mode. >>>>>> >>>>> This must be an older version of FreeBSD. I think you must >>>>> link your application (tclsh or whatever) against libpthread >>>>> in order for this to work. The libc functions won't get properly >>>>> overloaded by their equivalents in libpthread unless you do >>>>> this. >>>>> >>> -- >>> | Jeremy Chadwick jdc at 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-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > > From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 15:44:30 2008 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C7B8106564A for ; Fri, 12 Sep 2008 15:44:30 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id E40DB8FC21 for ; Fri, 12 Sep 2008 15:44:29 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id m8CFiRce099726; Fri, 12 Sep 2008 17:44:28 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id m8CFiRHQ099725; Fri, 12 Sep 2008 17:44:27 +0200 (CEST) (envelope-from olli) Date: Fri, 12 Sep 2008 17:44:27 +0200 (CEST) Message-Id: <200809121544.m8CFiRHQ099725@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, kpielorz_lst@tdx.co.uk In-Reply-To: X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 12 Sep 2008 17:44:28 +0200 (CEST) Cc: Subject: Re: ZFS w/failing drives - any equivalent of Solaris FMA? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, kpielorz_lst@tdx.co.uk List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 15:44:30 -0000 Karl Pielorz wrote: > Recently, a ZFS pool on my FreeBSD box started showing lots of errors on > one drive in a mirrored pair. > > The pool consists of around 14 drives (as 7 mirrored pairs), hung off of a > couple of SuperMicro 8 port SATA controllers (1 drive of each pair is on > each controller). > > One of the drives started picking up a lot of errors (by the end of things > it was returning errors pretty much for any reads/writes issued) - and > taking ages to complete the I/O's. > > However, ZFS kept trying to use the drive - e.g. as I attached another > drive to the remaining 'good' drive in the mirrored pair, ZFS was still > trying to read data off the failed drive (and remaining good one) in order > to complete it's re-silver to the newly attached drive. > > Having posted on the Open Solaris ZFS list - it appears, under Solaris > there's an 'FMA Engine' which communicates drive failures and the like to > ZFS - advising ZFS when a drive should be marked as 'failed'. > > Is there anything similar to this on FreeBSD yet? - i.e. Does/can anything > on the system tell ZFS "This drives experiencing failures" rather than ZFS > just seeing lots of timed out I/O 'errors'? (as appears to be the case). > > In the end, the failing drive was timing out literally every I/O - I did > recover the situation by detaching it from the pool (which hung the machine > - probably caused by ZFS having to update the meta-data on all drives, > including the failed one). A reboot bought the pool back, minus the > 'failed' drive, so enough of the 'detach' must have completed. Did you try "atacontrol detach" to remove the disk from the bus? I haven't tried that with ZFS, but gmirror automatically detects when a disk has gone away, and doesn't try to do anything with it anymore. It certainly should not hang the machine. After all, what's the purpose of a RAID when you have to reboot upon drive failure. ;-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months." -- Cliff Sarginson From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 15:45:23 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08B471065675 for ; Fri, 12 Sep 2008 15:45:23 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id A04738FC28 for ; Fri, 12 Sep 2008 15:45:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA05.westchester.pa.mail.comcast.net with comcast id Do8y1a00M16LCl055rlMPG; Fri, 12 Sep 2008 15:45:21 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA06.westchester.pa.mail.comcast.net with comcast id DrlL1a00f4v8bD73SrlMQs; Fri, 12 Sep 2008 15:45:21 +0000 X-Authority-Analysis: v=1.0 c=1 a=W33fUFesqP8A:10 a=p7sCquAJk-0A:10 a=8yVQ4dpiAAAA:8 a=m0bHr2FCAAAA:8 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=ttG82ios6s9qFbvj2xsA:9 a=pLc0Znp-IxMBGA4h2WMA:7 a=n3CXdc4i2iKN08bbdPghbd78ksUA:4 a=EoioJ0NPDVgA:10 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 5FC6317B822; Fri, 12 Sep 2008 08:45:20 -0700 (PDT) Date: Fri, 12 Sep 2008 08:45:20 -0700 From: Jeremy Chadwick To: Barry Andrews Message-ID: <20080912154520.GA60094@icarus.home.lan> References: <48CA555A.4050104@gmail.com> <20080912131045.GA56923@icarus.home.lan> <20080912135110.GA57637@icarus.home.lan> <48CA8402.5040207@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48CA8402.5040207@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Daniel Eischen , freebsd-hackers@freebsd.org Subject: Re: loading multi threaded library into executable enabled for single thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 15:45:23 -0000 On Fri, Sep 12, 2008 at 11:00:18AM -0400, Barry Andrews wrote: > Thanks for the links! But I'm not sure what any of this has to do with > this particular issue. I have an exe that does not use threads that > loads a lib that is linked with libpthread. Why does different threading > implementations affect what I am seeing here? Is there no way for this > to work in FreeBSD v5.5? Why would this go away if I upgraded to 6.x or > better? You're confusing me. Earlier you said: >>>>>>> I have a multi-threaded library that is linked against libpthread. >>>>>>> When I >>>>>>> load this lib into a tclsh process on FreeBSD, I get this error, So what is "the exe?" Are you referring to tclsh? If so, you need to rebuild tclsh from source to link with libpthread. If not, you need to contact whoever provided the binary and ask them to rebuild it from source. Additionally, please ensure that the tclsh binary is linked to the same version of libpthread library as your own library. You want to make sure they're both built and linked on the same machine (from the same source code) if possible; the simple ".so.X" versioning method works great for major changes, but there are often minor changes that don't result in "X" being increased. I'm getting the impression that the tclsh binary you have was not built on the same machine / from the same source as what your library (the one linked with libpthread) was. > Jeremy Chadwick wrote: >> On Fri, Sep 12, 2008 at 09:26:37AM -0400, Barry Andrews wrote: >> >>> I don't understand. If it was not broken, then why did it change in later >>> FreeBSD versions? >>> >> >> I should be more explicit: the threading library and implementations >> have changed over time. There was libc_r, then there was libthr, then >> there was libkse. This is what we call "evolution". :-) >> >> http://www.unobvious.com/bsd/freebsd-threads.html >> http://kerneltrap.org/node/624 >> http://www.freebsd.org/kse/ >> >> The gcc -pthread flag is still there on present-day FreeBSD (6 through >> HEAD), and *should* be used. You can choose not to use it but you must >> ensure during linktime that you explicitly link to -lpthread. >> >> >>> On Fri, Sep 12, 2008 at 9:10 AM, Jeremy Chadwick wrote: >>> >>> >>>> On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote: >>>> >>>>> Do you know if this is documented in Release Notes or Known Issues or >>>>> somewhere? >>>>> >>>> Why would it be an "issue"? gcc -pthread and libpthread linking is >>>> documented pretty much everywhere on the web. There isn't anything >>>> broken about it, it's how it's done on older FreeBSD. >>>> >>>> Note that all of this has significantly changed in later FreeBSD >>>> versions, and that the 5.x series was deprecated a very long time ago. >>>> >>>> >>>>>> On Thu, 11 Sep 2008, Barry Andrews wrote: >>>>>> >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> I have a multi-threaded library that is linked against libpthread. >>>>>>> When I >>>>>>> load this lib into a tclsh process on FreeBSD, I get this error, >>>>>>> "Recurse on >>>>>>> private mutex". and crash. I understand that I can have this issue >>>>>>> when the >>>>>>> executable is not linked against libpthread but one of the loaded >>>>>>> libs is. >>>>>>> Basically, it thinks it's in single threaded mode. >>>>>>> >>>>>> This must be an older version of FreeBSD. I think you must >>>>>> link your application (tclsh or whatever) against libpthread >>>>>> in order for this to work. The libc functions won't get properly >>>>>> overloaded by their equivalents in libpthread unless you do >>>>>> this. >>>>>> >>>> -- >>>> | Jeremy Chadwick jdc at 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-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >>> >> >> > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 15:55:03 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C67E61065678 for ; Fri, 12 Sep 2008 15:55:03 +0000 (UTC) (envelope-from titanandrews@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 6B93C8FC25 for ; Fri, 12 Sep 2008 15:55:03 +0000 (UTC) (envelope-from titanandrews@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so342931yxb.13 for ; Fri, 12 Sep 2008 08:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=eVPKrCiTj0MEWGDe41/ZwCv9QaU7YokcDyzh103tJds=; b=uVgSbldRih15JQooc67eTul48CGwsGXVfhpVqPQP4+a2faf4hCAkqc8McqxRq3gjy+ uoaKelM7XGbY+lI5yeirkhCIlZFhGTOtUhTs1g4KaIe9BREtBCYJtTQXN5hzcjOkHGX2 ORdDTgDeHbWfP1fcnS1nGRyNSzguFoItELYCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=RgVYpGX/wYaV/3rDxPzo1zZycmRCyk+4VuxUvn88GizepGsZSkk7QIOf6AmHVCOmFd LSlwjORDexkVcpzu3s+9h+kUJjdQIaAVoZeLyxy8rBmr0COM38A6+EQCugQPCguQA0Ib 0t0XAFqfQcLXneFdtC8N6KNViYkex+jRdy6og= Received: by 10.100.152.11 with SMTP id z11mr5329816and.157.1221234901623; Fri, 12 Sep 2008 08:55:01 -0700 (PDT) Received: by 10.100.45.6 with HTTP; Fri, 12 Sep 2008 08:55:01 -0700 (PDT) Message-ID: Date: Fri, 12 Sep 2008 11:55:01 -0400 From: "Barry Andrews" To: "Jeremy Chadwick" In-Reply-To: <20080912154520.GA60094@icarus.home.lan> MIME-Version: 1.0 References: <48CA555A.4050104@gmail.com> <20080912131045.GA56923@icarus.home.lan> <20080912135110.GA57637@icarus.home.lan> <48CA8402.5040207@gmail.com> <20080912154520.GA60094@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Daniel Eischen , freebsd-hackers@freebsd.org Subject: Re: loading multi threaded library into executable enabled for single thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 15:55:03 -0000 Yes, the exe is tclsh. I understand that linking tclsh with libpthread is what would work. However this is very impractical. A user of my library shouldn't have to rebuild their tclsh to match my library specs. Another option would be to ship tclsh with my lib, but that also is a little weird. It seems like the only somewhat practical option I have is to use LD_PRELOAD, which is also weird but better than nothing. On Fri, Sep 12, 2008 at 11:45 AM, Jeremy Chadwick wrote: > On Fri, Sep 12, 2008 at 11:00:18AM -0400, Barry Andrews wrote: > > Thanks for the links! But I'm not sure what any of this has to do with > > this particular issue. I have an exe that does not use threads that > > loads a lib that is linked with libpthread. Why does different threading > > implementations affect what I am seeing here? Is there no way for this > > to work in FreeBSD v5.5? Why would this go away if I upgraded to 6.x or > > better? > > You're confusing me. Earlier you said: > > >>>>>>> I have a multi-threaded library that is linked against libpthread. > >>>>>>> When I > >>>>>>> load this lib into a tclsh process on FreeBSD, I get this error, > > So what is "the exe?" Are you referring to tclsh? If so, you need to > rebuild tclsh from source to link with libpthread. If not, you need to > contact whoever provided the binary and ask them to rebuild it from > source. > > Additionally, please ensure that the tclsh binary is linked to the same > version of libpthread library as your own library. You want to make > sure they're both built and linked on the same machine (from the same > source code) if possible; the simple ".so.X" versioning method works > great for major changes, but there are often minor changes that don't > result in "X" being increased. > > I'm getting the impression that the tclsh binary you have was not built > on the same machine / from the same source as what your library (the one > linked with libpthread) was. > > > Jeremy Chadwick wrote: > >> On Fri, Sep 12, 2008 at 09:26:37AM -0400, Barry Andrews wrote: > >> > >>> I don't understand. If it was not broken, then why did it change in > later > >>> FreeBSD versions? > >>> > >> > >> I should be more explicit: the threading library and implementations > >> have changed over time. There was libc_r, then there was libthr, then > >> there was libkse. This is what we call "evolution". :-) > >> > >> http://www.unobvious.com/bsd/freebsd-threads.html > >> http://kerneltrap.org/node/624 > >> http://www.freebsd.org/kse/ > >> > >> The gcc -pthread flag is still there on present-day FreeBSD (6 through > >> HEAD), and *should* be used. You can choose not to use it but you must > >> ensure during linktime that you explicitly link to -lpthread. > >> > >> > >>> On Fri, Sep 12, 2008 at 9:10 AM, Jeremy Chadwick > wrote: > >>> > >>> > >>>> On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote: > >>>> > >>>>> Do you know if this is documented in Release Notes or Known Issues or > >>>>> somewhere? > >>>>> > >>>> Why would it be an "issue"? gcc -pthread and libpthread linking is > >>>> documented pretty much everywhere on the web. There isn't anything > >>>> broken about it, it's how it's done on older FreeBSD. > >>>> > >>>> Note that all of this has significantly changed in later FreeBSD > >>>> versions, and that the 5.x series was deprecated a very long time ago. > >>>> > >>>> > >>>>>> On Thu, 11 Sep 2008, Barry Andrews wrote: > >>>>>> > >>>>>> > >>>>>>> Hi All, > >>>>>>> > >>>>>>> I have a multi-threaded library that is linked against libpthread. > >>>>>>> When I > >>>>>>> load this lib into a tclsh process on FreeBSD, I get this error, > >>>>>>> "Recurse on > >>>>>>> private mutex". and crash. I understand that I can have this issue > >>>>>>> when the > >>>>>>> executable is not linked against libpthread but one of the loaded > >>>>>>> libs is. > >>>>>>> Basically, it thinks it's in single threaded mode. > >>>>>>> > >>>>>> This must be an older version of FreeBSD. I think you must > >>>>>> link your application (tclsh or whatever) against libpthread > >>>>>> in order for this to work. The libc functions won't get properly > >>>>>> overloaded by their equivalents in libpthread unless you do > >>>>>> this. > >>>>>> > >>>> -- > >>>> | Jeremy Chadwick jdc at 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-hackers@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >>> To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > >>> > >> > >> > > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 15:59:09 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21A6F106564A for ; Fri, 12 Sep 2008 15:59:09 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id EC43A8FC1F for ; Fri, 12 Sep 2008 15:59:08 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 86FD81A013BBC for ; Fri, 12 Sep 2008 08:34:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fDDk9XTZsv7L for ; Fri, 12 Sep 2008 08:34:02 -0700 (PDT) Received: from coal (unknown [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id F2E521A01550B for ; Fri, 12 Sep 2008 08:33:28 -0700 (PDT) From: Freddie Cash To: freebsd-hackers@freebsd.org Date: Fri, 12 Sep 2008 08:33:27 -0700 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809120833.28233.fjwcash@gmail.com> Subject: Re: ZFS w/failing drives - any equivalent of Solaris FMA? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 15:59:09 -0000 On September 12, 2008 02:45 am Karl Pielorz wrote: > Recently, a ZFS pool on my FreeBSD box started showing lots of errors > on one drive in a mirrored pair. > > The pool consists of around 14 drives (as 7 mirrored pairs), hung off > of a couple of SuperMicro 8 port SATA controllers (1 drive of each pair > is on each controller). > > One of the drives started picking up a lot of errors (by the end of > things it was returning errors pretty much for any reads/writes issued) > - and taking ages to complete the I/O's. > > However, ZFS kept trying to use the drive - e.g. as I attached another > drive to the remaining 'good' drive in the mirrored pair, ZFS was still > trying to read data off the failed drive (and remaining good one) in > order to complete it's re-silver to the newly attached drive. For the one time I've had a drive fail, and the three times I've replaced drives for larger ones, the process used was: zpool offline zpool replace For one machine, I had to shut it off after the offline, as it didn't have hot-swappable drive bays. For the other machine, it did everything while online and running. IOW, the old device never had a chance to interfere with anything. Same process we've used with hardware RAID setups in the past. > Is there anything similar to this on FreeBSD yet? - i.e. Does/can > anything on the system tell ZFS "This drives experiencing failures" > rather than ZFS just seeing lots of timed out I/O 'errors'? (as appears > to be the case). Beyond the periodic script that checks for things like this, and sends root an e-mail, I haven't seen anything. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 16:04:24 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE159106566C for ; Fri, 12 Sep 2008 16:04:24 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id 754068FC12 for ; Fri, 12 Sep 2008 16:04:24 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA10.westchester.pa.mail.comcast.net with comcast id DmrA1a00E0EZKEL5As4Phn; Fri, 12 Sep 2008 16:04:23 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA01.westchester.pa.mail.comcast.net with comcast id Ds4N1a00T4v8bD73Ms4NfC; Fri, 12 Sep 2008 16:04:23 +0000 X-Authority-Analysis: v=1.0 c=1 a=FEcCtSrf6_wA:10 a=SSZ9KyxJ8eYA:10 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=XoE1bSP1LchlhW2H8VAA:9 a=NkPdreUv0pa2ltfZFd4A:7 a=nfdCUBxVQYYOlJzrFCF8LMMaOB0A:4 a=EoioJ0NPDVgA:10 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 3D36517B81A; Fri, 12 Sep 2008 09:04:22 -0700 (PDT) Date: Fri, 12 Sep 2008 09:04:22 -0700 From: Jeremy Chadwick To: Karl Pielorz Message-ID: <20080912160422.GB60094@icarus.home.lan> References: <20080912132102.GB56923@icarus.home.lan> <3BE629D093001F6BA2C6791C@Slim64.dmpriest.net.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BE629D093001F6BA2C6791C@Slim64.dmpriest.net.uk> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org Subject: Re: ZFS w/failing drives - any equivalent of Solaris FMA? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 16:04:24 -0000 On Fri, Sep 12, 2008 at 03:34:30PM +0100, Karl Pielorz wrote: > --On 12 September 2008 06:21 -0700 Jeremy Chadwick > wrote: > >> As far as I know, there is no such "standard" mechanism in FreeBSD. If >> the drive falls off the bus entirely (e.g. detached), I would hope ZFS >> would notice that. I can imagine it (might) also depend on if the disk >> subsystem you're using is utilising CAM or not (e.g. disks should be daX >> not adX); Scott Long might know if something like this is implemented in >> CAM. I'm fairly certain nothing like this is implemented in ata(4). > > For ATA, at the moment - I don't think it'll notice even if a drive > detaches. I think like my system the other day, it'll just keep issuing > I/O commands to the drive, even if it's disappeared (it might get much > 'quicker failures' if the device has 'gone' to the point of FreeBSD just > quickly returning 'fail' for every request). I know ATA will notice a detached channel, because I myself have done it: administratively, that is -- atacontrol detach ataX. But the only time that can happen "automatically" is if the actual controller does so itself, or if FreeBSD is told to do it administratively. What this does to other parts of the kernel and userland applications is something I haven't tested. I *can* tell you that there are major, major problems with detach/reattach/reinit on ata(4) causing kernel panics and other such things. I've documented this quite thoroughly in my "Common FreeBSD issues" wiki: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues I am also very curious to know the exact brand/model of 8-port SATA controller from Supermicro you are using, *especially* if it uses ata(4) rather than CAM and da(4). Such Supermicro controllers were recently discussed on freebsd-stable (or was it -hardware?), and no one was able to come to a concise decision as to whether or not they were decent or even remotely trusted. Supermicro provides a few different SATA HBAs. >> Ideally, it would be the job of the controller and controller driver to >> announce to underlying I/O operations fail/success. Do you agree? >> >> I hope this "FMA Engine" on Solaris only *tells* underlying pieces of >> I/O errors, rather than acting on them (e.g. automatically yanking the >> disk off the bus for you). I'm in no way shunning Solaris, I'm simply >> saying such a mechanism could be as risky/deadly as it could be useful. > > Yeah, I guess so - I think the way it's meant to happen (and this is only > AFAIK) is that FMA 'detects' a failing drive by applying some > configurable policy to it. That policy would also include notifying ZFS, > so that ZFS could then decide to stop issuing I/O commands to that > device. It sounds like that is done very differently than on FreeBSD. If such a condition happens on FreeBSD (disk errors scrolling by, etc.), the only way I know of to get FreeBSD to stop sending commands through the ATA subsystem is to detach the channel (atacontrol detach ataX). > None of this seems to be in place, at least for ATA under FreeBSD - when > a drive goes bad, you can just end up with 'hours' worth of I/O timeouts, > until someone intervenes. I can see the usefulness in Solaris's FMA thing. My big concern is whether or not FMA actually pulls the disk off the channel, or if it just leaves the disk/channel connected and simply informs kernel pieces not to use it. If it pulls the disk off the channel, I have serious qualms with it. There are also chips on SATA and SCSI controllers which can cause chaos as well -- specifically, SES/SES2 chips (I'm looking at you, QLogic). These are supposed to be "smart chips" that detect when there are a large number of transport or hardware errors (implying cabling issues, etc.) and *automatically* yank the disk off the bus. Sounds great on paper, but in the field, I see these chips start pulling disks off the bus, changing SCSI IDs on devices, or induce what appear to be full SCSI subsystem timeouts (e.g. the SES/SES2 chip has locked up/crashed in some way, and now your entire bus is dead in the water). I have seen all of the above bugs with onboard Adaptec 320 controllers, the systems running Solaris 8, 9, and OpenSolaris. Most times it turns out to be the SES/SES2 chip getting in the way. > I did enquire on the Open Solaris list about setting limits for 'errors' > in ZFS, which netted me a reply that it's FMA (at least in Solaris) > that's responsible for this - it just then informs ZFS of the condition. > We don't appear (again at least for ATA) to have anything similar for > FreeBSD yet :( My recommendation to people these days is to avoid ata(4) on FreeBSD at all costs if they expect to encounter disk or hardware failures. The ata(4) layer is in no way shape or form reliable in the case of transport or disk failures, and even sometimes in the case of hot- swapping. Try your hardest to find a physical controller that supports SATA disks and uses CAM/da(4), which WILL provide that reliability. I know Areca controllers do this, and Areca is very FreeBSD-friendly. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 16:04:30 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 240DA1065677 for ; Fri, 12 Sep 2008 16:04:30 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 802E18FC14 for ; Fri, 12 Sep 2008 16:04:29 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by gxk10 with SMTP id 10so19262776gxk.19 for ; Fri, 12 Sep 2008 09:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=tGQ8IDW29WnYAzKJWlmgfc5QnvqTRiucTjxvjlgjLiA=; b=esc99gYNwYQ5AfqJLVe1pz5KSe7Ga56C35kYIK60fXIVXVaq5tUBzLE4FB7slm2Xc+ TSf9IVY3Epm+IdnZ34yfAR13ApbTnqGgMHg2QDFMnhVxGv9ieV1zFmBCtXdAUqxF7kf/ RLJsE17WfvDBpYjC/vhA7KB4b3X/YrGts70dw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=HHvfBAWz3TnBGDXTKB7/HbdgaVWTG62bItj5UBOIggPrMDIl4+lTD1605WMIVtP3rS fVLIuqIA91NAN9cQlCaxalEgzZa+xaC5gAqppTFQGuCIsCIqGlusrV7SOQ5fLT4cIMiI HgPeav+cFlM1O54KhlWkPrIo0/+6Mo9NiShEU= Received: by 10.151.102.16 with SMTP id e16mr6285117ybm.153.1221235467665; Fri, 12 Sep 2008 09:04:27 -0700 (PDT) Received: by 10.150.137.11 with HTTP; Fri, 12 Sep 2008 09:04:27 -0700 (PDT) Message-ID: <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> Date: Fri, 12 Sep 2008 12:04:27 -0400 From: "Zaphod Beeblebrox" To: freebsd-hackers@freebsd.org, kpielorz_lst@tdx.co.uk In-Reply-To: <200809121544.m8CFiRHQ099725@lurza.secnetix.de> MIME-Version: 1.0 References: <200809121544.m8CFiRHQ099725@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: ZFS w/failing drives - any equivalent of Solaris FMA? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 16:04:30 -0000 On Fri, Sep 12, 2008 at 11:44 AM, Oliver Fromme wrote: > Did you try "atacontrol detach" to remove the disk from > the bus? I haven't tried that with ZFS, but gmirror > automatically detects when a disk has gone away, and > doesn't try to do anything with it anymore. It certainly > should not hang the machine. After all, what's the > purpose of a RAID when you have to reboot upon drive > failure. ;-) To be fair, many "home" users run RAID without the expectation of being able to hot swap the drives. While RAID can provide high availability, but it can also provide simple data security. In my home environment, I have a number of machines running. I have a few things on non-redundant disks --- mostly operating systems or local archives of internet data (like a cvsup server, for instance). Those disks can be lost, and while it's a nuisance, it's not catastrophic. Other things (from family photos to mp3s to other media) I keep on home RAID arrays. They're not hot swap... but I've had quite a few disks go bad over the years. I actually welcome ZFS for this --- the idea that checksums are kepts makes me feel a lot more secure about my data. I have observed some bitrot over time on some data. To your point... I suppose you have to reboot at some point after the drive failure, but my experience has been that the reboot has been under my control some time after the failure (usually when I have the replacement drive). For the home user, this can be quite inexpensive, too. I've found a case that can take 19 drives internally (and has good cooling for about $125). If you used some of the 5-to-3 drive bays, that number would increase to 25. About the only real improvement I'd like to see in this setup is the ability to spin down idle drives. That would be an ideal setup for the home RAID array. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 16:09:03 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45CB11065678 for ; Fri, 12 Sep 2008 16:09:03 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id DB3EC8FC13 for ; Fri, 12 Sep 2008 16:09:02 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA02.westchester.pa.mail.comcast.net with comcast id DnEr1a0080Fqzac52s8zTC; Fri, 12 Sep 2008 16:08:59 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA08.westchester.pa.mail.comcast.net with comcast id Ds901a00E4v8bD73Us91FV; Fri, 12 Sep 2008 16:09:01 +0000 X-Authority-Analysis: v=1.0 c=1 a=W33fUFesqP8A:10 a=p7sCquAJk-0A:10 a=8yVQ4dpiAAAA:8 a=m0bHr2FCAAAA:8 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=puySSPv6-TM_xX-tvskA:9 a=d743vpzSxQgDJrNN56kA:7 a=fbVaiX4-4UmRGBJpbGvoTXeJhp0A:4 a=EoioJ0NPDVgA:10 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 6390117B81A; Fri, 12 Sep 2008 09:09:00 -0700 (PDT) Date: Fri, 12 Sep 2008 09:09:00 -0700 From: Jeremy Chadwick To: Barry Andrews Message-ID: <20080912160900.GC60094@icarus.home.lan> References: <48CA555A.4050104@gmail.com> <20080912131045.GA56923@icarus.home.lan> <20080912135110.GA57637@icarus.home.lan> <48CA8402.5040207@gmail.com> <20080912154520.GA60094@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Daniel Eischen , freebsd-hackers@freebsd.org Subject: Re: loading multi threaded library into executable enabled for single thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 16:09:03 -0000 On Fri, Sep 12, 2008 at 11:55:01AM -0400, Barry Andrews wrote: > Yes, the exe is tclsh. I understand that linking tclsh with libpthread is > what would work. However this is very impractical. A user of my library > shouldn't have to rebuild their tclsh to match my library specs. Another > option would be to ship tclsh with my lib, but that also is a little weird. > It seems like the only somewhat practical option I have is to use > LD_PRELOAD, which is also weird but better than nothing. This really isn't a "FreeBSD problem", as the same sort of issue plagues other operating systems. When it comes to threading, you want *everything* threaded as much as possible -- mix-matching usually does not work. The only OS I have seen where that kind of environment works reliably is Solaris. I still feel threading is "too new" of a technology on UNIX. Your options as I see them: 1) Require your users to ensure they have a threaded TCL installation, and do not promise support in the case they try to use your library on a non-threaded installation, 1) Provide two versions of your library -- a threaded and non-threaded version. This may be impractical for performance reasons, 3) Require LD_PRELOAD, which is ugly, agreed. I think those are pretty much the only options you have at this point. Not a great set, I know, but it's reality. > On Fri, Sep 12, 2008 at 11:45 AM, Jeremy Chadwick wrote: > > > On Fri, Sep 12, 2008 at 11:00:18AM -0400, Barry Andrews wrote: > > > Thanks for the links! But I'm not sure what any of this has to do with > > > this particular issue. I have an exe that does not use threads that > > > loads a lib that is linked with libpthread. Why does different threading > > > implementations affect what I am seeing here? Is there no way for this > > > to work in FreeBSD v5.5? Why would this go away if I upgraded to 6.x or > > > better? > > > > You're confusing me. Earlier you said: > > > > >>>>>>> I have a multi-threaded library that is linked against libpthread. > > >>>>>>> When I > > >>>>>>> load this lib into a tclsh process on FreeBSD, I get this error, > > > > So what is "the exe?" Are you referring to tclsh? If so, you need to > > rebuild tclsh from source to link with libpthread. If not, you need to > > contact whoever provided the binary and ask them to rebuild it from > > source. > > > > Additionally, please ensure that the tclsh binary is linked to the same > > version of libpthread library as your own library. You want to make > > sure they're both built and linked on the same machine (from the same > > source code) if possible; the simple ".so.X" versioning method works > > great for major changes, but there are often minor changes that don't > > result in "X" being increased. > > > > I'm getting the impression that the tclsh binary you have was not built > > on the same machine / from the same source as what your library (the one > > linked with libpthread) was. > > > > > Jeremy Chadwick wrote: > > >> On Fri, Sep 12, 2008 at 09:26:37AM -0400, Barry Andrews wrote: > > >> > > >>> I don't understand. If it was not broken, then why did it change in > > later > > >>> FreeBSD versions? > > >>> > > >> > > >> I should be more explicit: the threading library and implementations > > >> have changed over time. There was libc_r, then there was libthr, then > > >> there was libkse. This is what we call "evolution". :-) > > >> > > >> http://www.unobvious.com/bsd/freebsd-threads.html > > >> http://kerneltrap.org/node/624 > > >> http://www.freebsd.org/kse/ > > >> > > >> The gcc -pthread flag is still there on present-day FreeBSD (6 through > > >> HEAD), and *should* be used. You can choose not to use it but you must > > >> ensure during linktime that you explicitly link to -lpthread. > > >> > > >> > > >>> On Fri, Sep 12, 2008 at 9:10 AM, Jeremy Chadwick > > wrote: > > >>> > > >>> > > >>>> On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote: > > >>>> > > >>>>> Do you know if this is documented in Release Notes or Known Issues or > > >>>>> somewhere? > > >>>>> > > >>>> Why would it be an "issue"? gcc -pthread and libpthread linking is > > >>>> documented pretty much everywhere on the web. There isn't anything > > >>>> broken about it, it's how it's done on older FreeBSD. > > >>>> > > >>>> Note that all of this has significantly changed in later FreeBSD > > >>>> versions, and that the 5.x series was deprecated a very long time ago. > > >>>> > > >>>> > > >>>>>> On Thu, 11 Sep 2008, Barry Andrews wrote: > > >>>>>> > > >>>>>> > > >>>>>>> Hi All, > > >>>>>>> > > >>>>>>> I have a multi-threaded library that is linked against libpthread. > > >>>>>>> When I > > >>>>>>> load this lib into a tclsh process on FreeBSD, I get this error, > > >>>>>>> "Recurse on > > >>>>>>> private mutex". and crash. I understand that I can have this issue > > >>>>>>> when the > > >>>>>>> executable is not linked against libpthread but one of the loaded > > >>>>>>> libs is. > > >>>>>>> Basically, it thinks it's in single threaded mode. > > >>>>>>> > > >>>>>> This must be an older version of FreeBSD. I think you must > > >>>>>> link your application (tclsh or whatever) against libpthread > > >>>>>> in order for this to work. The libc functions won't get properly > > >>>>>> overloaded by their equivalents in libpthread unless you do > > >>>>>> this. > > >>>>>> > > >>>> -- > > >>>> | Jeremy Chadwick jdc at 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-hackers@freebsd.org mailing list > > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > >>> To unsubscribe, send any mail to " > > freebsd-hackers-unsubscribe@freebsd.org" > > >>> > > >> > > >> > > > > > > _______________________________________________ > > > freebsd-hackers@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > > To unsubscribe, send any mail to " > > freebsd-hackers-unsubscribe@freebsd.org" > > > > -- > > | Jeremy Chadwick jdc at 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-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 16:10:55 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 306A11065672 for ; Fri, 12 Sep 2008 16:10:55 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 11C618FC27 for ; Fri, 12 Sep 2008 16:10:54 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id Dpie1a00617UAYkA8sAu0k; Fri, 12 Sep 2008 16:10:54 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id DsAs1a00N4v8bD78ZsAtjz; Fri, 12 Sep 2008 16:10:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=FEcCtSrf6_wA:10 a=SSZ9KyxJ8eYA:10 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=U0Ns0KDTOM0-s9TmXLMA:9 a=M2jwZ-4510svHMCRuSadmzLhF_QA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id CE2F417B81A; Fri, 12 Sep 2008 09:10:52 -0700 (PDT) Date: Fri, 12 Sep 2008 09:10:52 -0700 From: Jeremy Chadwick To: Karl Pielorz Message-ID: <20080912161052.GD60094@icarus.home.lan> References: <20080912132102.GB56923@icarus.home.lan> <3BE629D093001F6BA2C6791C@Slim64.dmpriest.net.uk> <20080912160422.GB60094@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080912160422.GB60094@icarus.home.lan> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org Subject: Re: ZFS w/failing drives - any equivalent of Solaris FMA? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 16:10:55 -0000 On Fri, Sep 12, 2008 at 09:04:22AM -0700, Jeremy Chadwick wrote: > What this does to other parts of the kernel and userland applications is > something I haven't tested. I *can* tell you that there are major, > major problems with detach/reattach/reinit on ata(4) causing kernel > panics and other such things. I've documented this quite thoroughly in > my "Common FreeBSD issues" wiki: > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues This should have read: "... in my ATA/SATA issues and troubleshooting methods page": http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 16:12:04 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC6A2106564A; Fri, 12 Sep 2008 16:12:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 489938FC13; Fri, 12 Sep 2008 16:12:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KeBFa-000688-AF; Fri, 12 Sep 2008 19:12:02 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8CGBxuk030308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2008 19:11:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8CGBwbJ041194; Fri, 12 Sep 2008 19:11:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id m8CGBwj8041192; Fri, 12 Sep 2008 19:11:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Sep 2008 19:11:58 +0300 From: Kostik Belousov To: Jeremy Chadwick Message-ID: <20080912161158.GL39652@deviant.kiev.zoral.com.ua> References: <48CA555A.4050104@gmail.com> <20080912131045.GA56923@icarus.home.lan> <20080912135110.GA57637@icarus.home.lan> <48CA8402.5040207@gmail.com> <20080912154520.GA60094@icarus.home.lan> <20080912160900.GC60094@icarus.home.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RWntzN4uhMukjMHt" Content-Disposition: inline In-Reply-To: <20080912160900.GC60094@icarus.home.lan> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KeBFa-000688-AF b945a9ce78cdeaba9941dcf739772ebf X-Terabit: YES Cc: Daniel Eischen , freebsd-hackers@freebsd.org, Barry Andrews Subject: Re: loading multi threaded library into executable enabled for single thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 16:12:04 -0000 --RWntzN4uhMukjMHt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 12, 2008 at 09:09:00AM -0700, Jeremy Chadwick wrote: > On Fri, Sep 12, 2008 at 11:55:01AM -0400, Barry Andrews wrote: > > Yes, the exe is tclsh. I understand that linking tclsh with libpthread = is > > what would work. However this is very impractical. A user of my library > > shouldn't have to rebuild their tclsh to match my library specs. Another > > option would be to ship tclsh with my lib, but that also is a little we= ird. > > It seems like the only somewhat practical option I have is to use > > LD_PRELOAD, which is also weird but better than nothing. >=20 > This really isn't a "FreeBSD problem", as the same sort of issue plagues > other operating systems. When it comes to threading, you want > *everything* threaded as much as possible -- mix-matching usually does > not work. The only OS I have seen where that kind of environment works > reliably is Solaris. I still feel threading is "too new" of a Yeah, they merged libpthread and libc some time ago, AFAIR :). --RWntzN4uhMukjMHt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjKlM4ACgkQC3+MBN1Mb4iT4wCeOJBDDQx5enlv0rdg3pMw3Xyq Q6AAn0J3j1/pjGpALafRS92/W5E4YvUX =0s+k -----END PGP SIGNATURE----- --RWntzN4uhMukjMHt-- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 16:16:10 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96DB31065675 for ; Fri, 12 Sep 2008 16:16:10 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by mx1.freebsd.org (Postfix) with ESMTP id 4BCA18FC1F for ; Fri, 12 Sep 2008 16:16:10 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so194511wra.27 for ; Fri, 12 Sep 2008 09:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=OARKhhHDvpDZpgm/lhoxUv6JyVurTtZInXRwkhHu+nI=; b=neqnCxyjoL9u64631UXNLFk1Kx6eVS+su/8GWT4ZFEFhuMFSM90HJ+gEgS85cIHT2N fWTrCQxlLJ4xShcZQJLyx4f0+qOzJrJPmQ6G4YyMixA21c4ft1Y4xnlTRf1dYuXJvZK/ 3indmwWpg0BjIQgotN82LD2nRbfwoxipcvuoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=MQ6v03RSTW1ScxxrMrRT+nUat1/XALyCwcckERvLVKSzfQJSfnA5zPUVAPgBuige3Q OF1HsVFRiP9ofu775tlvhfAf+XxlCSIiOJbKF/KDXksLfqmhZSYloyohx3JIFeMB8GfA fN1gCHpA6ducekIY0lc9nInSNuq+W5Z8N2E2Q= Received: by 10.151.112.4 with SMTP id p4mr6295725ybm.103.1221234641107; Fri, 12 Sep 2008 08:50:41 -0700 (PDT) Received: by 10.150.137.11 with HTTP; Fri, 12 Sep 2008 08:50:41 -0700 (PDT) Message-ID: <5f67a8c40809120850u60c23fc4m7c4c1341fb2c4966@mail.gmail.com> Date: Fri, 12 Sep 2008 11:50:41 -0400 From: "Zaphod Beeblebrox" To: "Karl Pielorz" In-Reply-To: <3BE629D093001F6BA2C6791C@Slim64.dmpriest.net.uk> MIME-Version: 1.0 References: <20080912132102.GB56923@icarus.home.lan> <3BE629D093001F6BA2C6791C@Slim64.dmpriest.net.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick Subject: Re: ZFS w/failing drives - any equivalent of Solaris FMA? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 16:16:10 -0000 On Fri, Sep 12, 2008 at 10:34 AM, Karl Pielorz wrote: > --On 12 September 2008 06:21 -0700 Jeremy Chadwick > wrote: > > As far as I know, there is no such "standard" mechanism in FreeBSD. If >> the drive falls off the bus entirely (e.g. detached), I would hope ZFS >> would notice that. I can imagine it (might) also depend on if the disk >> subsystem you're using is utilising CAM or not (e.g. disks should be daX >> not adX); Scott Long might know if something like this is implemented in >> CAM. I'm fairly certain nothing like this is implemented in ata(4). >> > > For ATA, at the moment - I don't think it'll notice even if a drive > detaches. I think like my system the other day, it'll just keep issuing I/O > commands to the drive, even if it's disappeared (it might get much 'quicker > failures' if the device has 'gone' to the point of FreeBSD just quickly > returning 'fail' for every request). Since I had the opportunity, I tested this recently for both CAM and ATA. Now the RAID engine was gmirror in both cases (my production hardware doesn't do ZFS yet), but I expect the reaction to be somewhat the same. Both systems were Dell 1U's. One, an R200, had SATA disks attached to a plain SATA controller. I believe it may have supported RAID1, but I didn't use that functionality. When a drive was removed from it, it stalled for some time (30 minutes?) and then resumed working. by the time I could type on the machine again, gmirror had decided that the drive was gone and marked the mirror as degraded. The other system was a 1950-III with a SCSI SAS controller attached to an SAS hot-swap backplane. The drives themselves were 750G SATA drives. Yanking one of them resulted in about 5 seconds of disruption followed by gmirror realizing the problem and marking the mirror degraded. Neither system was heavily loaded during the test. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 16:32:10 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92E0E1065676 for ; Fri, 12 Sep 2008 16:32:10 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 7520C8FC13 for ; Fri, 12 Sep 2008 16:32:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id DlgF1a0060vp7WLA2sY8xH; Fri, 12 Sep 2008 16:32:08 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id DsY71a00b4v8bD78RsY8SG; Fri, 12 Sep 2008 16:32:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=FEcCtSrf6_wA:10 a=SSZ9KyxJ8eYA:10 a=QycZ5dHgAAAA:8 a=A83LeEqSZlcB8MI0kgwA:9 a=VikVsTUK0H0in_DGzq8A:7 a=lDfpnWc1vJKTIVBhB1BSMSoH6J0A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 9EC2917B81A; Fri, 12 Sep 2008 09:32:07 -0700 (PDT) Date: Fri, 12 Sep 2008 09:32:07 -0700 From: Jeremy Chadwick To: Zaphod Beeblebrox Message-ID: <20080912163207.GE60094@icarus.home.lan> References: <200809121544.m8CFiRHQ099725@lurza.secnetix.de> <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org, kpielorz_lst@tdx.co.uk Subject: Re: ZFS w/failing drives - any equivalent of Solaris FMA? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 16:32:10 -0000 On Fri, Sep 12, 2008 at 12:04:27PM -0400, Zaphod Beeblebrox wrote: > On Fri, Sep 12, 2008 at 11:44 AM, Oliver Fromme wrote: > > Did you try "atacontrol detach" to remove the disk from > > the bus? I haven't tried that with ZFS, but gmirror > > automatically detects when a disk has gone away, and > > doesn't try to do anything with it anymore. It certainly > > should not hang the machine. After all, what's the > > purpose of a RAID when you have to reboot upon drive > > failure. ;-) > > To be fair, many "home" users run RAID without the expectation of being able > to hot swap the drives. While RAID can provide high availability, but it > can also provide simple data security. RAID only ensures a very, very tiny part of "data security", and it depends greatly on what RAID implementation you use. No RAID implementation I know of provides against transparent data corruption ("bit-rot"), and many RAID controllers and RAID drivers have bugs that induce corruption (to date, that's (very old ATA) Highpoint chips, nVidia/nForce chips, JMicron or Silicon Image chips -- all of these are used on consumer boards). A big problem is also that end-users *still* think RAID is a replacement for doing backups. :-( > To your point... I suppose you have to reboot at some point after the drive > failure, but my experience has been that the reboot has been under my > control some time after the failure (usually when I have the replacement > drive). For home use, sure. Since most home/consumer systems do not include hot-swappable drive bays, rebooting is required. Although more and more consumer motherboards are offering AHCI -- which is the only reliable way you'll get that capability with SATA. In my case with servers in a co-lo, it's not acceptable. Our systems contain SATA backplanes that support hot-swapping, and it works how it should (yank the disk, replace with a new one) on Linux -- there is no need to do a bunch of hoopla like on FreeBSD. On FreeBSD, with that hoopla, also take the risk of inducing a kernel panic. That risk does not sit well with me, but thankfully I've only been in that situation (replacing a bad disk + using hot-swapping) once -- and it did work. At my home, I have a pseudo-NAS system running FreeBSD. The case is from Supermicro, a mid-tower, and has a SATA backplane that supports hot-swapping. I use ZFS on this system, sporting 3 disks and one (non-ZFS) for boot/OS. But because I'm using ata(4) -- see above. Individuals on -stable and other lists using ZFS have posted their experiences with disk failures. I believe to date I've seen one which worked flawlessly, and the others reporting strange issues with resilvering, or in a couple cases, lost all their zpools permanently. Of course, it's very rare in this day and age for people to mail a mailing list reporting *successes* with something -- people usually only mail if something *fails*. :-) That said, pjd@'s dedication to getting ZFS working reliably on FreeBSD is outstanding. It's a great filesystem replacement, and even the Linux folks are a bit jealous over how simple and painless it is. I can share their jealousy -- I've looked at the LVM docs... never again. > About the only real improvement I'd like to see in this setup is the ability > to spin down idle drives. That would be an ideal setup for the home RAID > array. There is a FreeBSD port which handles this, although such a feature should ideally be part of the ata(4) system (as should TCQ/NCQ and a slew of other things -- some of those are being worked on). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 16:44:28 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1D3C106564A for ; Fri, 12 Sep 2008 16:44:28 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7726F8FC08 for ; Fri, 12 Sep 2008 16:44:28 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m8CGiQfo004127; Fri, 12 Sep 2008 12:44:27 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Fri, 12 Sep 2008 12:44:27 -0400 (EDT) Date: Fri, 12 Sep 2008 12:44:26 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Barry Andrews In-Reply-To: <48CA555A.4050104@gmail.com> Message-ID: References: <48CA555A.4050104@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: loading multi threaded library into executable enabled for single thread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 16:44:28 -0000 On Fri, 12 Sep 2008, Barry Andrews wrote: > Do you know if this is documented in Release Notes or Known Issues or > somewhere? No, but it's certainly in the -threads or -ports mailing list archives from a few years ago ;-) -- DE From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 16:47:23 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 063ED1065685 for ; Fri, 12 Sep 2008 16:47:23 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id AD31C8FC2C for ; Fri, 12 Sep 2008 16:47:22 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so354253ywe.13 for ; Fri, 12 Sep 2008 09:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=wAseeKx8eg26UwtnNyvKmuW8HXV4KtQUh7xwICqQRus=; b=NFoZu2x9uqJNI9jkHTuBSSH9d2s1Gcmpz4oLrF6I9h2eB0J//MeJwUeuYDt2bFpzp0 8ivz4zTWqBWLy6iSqOqHmVAl98c7aYGepgUKwy+iLh6YpOH95+k2sbZzfmRfiwflKjHj 4Tgz2ZMxZNfP7Wrz8iOFLrD92Gd2oFonhLhy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=Z4PZe2LXT+okcepiTmt+8qSJbGwtPm1LfRcguSJYQvAQRjc/zQr5viI74DnTl/cIgt U4b/cOfTmhOipSQsR/yIFY5PEuOknYHo4GdyJRuY/T6r+1cChYuV2pZaWmGlEvSlNpZf 195yyDd0HZPC9jHcx+d9eauz4c0uKUL8O+5CI= Received: by 10.151.156.12 with SMTP id i12mr6314461ybo.217.1221238041367; Fri, 12 Sep 2008 09:47:21 -0700 (PDT) Received: by 10.150.137.11 with HTTP; Fri, 12 Sep 2008 09:47:21 -0700 (PDT) Message-ID: <5f67a8c40809120947u2bbeb03cnb20618e1d9ddf6b8@mail.gmail.com> Date: Fri, 12 Sep 2008 12:47:21 -0400 From: "Zaphod Beeblebrox" To: "Jeremy Chadwick" In-Reply-To: <20080912163207.GE60094@icarus.home.lan> MIME-Version: 1.0 References: <200809121544.m8CFiRHQ099725@lurza.secnetix.de> <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> <20080912163207.GE60094@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, kpielorz_lst@tdx.co.uk Subject: Re: ZFS w/failing drives - any equivalent of Solaris FMA? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 16:47:23 -0000 On Fri, Sep 12, 2008 at 12:32 PM, Jeremy Chadwick wrote: > On Fri, Sep 12, 2008 at 12:04:27PM -0400, Zaphod Beeblebrox wrote: > > On Fri, Sep 12, 2008 at 11:44 AM, Oliver Fromme >wrote: > > > Did you try "atacontrol detach" to remove the disk from > > > the bus? I haven't tried that with ZFS, but gmirror > > > automatically detects when a disk has gone away, and > > > doesn't try to do anything with it anymore. It certainly > > > should not hang the machine. After all, what's the > > > purpose of a RAID when you have to reboot upon drive > > > failure. ;-) > > > > To be fair, many "home" users run RAID without the expectation of being > able > > to hot swap the drives. While RAID can provide high availability, but it > > can also provide simple data security. > > RAID only ensures a very, very tiny part of "data security", and it > depends greatly on what RAID implementation you use. No RAID > implementation I know of provides against transparent data corruption > ("bit-rot"), and many RAID controllers and RAID drivers have bugs that Well... this is/was a thread about ZFS. ZFS does detect that bitrot _and_ correct it if it is possible. > A big problem is also that end-users *still* think RAID is a replacement > for doing backups Well... this comment seems a bit off topic, but maybe (in some cases) RAID is a substitute for doing backups. I suppose it depends on your tolerance and data value. The sheer size of some datasets these days makes backup prohibitively time consuming and/or expensive. Then again (this is a ZFS thread), ZFS helps with this: the ability to export snapshots to other spinning spool makes a lot of sense. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 17:12:31 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00D2C1065675 for ; Fri, 12 Sep 2008 17:12:31 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id CBA828FC23 for ; Fri, 12 Sep 2008 17:12:30 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 42CB31A000B38 for ; Fri, 12 Sep 2008 10:12:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jpPHbJjMIY9C for ; Fri, 12 Sep 2008 10:12:20 -0700 (PDT) Received: from coal (unknown [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id B0C711A012070 for ; Fri, 12 Sep 2008 10:12:10 -0700 (PDT) From: Freddie Cash To: freebsd-hackers@freebsd.org Date: Fri, 12 Sep 2008 10:12:09 -0700 User-Agent: KMail/1.9.9 References: <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> <20080912163207.GE60094@icarus.home.lan> In-Reply-To: <20080912163207.GE60094@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809121012.10195.fjwcash@gmail.com> Subject: Re: ZFS w/failing drives - any equivalent of Solaris FMA? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 17:12:31 -0000 On September 12, 2008 09:32 am Jeremy Chadwick wrote: > For home use, sure. Since most home/consumer systems do not include > hot-swappable drive bays, rebooting is required. Although more and > more consumer motherboards are offering AHCI -- which is the only > reliable way you'll get that capability with SATA. > > In my case with servers in a co-lo, it's not acceptable. Our systems > contain SATA backplanes that support hot-swapping, and it works how it > should (yank the disk, replace with a new one) on Linux -- there is no > need to do a bunch of hoopla like on FreeBSD. On FreeBSD, with that > hoopla, also take the risk of inducing a kernel panic. That risk does > not sit well with me, but thankfully I've only been in that situation > (replacing a bad disk + using hot-swapping) once -- and it did work. Hrm, is this with software RAID or hardware RAID? With our hardware RAID systems, the process has always been the same, regardless of which OS (Windows 2003 Servers, Debian Linux, FreeBSD) is on the system: - go into RAID management GUI, remove drive - pull dead drive from system - insert new drive into system - go into RAID management GUI, make sure it picked up new drive and started the rebuild We've been lucky so far, and not had to do any drive replacements on our non-ZFS software RAID systems (md on Debian, gmirror on FreeBSD). I'm not looking forward to a drive failing, as these systems have non-hot-pluggable SATA setups. On the ZFS systems, we just "zpool offline" the drive, physically replace the drive, and "zpool replace" the drive. On one system, this was done via hot-pluggable SATA backplane, on another, it required a reboot. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 18:22:37 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 869371065674 for ; Fri, 12 Sep 2008 18:22:37 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 69E728FC18 for ; Fri, 12 Sep 2008 18:22:37 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id DtWY1a0040EPchoA4uNdbN; Fri, 12 Sep 2008 18:22:37 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id DuNb1a00Y4v8bD78MuNc6n; Fri, 12 Sep 2008 18:22:36 +0000 X-Authority-Analysis: v=1.0 c=1 a=FEcCtSrf6_wA:10 a=SSZ9KyxJ8eYA:10 a=QycZ5dHgAAAA:8 a=D_HWRfpMJYFIkFXSiXsA:9 a=R9ANlix2jvog273o3ewA:7 a=fxdJgh-zXqg-5lFS96MCL21dCW8A:4 a=EoioJ0NPDVgA:10 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id C0B1917B81A; Fri, 12 Sep 2008 11:22:35 -0700 (PDT) Date: Fri, 12 Sep 2008 11:22:35 -0700 From: Jeremy Chadwick To: Freddie Cash Message-ID: <20080912182235.GA62771@icarus.home.lan> References: <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> <20080912163207.GE60094@icarus.home.lan> <200809121012.10195.fjwcash@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809121012.10195.fjwcash@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org Subject: Re: ZFS w/failing drives - any equivalent of Solaris FMA? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 18:22:37 -0000 On Fri, Sep 12, 2008 at 10:12:09AM -0700, Freddie Cash wrote: > On September 12, 2008 09:32 am Jeremy Chadwick wrote: > > For home use, sure. Since most home/consumer systems do not include > > hot-swappable drive bays, rebooting is required. Although more and > > more consumer motherboards are offering AHCI -- which is the only > > reliable way you'll get that capability with SATA. > > > > In my case with servers in a co-lo, it's not acceptable. Our systems > > contain SATA backplanes that support hot-swapping, and it works how it > > should (yank the disk, replace with a new one) on Linux -- there is no > > need to do a bunch of hoopla like on FreeBSD. On FreeBSD, with that > > hoopla, also take the risk of inducing a kernel panic. That risk does > > not sit well with me, but thankfully I've only been in that situation > > (replacing a bad disk + using hot-swapping) once -- and it did work. > > Hrm, is this with software RAID or hardware RAID? I do not use either, but have tried software RAID (Intel MatrixRAID) in the past (and major, MAJOR bugs are why I do not any longer). Speaking (mostly) strictly of FreeBSD, let me list off the problems with both: Software RAID: 1) Buggy as hell. Using Intel MatrixRAID as an example, even with RAID 1, due to ata(4) driver bugs, you are practically guaranteed to lose your data, 3) Limited userland interface to RAID BIOS; many operations do not work with atacontrol, requiring a system reboot + entering BIOS to do things like add/remove disks or rebuild an array 3) SMART monitoring lost; if the card or BIOS supports passthrough (basically ATA version of pass(4)), FreeBSD will see the disks natively (e.g. arX for the RAID, ad4 and ad8 for the disks), and you can use smartmontools. Otherwise, you're screwed 4) Support is questionable; numerous mainstream chips unsupported, including Adaptec HostRAID Hardware RAID: 1) You are "locked in" to that controller. Your data is at the mercy of the company who makes the HBA; if your controller dies and is no longer made, your data is dead in the water. Chances are a newer model/revision of controller will not understand the the disk metadata from the previous controller 2) Performance problems as a result of excessive caching levels; onboard hardware cache vs. system memory cache vs. disk layer cache in OS vs. other kernel caching mechanisms 3) Controller firmware upgrades are risky -- 3Ware has a very nasty history of this, for sake of example. I've heard of some upgrades changing the metadata format, requiring complete array re-creation I can pull Ade Lovett into this conversation if you think any of the above is exaggerated. :-) The only hardware RAID controller I'd trust at this point would be Areca -- but hardware RAID is not what I want. On the other hand, I really want Areca to make a standard 4 or 8-port SATA controller -- no RAID, but full driver support under arcmsr(4) (which uses CAM and da(4)). This would be perfect. > With our hardware RAID systems, the process has always been the same, > regardless of which OS (Windows 2003 Servers, Debian Linux, FreeBSD) is > on the system: > - go into RAID management GUI, remove drive > - pull dead drive from system > - insert new drive into system > - go into RAID management GUI, make sure it picked up new drive and > started the rebuild The simplicity there is correct -- that's really how simple it should be. But a GUI? What card is this that requires a GUI? Does it require a reboot? No command-line support? > We've been lucky so far, and not had to do any drive replacements on our > non-ZFS software RAID systems (md on Debian, gmirror on FreeBSD). I'm > not looking forward to a drive failing, as these systems have > non-hot-pluggable SATA setups. I'm hearing you loud and clear. :-) > On the ZFS systems, we just "zpool offline" the drive, physically replace > the drive, and "zpool replace" the drive. On one system, this was done > via hot-pluggable SATA backplane, on another, it required a reboot. If this was done on the hardware RAID controller (presuming it uses CAM and da(4)), I'm not surprised it worked perfectly. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 12 19:45:55 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1CE01065675; Fri, 12 Sep 2008 19:45:55 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from lorca.tdx.co.uk (lorca.tdx.co.uk [62.13.128.6]) by mx1.freebsd.org (Postfix) with ESMTP id 51E148FC1E; Fri, 12 Sep 2008 19:45:55 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from Quadro64.tdx.co.uk (rainbow.tdx.co.uk [62.13.130.232] (may be forged)) (authenticated bits=0) by lorca.tdx.co.uk (8.14.0/8.14.0/Kp) with ESMTP id m8CJXEBs010145; Fri, 12 Sep 2008 20:33:15 +0100 (BST) Date: Fri, 12 Sep 2008 20:31:18 +0100 From: Karl Pielorz To: Jeremy Chadwick Message-ID: In-Reply-To: <20080912160422.GB60094@icarus.home.lan> References: <20080912132102.GB56923@icarus.home.lan> <3BE629D093001F6BA2C6791C@Slim64.dmpriest.net.uk> <20080912160422.GB60094@icarus.home.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org Subject: Re: ZFS w/failing drives - any equivalent of Solaris FMA? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 19:45:55 -0000 --On 12 September 2008 09:04 -0700 Jeremy Chadwick wrote: > I know ATA will notice a detached channel, because I myself have done > it: administratively, that is -- atacontrol detach ataX. But the only > time that can happen "automatically" is if the actual controller does > so itself, or if FreeBSD is told to do it administratively. I think the problem at the moment is, ZFS "doesn't care" - it's deliberately remote from things like drivers, and drives - and at the moment, there's no 'middle layer' or way for at least the ATA drivers to communicate to ZFS that a drive 'has failed' (I mean, for starters, you've got the problem of "what's a failed drive" - presumably a drive that's operating outside a set of limits? - The first probably being 'is it still attached?' :) That was a thread recently on the Open Solaris ZFS forum - and discussed at length... > I am also very curious to know the exact brand/model of 8-port SATA > controller from Supermicro you are using, *especially* if it uses ata(4) > rather than CAM and da(4). The controllers ID as: Marvell 88SX6081 SATA300 controller They're SuperMicro 8 PORT PCI-X SATA controllers, 'AOC-SAT2-MV8' - and they definitely show as 'adX' > Such Supermicro controllers were recently > discussed on freebsd-stable (or was it -hardware?), and no one was able > to come to a concise decision as to whether or not they were decent or > even remotely trusted. Supermicro provides a few different SATA HBAs. Well, I've tested these cards for a number of months now, and they seem fine here - at least with the WD drives I'm currently running (not saying they're 'perfect' - but for my setup, I've not seen any issues). I didn't notice any 'bad behaviour' when testing them under UFS, and when running under ZFS they've picked up no checksum errors (or console messages) for the duration the box has been running. > I can see the usefulness in Solaris's FMA thing. My big concern is > whether or not FMA actually pulls the disk off the channel, or if it > just leaves the disk/channel connected and simply informs kernel pieces > not to use it. If it pulls the disk off the channel, I have serious > qualms with it. I don't think it pulls it - I think it's looks at it's policies, and does what they say, which would seem to be the equivalent of 'zpool offline dev' by default (which, again doesn't pull it off any busses - it just notifies ZFS not to send I/O to that device). I'll have to do a test using da / CAM driven disks (or ask someone who worked on the port ;) - but I'd guess, unless there's something been added to CAM to tell ZFS to offline the disk, it'll do the same - i.e. ZFS will continue to issue I/O requests to disks as it needs - as at least in Open Solaris, it's deemed *not* to be ZFS's job to detect failed disks, or do anything about them - other than what it's told. ZFS under FreeBSD still works despite this (and works wonderfully well) - it just means if any of your drives 'go out to lunch' - unless they fail in such a way that the I/O requests are returned immediately as 'failed' (i.e. I guess if the device node has gone) - ZFS will keep issuing (and potentially pausing) waiting for I/O requests to failed drives, because it doesn't know, doesn't care - and hasn't been told to do otherwise. -Kp From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 13 05:28:05 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4B1E106566C for ; Sat, 13 Sep 2008 05:28:05 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.177]) by mx1.freebsd.org (Postfix) with ESMTP id 068638FC25 for ; Sat, 13 Sep 2008 05:28:04 +0000 (UTC) (envelope-from artemb@gmail.com) Received: by ik-out-1112.google.com with SMTP id c29so1001722ika.3 for ; Fri, 12 Sep 2008 22:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=4zriJweGWF3lFW1BW5nds3J56XOV1tO82VMfFhH/5us=; b=sZnymKneK7BvzXFeB55m7bUkEv/GDRAfWw+mS3HXVx4NQLnD8qYFtfTmrXha+qlBzw uJd7a5vvWPJxD6pktD4PLJ6pYOMEttHQCPYzb2Q1xra+oFPjkpcZaFq97pJaCt+tI/Di U9fbCVkDjB4g+Vvd8QUJLxZyECn9ZnxrJZe2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=eGK+O4H1cBklhoSSP6OX0Zn9eYYUOMh/seCcqLk8gZlJzDly/4OXEbO5Tnr86TIsQK M8Sk+jB/+CTSH9b3qPZLqDGkxIdY2K5hq0YeA8N8r3qtpEZuykHzu2t8RmQQqwiPH8TG Y3atOy4i0RM0eEI5SM+JK0FddgnQNvTCeJr1M= Received: by 10.210.62.12 with SMTP id k12mr4826711eba.15.1221283683746; Fri, 12 Sep 2008 22:28:03 -0700 (PDT) Received: by 10.210.128.7 with HTTP; Fri, 12 Sep 2008 22:28:03 -0700 (PDT) Message-ID: Date: Fri, 12 Sep 2008 22:28:03 -0700 From: "Artem Belevich" Sender: artemb@gmail.com To: freebsd-hackers@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48C8A78C.6070608@cs.rice.edu> X-Google-Sender-Auth: 35a7110f2824d181 Cc: Alan Cox Subject: Re: Increasing KVM on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2008 05:28:05 -0000 By the way, this part of Alan's patch fixes a bug in RELENG7 where mapbase is passed to vm_map_find uninitialized. -CURRENT already has this change applied. Perhaps it's worth committing in RELENG7, too. --- ./kern/link_elf_obj.c.orig 2008-09-01 11:06:44.000000000 -0700 +++ ./kern/link_elf_obj.c 2008-09-10 13:07:54.793310216 -0700 @@ -667,6 +667,7 @@ goto out; } ef->address = (caddr_t) vm_map_min(kernel_map); + mapbase = KERNBASE; error = vm_map_find(kernel_map, ef->object, 0, &mapbase, round_page(mapsize), TRUE, VM_PROT_ALL, VM_PROT_ALL, FALSE); if (error) { --Artem From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 13 12:23:20 2008 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EB421065673; Sat, 13 Sep 2008 12:23:20 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id E2C598FC16; Sat, 13 Sep 2008 12:23:19 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (e180139087.adsl.alicedsl.de [85.180.139.87]) by acme.spoerlein.net (8.14.2/8.14.2) with ESMTP id m8DCNHBn062439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 13 Sep 2008 14:23:18 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.2/8.14.2) with ESMTP id m8DBpM0f060605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Sep 2008 13:51:22 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from uqs@localhost) by roadrunner.spoerlein.net (8.14.2/8.14.2/Submit) id m8DBpM6S060604; Sat, 13 Sep 2008 13:51:22 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Sat, 13 Sep 2008 13:51:22 +0200 From: Ulrich Spoerlein To: freebsd-hackers@FreeBSD.ORG, koitsu@FreeBSD.ORG Message-ID: <20080913115122.GK76117@roadrunner.spoerlein.net> Mail-Followup-To: freebsd-hackers@FreeBSD.ORG, koitsu@FreeBSD.ORG References: <20080905143915.GA60002@icarus.home.lan> <200809081347.m88DlK8T074926@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809081347.m88DlK8T074926@lurza.secnetix.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: Re: Extending find(1) to support -printf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2008 12:23:20 -0000 Pretty late to the game, but ... On Mon, 08.09.2008 at 15:47:20 +0200, Oliver Fromme wrote: > Jeremy Chadwick wrote: > > Equally as frustrating, mutt's backtick support will only honour the > > first line of input. If a backticked command returns multiple lines, > > only the first is read; the rest are ignored. > > Well, you can convert back and forth between spaces > and newlines with tr(1): > > echo * | tr ' ' '\n' | grep -v whatever | tr '\n' ' ' If your data is not very large, you can also fool xargs(1) into doing the conversion for you $ echo * | xargs -n1 and $ ls -1 | xargs > It's not pretty, but it should work. Note that ls(1) > prints one file name per line, so you can simplify the > above line like this: > > ls | grep -v whatever | tr '\n' ' ' > > By the way, I often use zsh in such cases. It supports > "extended globbing", for example, the wildcard expression > *~*.(gz|bz2) matches all files _except_ the ones that end > with .gz or .bz2. Indeed much more useful than fighting with find(1) and passing the file lists around. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 13 20:53:04 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8961A1065672 for ; Sat, 13 Sep 2008 20:53:04 +0000 (UTC) (envelope-from nhoyle@hoyletech.com) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by mx1.freebsd.org (Postfix) with ESMTP id 567438FC19 for ; Sat, 13 Sep 2008 20:53:04 +0000 (UTC) (envelope-from nhoyle@hoyletech.com) Received: from [192.168.1.5] (pool-96-241-114-53.washdc.fios.verizon.net [96.241.114.53]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1KebuZ1IqK-0005XW; Sat, 13 Sep 2008 16:40:12 -0400 From: Nathanael Hoyle To: Karl Pielorz In-Reply-To: References: <20080912132102.GB56923@icarus.home.lan> <3BE629D093001F6BA2C6791C@Slim64.dmpriest.net.uk> <20080912160422.GB60094@icarus.home.lan> Content-Type: text/plain Date: Sat, 13 Sep 2008 16:40:01 -0400 Message-Id: <1221338401.18959.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/Syos523fMHOimEQPP2XfsgH9/AsP9turE66B Gh/Hp73UEA4cz6SKyL42jyDICk0Luy8fIoDs3EKruj5eNCafS/ lzSFye/UoQedpV5Yzp3XLTWfMvSAZH0 Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick Subject: Re: ZFS w/failing drives - any equivalent of Solaris FMA? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2008 20:53:04 -0000 On Fri, 2008-09-12 at 20:31 +0100, Karl Pielorz wrote: > > --On 12 September 2008 09:04 -0700 Jeremy Chadwick > wrote: > > > I know ATA will notice a detached channel, because I myself have done > > it: administratively, that is -- atacontrol detach ataX. But the only > > time that can happen "automatically" is if the actual controller does > > so itself, or if FreeBSD is told to do it administratively. > > I think the problem at the moment is, ZFS "doesn't care" - it's > deliberately remote from things like drivers, and drives - and at the > moment, there's no 'middle layer' or way for at least the ATA drivers to > communicate to ZFS that a drive 'has failed' (I mean, for starters, you've > got the problem of "what's a failed drive" - presumably a drive that's > operating outside a set of limits? - The first probably being 'is it still > attached?' :) > > That was a thread recently on the Open Solaris ZFS forum - and discussed at > length... > > > I am also very curious to know the exact brand/model of 8-port SATA > > controller from Supermicro you are using, *especially* if it uses ata(4) > > rather than CAM and da(4). > > The controllers ID as: > > Marvell 88SX6081 SATA300 controller > > They're SuperMicro 8 PORT PCI-X SATA controllers, 'AOC-SAT2-MV8' - and they > definitely show as 'adX' > > > Such Supermicro controllers were recently > > discussed on freebsd-stable (or was it -hardware?), and no one was able > > to come to a concise decision as to whether or not they were decent or > > even remotely trusted. Supermicro provides a few different SATA HBAs. > > Well, I've tested these cards for a number of months now, and they seem > fine here - at least with the WD drives I'm currently running (not saying > they're 'perfect' - but for my setup, I've not seen any issues). I didn't > notice any 'bad behaviour' when testing them under UFS, and when running > under ZFS they've picked up no checksum errors (or console messages) for > the duration the box has been running. > > > I can see the usefulness in Solaris's FMA thing. My big concern is > > whether or not FMA actually pulls the disk off the channel, or if it > > just leaves the disk/channel connected and simply informs kernel pieces > > not to use it. If it pulls the disk off the channel, I have serious > > qualms with it. > > I don't think it pulls it - I think it's looks at it's policies, and does > what they say, which would seem to be the equivalent of 'zpool offline dev' > by default (which, again doesn't pull it off any busses - it just notifies > ZFS not to send I/O to that device). > This is consistent with my understanding of the behavior under Solaris, and is similar to how Sun Solstice Disksuite has worked for years... the drive will get "kicked out" of the array, but will remain attached to the bus and fully visible to the system. The array gets marked as degraded and no further I/O is performed against the "submirror" until it is either manually re-synced or replaced and resynced. Occassionally, disksuite is somewhat overly aggressive about this, but the box stays responsive and resilient when a drive goes down. > I'll have to do a test using da / CAM driven disks (or ask someone who > worked on the port ;) - but I'd guess, unless there's something been added > to CAM to tell ZFS to offline the disk, it'll do the same - i.e. ZFS will > continue to issue I/O requests to disks as it needs - as at least in Open > Solaris, it's deemed *not* to be ZFS's job to detect failed disks, or do > anything about them - other than what it's told. > > ZFS under FreeBSD still works despite this (and works wonderfully well) - > it just means if any of your drives 'go out to lunch' - unless they fail in > such a way that the I/O requests are returned immediately as 'failed' (i.e. > I guess if the device node has gone) - ZFS will keep issuing (and > potentially pausing) waiting for I/O requests to failed drives, because it > doesn't know, doesn't care - and hasn't been told to do otherwise. > Unfortunately this means that a single failed/failing drive can make the entire i/o subsystem (and likely the machine with it) nonresponsive and fails badly at high-availability. There probably needs to be some sort of "middleware" that can monitor the responses from the commands to the individual drives and configurably take action to offline the drive from the zpool in order to attain high availability. -Nathanael > -Kp > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 13 23:57:30 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7646F106566C for ; Sat, 13 Sep 2008 23:57:30 +0000 (UTC) (envelope-from jamesfrancistoy@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 083988FC14 for ; Sat, 13 Sep 2008 23:57:29 +0000 (UTC) (envelope-from jamesfrancistoy@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so893181fgb.35 for ; Sat, 13 Sep 2008 16:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=RHZonfRNNs//S0bN43phklkACRsIddxX4oaipi9nds4=; b=Q2VrjV4MYoSZdnA5da0yA9X2qhgLH6/PbGulcnOVVerJLuJEJlFHtiHPXLcriHe0Ed YdvFQJ4CF1Y1GdyWq2pZRNVUDT1sOhWhjpB2y+oZzwigyXzkgnzVEZMpPxAd5+y+Yiab uduCM7F60NGv1AQELm7YblmyhZk497P14DUlQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=G9t7NFyKCv6vQBdABRHn9fH5vqWVSvcgrpYDKkTTE5g7JTgokdTUIHu/WtHBb+yFv5 RQtnUgeLVdVIkFpvSZ7/Zz0oB38prORA+G6SwC9heM7x3aLlA/xage8Pw6p7X9fjAjl3 8s669UYZ8eCt1aZlfgm2RjtvWBQeMDo0RgQzI= Received: by 10.187.191.19 with SMTP id t19mr784460fap.87.1221350248345; Sat, 13 Sep 2008 16:57:28 -0700 (PDT) Received: by 10.187.218.13 with HTTP; Sat, 13 Sep 2008 16:57:28 -0700 (PDT) Message-ID: <9f8af95f0809131657q6c3e2339uebc2a9a4b2e2f5de@mail.gmail.com> Date: Sat, 13 Sep 2008 19:57:28 -0400 From: jT Sender: jamesfrancistoy@gmail.com To: "Wesley Shields" In-Reply-To: <20080909131442.GL62357@atarininja.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9f8af95f0809061626q22bc8f60i48fd95b32cef3d04@mail.gmail.com> <20080907150747.GB62357@atarininja.org> <20080909115351.GJ39652@deviant.kiev.zoral.com.ua> <20080909122917.GK62357@atarininja.org> <20080909123746.GK39652@deviant.kiev.zoral.com.ua> <20080909131442.GL62357@atarininja.org> X-Google-Sender-Auth: 3f42593129251624 Cc: Kostik Belousov , freebsd-hackers Subject: Re: 256-byte inode support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2008 23:57:30 -0000 Kostik, Wesley, I've been using this patch since Wesley made me aware of it -- it has been 100% fine for me atm -- there are a few small modifications to it and it applies cleanly to -CURRENT -- a bunch of my friends who run all linux boxen (and i'm changing their minds about that slowly but surely) use it and I have also _not_ heard a peep from them about any failures / weirdness -- and most of their data exists on ext2fs :) -- so thats a good sign -- i've attached the updated patch --- ./ext2_fs.h.orig 2008-09-13 23:25:32.000000000 +0100 +++ ./ext2_fs.h 2008-09-13 23:25:45.000000000 +0100 @@ -150,7 +150,7 @@ #else /* !notyet */ #define EXT2_INODES_PER_BLOCK(s) ((s)->s_inodes_per_block) /* Should be sizeof(struct ext2_inode): */ -#define EXT2_INODE_SIZE 128 +#define EXT2_INODE_SIZE(s) ((s)->s_es->s_inode_size) #define EXT2_FIRST_INO 11 #endif /* notyet */ --- ./ext2_inode.c.orig 2008-09-13 23:25:53.000000000 +0100 +++ ./ext2_inode.c 2008-09-13 23:26:06.000000000 +0100 @@ -91,7 +91,7 @@ return (error); } ext2_i2ei(ip, (struct ext2_inode *)((char *)bp->b_data + - EXT2_INODE_SIZE * ino_to_fsbo(fs, ip->i_number))); + EXT2_INODE_SIZE(fs) * ino_to_fsbo(fs, ip->i_number))); if (waitfor && (vp->v_mount->mnt_kern_flag & MNTK_ASYNC) == 0) return (bwrite(bp)); else { --- ./ext2_vfsops.c.orig 2008-09-13 23:26:13.000000000 +0100 +++ ./ext2_vfsops.c 2008-09-13 23:26:55.000000000 +0100 @@ -424,7 +424,7 @@ V(s_frags_per_group) fs->s_inodes_per_group = es->s_inodes_per_group; V(s_inodes_per_group) - fs->s_inodes_per_block = fs->s_blocksize / EXT2_INODE_SIZE; + fs->s_inodes_per_block = fs->s_blocksize / EXT2_INODE_SIZE(fs); V(s_inodes_per_block) fs->s_itb_per_group = fs->s_inodes_per_group /fs->s_inodes_per_block; V(s_itb_per_group) @@ -578,7 +578,7 @@ return (error); } ext2_ei2i((struct ext2_inode *) ((char *)bp->b_data + - EXT2_INODE_SIZE * ino_to_fsbo(fs, ip->i_number)), ip); + EXT2_INODE_SIZE(fs) * ino_to_fsbo(fs, ip->i_number)), ip); brelse(bp); VOP_UNLOCK(vp, 0); vrele(vp); @@ -1013,7 +1013,7 @@ return (error); } /* convert ext2 inode to dinode */ - ext2_ei2i((struct ext2_inode *) ((char *)bp->b_data + EXT2_INODE_SIZE * + ext2_ei2i((struct ext2_inode *) ((char *)bp->b_data + EXT2_INODE_SIZE(fs) * ino_to_fsbo(fs, ino)), ip); ip->i_block_group = ino_to_cg(fs, ino); ip->i_next_alloc_block = 0; /jT http://git.zen-sources.org/?p=kernel/zenmm.git;a=summary On Tue, Sep 9, 2008 at 9:14 AM, Wesley Shields wrote: > On Tue, Sep 09, 2008 at 03:37:47PM +0300, Kostik Belousov wrote: >> On Tue, Sep 09, 2008 at 08:29:17AM -0400, Wesley Shields wrote: >> > On Tue, Sep 09, 2008 at 02:53:51PM +0300, Kostik Belousov wrote: >> > > On Sun, Sep 07, 2008 at 11:07:47AM -0400, Wesley Shields wrote: >> > > > On Sat, Sep 06, 2008 at 07:26:27PM -0400, jT wrote: >> > > > > hackers, >> > > > > >> > > > > since tytso had updated ext3 -- i've noticed that i can't use my >> > > > > 265-byte inode ext3 drives -- is there any effort to update it? If >> > > > > not -- if you know where i should attempt to start please let me know >> > > > > so i can start working on support (i have a few other people i know >> > > > > interested in this) -- thanks and hope everyone is well >> > > > >> > > > There was a PR submitted for it and eventually a patch added to the PR. >> > > > I've tested the patch given in the URL at the port and it works. We >> > > > will start to see more of this as the newer version becomes more common >> > > > in the wild. >> > > > >> > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124621 >> > > > >> > > > Would be nice to see this fixed in 7.1 but it may be too late for that. >> > > >> > > What was the reason for increasing inode size ? I think it is rather >> > > pointless to increase the size without using newly added space for some >> > > data. Is inode format the same for the first 128 bytes, and does data >> > > at the second 128 bytes should be used to correctly interpret inode ? >> > >> > I honestly don't know the answer. Though I do agree that it is >> > pointless to increase the size without using the new space. >> > >> > All I know is that I was unable to read an ext filesystem made with -I >> > 256 (which is the default when using the most recent >> > sysutils/e2fsprogs). >> >> I think it is too dangerous for the user data to commit this patch, >> without investigating this first. > > I think that's a fair assessment to make. The patch is certainly simple > enough but I'm not familiar with what it's doing to make an accurate > assessment. I know it worked for the simple test case I provided in my > previous message. If I can be of any further assistance please let me > know. > > -- WXS >