From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 13 08:42:59 2009 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 E78C11065695 for ; Sun, 13 Sep 2009 08:42:59 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout6.freenet.de (mout6.freenet.de [IPv6:2001:748:100:40::2:8]) by mx1.freebsd.org (Postfix) with ESMTP id 8525E8FC1F for ; Sun, 13 Sep 2009 08:42:59 +0000 (UTC) Received: from [195.4.92.22] (helo=12.mx.freenet.de) by mout6.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1Mmkfi-0001dP-En for freebsd-hackers@freebsd.org; Sun, 13 Sep 2009 10:42:58 +0200 Received: from te22e.t.pppool.de ([89.55.226.46]:22731 helo=ernst.jennejohn.org) by 12.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1Mmkfi-0001WF-7J for freebsd-hackers@freebsd.org; Sun, 13 Sep 2009 10:42:58 +0200 Date: Sun, 13 Sep 2009 10:42:57 +0200 From: Gary Jennejohn To: freebsd-hackers@freebsd.org Message-ID: <20090913104257.7e042f45@ernst.jennejohn.org> In-Reply-To: <86fxasl154.fsf@ds4.des.no> References: <86fxasl154.fsf@ds4.des.no> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: DDB capture buffer X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2009 08:43:00 -0000 On Sat, 12 Sep 2009 15:53:59 +0200 Dag-Erling Sm__rgrav wrote: > The default maximum size of the DDB capture buffer is 48 kB. This is > ridiculously low; it's not even nearly enough to capture the output from > the first example in textdump(4): > > script kdb.enter.panic=textdump set; capture on; show allpcpu; bt; > ps; alltrace; show alllocks; call doadump; reset > > Would anyone object to increasing it to 1 MB? DDB is opt-in, so it will > only affect people who compile it into their kernel (or -CURRENT users > who don't compile it out; they have it coming). > I'd say it's a good idea, as long as you put a warning in UPDATING for people using e.g. embedded devices with little memory. It's reasonable to expect such users to customize their kernel configs. --- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 13 17:38:05 2009 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 3F3A31065672; Sun, 13 Sep 2009 17:38:05 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id 10FE28FC2C; Sun, 13 Sep 2009 17:38:04 +0000 (UTC) Received: from feathers.peganest.com (feathers.peganest.com [78.33.110.3]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n8DHbulG032581 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 13 Sep 2009 17:37:58 GMT (envelope-from ken@mthelicon.com) From: Pegasus Mc Cleaft Organization: Feathers To: current@freebsd.org, hackers@freebsd.org Date: Sun, 13 Sep 2009 18:37:56 +0100 User-Agent: KMail/1.12.1 (FreeBSD/9.0-CURRENT; KDE/4.3.1; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200909131837.56319.ken@mthelicon.com> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hercules.mthelicon.com Cc: Subject: Changes in IPv6 Configuration 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, 13 Sep 2009 17:38:05 -0000 Hello Current and Hackers, With the recent changes to /etc/rc.d for network start-up. I was wondering what is now correct. The previously working ipv6 configuration no longer creates a static default route, and I have not been able to figure out why. After boot, if I manually add the default route for ipv6, all works OK but I must be missing something to make it happen automatically. Currently, I have this in my /etc/rc.conf and this does not work. Any help would be appreciated. ipv6_prefer="YES" ifconfig_re0_ipv6="inet6 2001:4d48:ad51:32:21d:7dff:fe07:241a prefixlen 64" ipv6_defaultrouter="2001:4d48:ad51:32::3" ipv6_network_interfaces="auto" ipv6_default_interface="re0" Thanks in advance, Peg From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 13 18:14:05 2009 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 B9CC5106568B; Sun, 13 Sep 2009 18:14:05 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6BB0F8FC18; Sun, 13 Sep 2009 18:14:05 +0000 (UTC) Received: from feathers.peganest.com (feathers.peganest.com [78.33.110.3]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n8DIDw77032806 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 13 Sep 2009 18:14:00 GMT (envelope-from ken@mthelicon.com) From: Pegasus Mc Cleaft Organization: Feathers To: "Bjoern A. Zeeb" Date: Sun, 13 Sep 2009 19:13:53 +0100 User-Agent: KMail/1.12.1 (FreeBSD/9.0-CURRENT; KDE/4.3.1; amd64; ; ) References: <200909131837.56319.ken@mthelicon.com> <20090913175656.K68375@maildrop.int.zabbadoz.net> In-Reply-To: <20090913175656.K68375@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909131913.53853.ken@mthelicon.com> X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hercules.mthelicon.com Cc: hackers@freebsd.org, FreeBSD current mailing list Subject: Re: Changes in IPv6 Configuration 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, 13 Sep 2009 18:14:05 -0000 On Sunday 13 September 2009 18:58:02 Bjoern A. Zeeb wrote: > On Sun, 13 Sep 2009, Pegasus Mc Cleaft wrote: > > Hi, > > > With the recent changes to /etc/rc.d for network start-up. I was > > wondering what is now correct. The previously working ipv6 configuration > > no longer creates a static default route, and I have not been able to > > figure out why. After boot, if I manually add the default route for ipv6, > > all works OK but I must be missing something to make it happen > > automatically. Currently, I have this in my /etc/rc.conf and this does > > not work. Any help would be appreciated. > > > > ipv6_prefer="YES" > > ifconfig_re0_ipv6="inet6 2001:4d48:ad51:32:21d:7dff:fe07:241a prefixlen > > 64" ipv6_defaultrouter="2001:4d48:ad51:32::3" > > ipv6_network_interfaces="auto" > > ipv6_default_interface="re0" > > can you try this change (just pasted in): > > Index: etc/rc.d/routing > =================================================================== > --- etc/rc.d/routing (revision 197153) > +++ etc/rc.d/routing (working copy) > @@ -132,7 +132,7 @@ > if [ -n "${ipv6_static_routes}" ]; then > for i in ${ipv6_static_routes}; do > ipv6_route_args=`get_if_var $i ipv6_route_IF` > - route ${_action} -inet6 ${route_args} > + route ${_action} -inet6 ${ipv6_route_args} > done > fi > > > > /bz > Hi Bjoern, Thank you very much. That change did work and now the IPv6 default gateway is being added to the route table on start-up. Cheers, Peg From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 13 18:19:17 2009 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 B121C106568B; Sun, 13 Sep 2009 18:19:17 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6198FC1A; Sun, 13 Sep 2009 18:19:17 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 207CA41C707; Sun, 13 Sep 2009 20:00:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id o4HIJZgHpau8; Sun, 13 Sep 2009 20:00:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 52E7141C705; Sun, 13 Sep 2009 20:00:06 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id CE7274448E6; Sun, 13 Sep 2009 17:58:02 +0000 (UTC) Date: Sun, 13 Sep 2009 17:58:02 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Pegasus Mc Cleaft In-Reply-To: <200909131837.56319.ken@mthelicon.com> Message-ID: <20090913175656.K68375@maildrop.int.zabbadoz.net> References: <200909131837.56319.ken@mthelicon.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@freebsd.org, FreeBSD current mailing list , Hiroki Sato Subject: Re: Changes in IPv6 Configuration 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, 13 Sep 2009 18:19:17 -0000 On Sun, 13 Sep 2009, Pegasus Mc Cleaft wrote: Hi, > With the recent changes to /etc/rc.d for network start-up. I was wondering > what is now correct. The previously working ipv6 configuration no longer > creates a static default route, and I have not been able to figure out why. > After boot, if I manually add the default route for ipv6, all works OK but I > must be missing something to make it happen automatically. Currently, I have > this in my /etc/rc.conf and this does not work. Any help would be appreciated. > > ipv6_prefer="YES" > ifconfig_re0_ipv6="inet6 2001:4d48:ad51:32:21d:7dff:fe07:241a prefixlen 64" > ipv6_defaultrouter="2001:4d48:ad51:32::3" > ipv6_network_interfaces="auto" > ipv6_default_interface="re0" can you try this change (just pasted in): Index: etc/rc.d/routing =================================================================== --- etc/rc.d/routing (revision 197153) +++ etc/rc.d/routing (working copy) @@ -132,7 +132,7 @@ if [ -n "${ipv6_static_routes}" ]; then for i in ${ipv6_static_routes}; do ipv6_route_args=`get_if_var $i ipv6_route_IF` - route ${_action} -inet6 ${route_args} + route ${_action} -inet6 ${ipv6_route_args} done fi /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 13 20:20:14 2009 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 2412C106566C; Sun, 13 Sep 2009 20:20:14 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id D10968FC0C; Sun, 13 Sep 2009 20:20:13 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 901E241C6FC; Sun, 13 Sep 2009 22:20:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 76s0oaUA1B0h; Sun, 13 Sep 2009 22:20:12 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id E2CCE41C6F2; Sun, 13 Sep 2009 22:20:11 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id CDD96444900; Sun, 13 Sep 2009 20:20:08 +0000 (UTC) Date: Sun, 13 Sep 2009 20:20:08 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Pegasus Mc Cleaft In-Reply-To: <200909131913.53853.ken@mthelicon.com> Message-ID: <20090913201914.A68375@maildrop.int.zabbadoz.net> References: <200909131837.56319.ken@mthelicon.com> <20090913175656.K68375@maildrop.int.zabbadoz.net> <200909131913.53853.ken@mthelicon.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@freebsd.org, FreeBSD current mailing list Subject: Re: Changes in IPv6 Configuration 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, 13 Sep 2009 20:20:14 -0000 On Sun, 13 Sep 2009, Pegasus Mc Cleaft wrote: Hi, > On Sunday 13 September 2009 18:58:02 Bjoern A. Zeeb wrote: >> On Sun, 13 Sep 2009, Pegasus Mc Cleaft wrote: >> >> Hi, >> >>> With the recent changes to /etc/rc.d for network start-up. I was >>> wondering what is now correct. The previously working ipv6 configuration >>> no longer creates a static default route, and I have not been able to >>> figure out why. After boot, if I manually add the default route for ipv6, >>> all works OK but I must be missing something to make it happen >>> automatically. Currently, I have this in my /etc/rc.conf and this does >>> not work. Any help would be appreciated. >>> >>> ipv6_prefer="YES" >>> ifconfig_re0_ipv6="inet6 2001:4d48:ad51:32:21d:7dff:fe07:241a prefixlen >>> 64" ipv6_defaultrouter="2001:4d48:ad51:32::3" >>> ipv6_network_interfaces="auto" >>> ipv6_default_interface="re0" >> >> can you try this change (just pasted in): >> >> Index: etc/rc.d/routing >> =================================================================== >> --- etc/rc.d/routing (revision 197153) >> +++ etc/rc.d/routing (working copy) >> @@ -132,7 +132,7 @@ >> if [ -n "${ipv6_static_routes}" ]; then >> for i in ${ipv6_static_routes}; do >> ipv6_route_args=`get_if_var $i ipv6_route_IF` >> - route ${_action} -inet6 ${route_args} >> + route ${_action} -inet6 ${ipv6_route_args} >> done >> fi >> >> >> >> /bz >> > > Thank you very much. That change did work and now the IPv6 default gateway > is being added to the route table on start-up. Thanks a lot for reporting and testing. I just comitted the correction. /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 14 09:31:46 2009 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 1F3DB106568B for ; Mon, 14 Sep 2009 09:31:46 +0000 (UTC) (envelope-from kobold=freebsd-hackers=freebsd.org=ledolblw@mail.26dimensions.com) Received: from mail.26dimensions.com (mail.26dimensions.com [62.112.194.160]) by mx1.freebsd.org (Postfix) with ESMTP id D38D18FC18 for ; Mon, 14 Sep 2009 09:31:45 +0000 (UTC) Received: from kobold by mail.26dimensions.com with local (Exim 4.69) (envelope-from ) id 1Mn7ft-0006Kb-7J for freebsd-hackers@freebsd.org; Mon, 14 Sep 2009 11:16:41 +0200 Date: Mon, 14 Sep 2009 11:16:41 +0200 From: Fabio Tranchitella To: freebsd-hackers@freebsd.org Message-ID: <20090914091641.GE23252@mail.26dimensions.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Organization: Fabio Tranchitella: =?iso-8859-1?Q?Torino_?= =?iso-8859-1?B?KEl0YWx5KSwgUOljcw==?= (Hungary) X-URL: http://www.tranchitella.it X-Operating-System: Debian GNU/Linux 4.0 X-GPG-Keyserver: http://keyring.debian.org X-GPG-Keynumber: 0x7F961564 X-GPG-Fingerprint: 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Mon, 14 Sep 2009 11:32:39 +0000 Subject: Distro Summit 2010: Call for Papers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cfp@distrosummit.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 09:31:46 -0000 =============== CALL FOR PAPERS =============== Distro Summit 2010 is a one-day technical conference with a strong focus on collaboration between Free Software distributions hosted at the linux.conf.au 2010. We are looking for proposals from any Free Software distribution, from the typical full distributions (both linux and non-linux) to the niche market derivatives. In spite of the strong focus on collaboration between Free Software distributions, topics may include packaging, maintenance, relationship with upstream developers, release management and QA. For more informtion, please visit: http://distrosummit.org. Important dates =============== * Call for papers ends: Wednesday 30 September 2009 * Announcing the schedule: Friday 2 October 2009 * Conference begins: Monday 18 January 2010 Presentation types ================== We will accept proposals for: * 25 minute standard-length presentations; * 50 minute long presentations. Session lengths include time for audience questions. We intend for standard-length presentation to make up the vast majority of our presentations. If you plan on submitting a proposal for a long presentation, a willingness to present a standard-length presentation will impact positively on your proposal. Submit a proposal ================= To submit your proposal, we'll need the following information: * Your name, contact details and a short biography; * Your proposal title; * Intended audience; * An abstract; * Presentation outline; * Presentation type (standard-length or long). To submit a proposal, or get more information, please write to cfp@distrosummit.org. About the Distro Summit ======================= The Distro Summit 2010 is a one-day developer conference with a strong focus on collaboration between free software distributions hosted at the linux.conf.au 2010 (http://www.lca2010.org.nz). In addition to a schedule of technical, social and policy talks, the Distro Summit provides an opportunity for developers, contributors and other interested people to meet in person and work together more closely. Previous similar events have featured speakers from around the world. They have also been extremely beneficial for developing key free software software components and for improving collaboration and sharing between the different distributions. Target Audience =============== The Distro Summit is (mainly) a technical event, but this does not mean that the only target audience are developers and maintainers of free software distributions: the event will feature talks that range from the development to real-world use cases, going through marketing and the social aspects of the maintenance of free software distributions. -- Fabio Tranchitella on the behalf of the Distro Summit organizers From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 14 13:28:26 2009 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 0DA481065670 for ; Mon, 14 Sep 2009 13:28:26 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cetus.palisadesys.com (cetus.palisadesys.isupark.org [205.237.115.21]) by mx1.freebsd.org (Postfix) with ESMTP id 9190D8FC21 for ; Mon, 14 Sep 2009 13:28:25 +0000 (UTC) Received: from cancer.palisadesys.com (serverwatch [172.16.1.98]) by cetus.palisadesys.com (8.14.3/8.14.3) with ESMTP id n8EDF9IW017699; Mon, 14 Sep 2009 08:15:09 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) Received: from GuysMBP.local (cetus.palisadesys.isupark.org [205.237.115.21]) (authenticated bits=0) by cancer.palisadesys.com (8.14.2/8.14.2) with ESMTP id n8EDF7mo003404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Sep 2009 08:15:07 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) Message-ID: <4AAE41DB.9050104@palisadesys.com> Date: Mon, 14 Sep 2009 08:15:07 -0500 From: Guy Helmer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Linda Messerschmidt References: <237c27100908261203g7e771400o2d9603220d1f1e0b@mail.gmail.com> <200909111102.14503.jhb@freebsd.org> <237c27100909111035y544e8c91hc7726fd6ef16e351@mail.gmail.com> <200909111506.47309.jhb@freebsd.org> <237c27100909111905y244924c1n93b4e4d9ceda44be@mail.gmail.com> <237c27100909112055i35612b4btbfbecb8b5dd1568c@mail.gmail.com> <4AAB1E34.2060908@elischer.org> <237c27100909112147h64f71585p2a97f2b48a510985@mail.gmail.com> In-Reply-To: <237c27100909112147h64f71585p2a97f2b48a510985@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (cancer.palisadesys.com [205.237.115.20]); Mon, 14 Sep 2009 08:15:07 -0500 (CDT) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.399, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Cc: freebsd-hackers@freebsd.org Subject: Re: Intermittent system hangs on 7.2-RELEASE-p1 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, 14 Sep 2009 13:28:26 -0000 Linda Messerschmidt wrote: > Well, this is interesting. I got really frustrated with the other > approach, so I thought I'd thin a machine down absolutely as far as I > could, eliminate every possible source of delay, and see what happens. > I killed everything... cron, RPC, NFS, devd, gmon, nrpe, everything. > The Apache and its exerciser are now the only things running on the > machine, and the Apache is only touching an md0 swap device mounted on > /mnt. I *still* get the hangs. > > It hangs for all sorts of different periods, but the duration of the > stall is approximately inversely proportional to the chance of seeing > it. To get a short delay, you need wait only a little bit. If you > want a 2-3 second delay, you may have to wait 15-20 minutes. > On what sort of hardware is this hang occurring? Several months ago I was trying to resolve an intermittent hang under FreeBSD 7. I collected a large number of crashdumps I created using the kernel debugger when I caught the machine hanging, but the backtraces were very inconsistent, and the hang was only occurring on Xeons with multithreading (older 2.8GHz and 3.6GHz Xeons). I was able to prevent the hang by setting "mach.hyperthreading_enabled=0" in /boot/loader.conf, but I am still not sure why it worked. Guy From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 15 09:08:18 2009 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 5BF0A106568B; Tue, 15 Sep 2009 09:08:17 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2782A8FC20; Tue, 15 Sep 2009 09:08:17 +0000 (UTC) Received: from outgoing.leidinger.net (pD954FB25.dip.t-dialin.net [217.84.251.37]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id B8FC9844730; Tue, 15 Sep 2009 11:08:10 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 98304AAB91; Tue, 15 Sep 2009 11:08:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1253005687; bh=CY8I7hIusDBRWyUe2+QzbakhPiUkwdL3mv1ac1u1UZU=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=BNJc04UpgblvG9NfGtmNvaSElpV6Jyb8ohGd742D3E+x8xk6O5qjU/P3AO3rT+gcs 1PPcsGo+5cg+95puS+i1JHglqOmqSmp/yXx7nXUmI+oBKm4cZkEHHsnfW/O+1d5uWj X4CcCXPYKo+IiLxqKQ0UmN8pI4OLRomsjYyHF6q6McGvMTnma6wuVYq4jBslp/lbi3 qln2+MAY7gJS3ynlhQ3oWHVmJGzfLW1i3La0GARVN4FZzDlVLYI5ZbrOkLYBPjAEIl gjGuJ5HkRDy8seYE9kPlorrD1vGt1qyQH73VieA00eVI+2se7HZsIrLvynmnRkaJXr wzUqcEYkOo4xw== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n8F987VG078982; Tue, 15 Sep 2009 11:08:07 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 15 Sep 2009 11:08:06 +0200 Message-ID: <20090915110806.13816i8eowbecwkc@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Tue, 15 Sep 2009 11:08:06 +0200 From: Alexander Leidinger To: Alexander Best References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-8.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: B8FC9844730.C6C96 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.285, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, TW_BF 0.08, TW_XC 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1253610491.96097@4yd8QxAnjwE+dHz8FjMrEw X-EBL-Spam-Status: No X-Mailman-Approved-At: Tue, 15 Sep 2009 11:31:57 +0000 Cc: emulation@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: Buffer overflow detected by REDZONE with linuxulator 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, 15 Sep 2009 09:08:18 -0000 Quoting Alexander Best (from Wed, 09 Sep 2009 19:01:31 +0200 (CEST)): > hi there, CCing emulation@, this is better suited there. Full quote for the benefit of the emulation@ readers. Please drop hackers@ on reply. Thanks. > i've installed emulators/linux_dist-gentoo-stage3 and grabbed a snapshot from > the ltp git repository (http://ltp.sourceforge.net/). as expected some tests > failed because i'm using compat.linux.osrelease: 2.6.16 which is > still missing > a few linux syscalls, ipcs and ioctls. Are you interested to help update the corresponding FreeBSD wiki page? If yes, register there and we can hand out write access. > however i also noticed REDZONE reporting buffer overflows. i'm only > a user and > not a developer so i don't know if the ltp is to be blamed or if the problem > lies within the linuxulator. Probably the later... > i'm running 9.0-CURRENT (r196879). as i mentioned before i'm using 2.6 linux > kernel emulation. here are the buffer overflow reports: Is your system running in 32bit or 64bit mode? Do you know which ltp-tests cause those messages to appear? Bye, Alexander. > Sep 9 14:12:42 otaku kernel: REDZONE: Buffer overflow detected. 9 bytes > corrupted after 0xcc28c483 (3 bytes allocated). > Sep 9 14:12:42 otaku kernel: Allocation backtrace: > Sep 9 14:12:42 otaku kernel: #0 0xc0709aaa at redzone_setup+0x3a > Sep 9 14:12:42 otaku kernel: #1 0xc05bc673 at malloc+0x1c3 > Sep 9 14:12:42 otaku kernel: #2 0xc07428b8 at linux_getsockaddr+0x48 > Sep 9 14:12:42 otaku kernel: #3 0xc0742eb8 at linux_socketcall+0x178 > Sep 9 14:12:42 otaku kernel: #4 0xc0772f56 at syscall+0x2a6 > Sep 9 14:12:42 otaku kernel: #5 0xc07568b0 at Xint0x80_syscall+0x20 > Sep 9 14:12:42 otaku kernel: Free backtrace: > Sep 9 14:12:42 otaku kernel: #0 0xc0709a3a at redzone_check+0x17a > Sep 9 14:12:42 otaku kernel: #1 0xc05bc32d at free+0x5d > Sep 9 14:12:42 otaku kernel: #2 0xc0742ef0 at linux_socketcall+0x1b0 > Sep 9 14:12:42 otaku kernel: #3 0xc0772f56 at syscall+0x2a6 > Sep 9 14:12:42 otaku kernel: #4 0xc07568b0 at Xint0x80_syscall+0x20 > Sep 9 14:20:08 otaku kernel: REDZONE: Buffer overflow detected. 4 bytes > corrupted after 0xcc2538ea (106 bytes allocated). > Sep 9 14:20:08 otaku kernel: Allocation backtrace: > Sep 9 14:20:08 otaku kernel: #0 0xc0709aaa at redzone_setup+0x3a > Sep 9 14:20:08 otaku kernel: #1 0xc05bc673 at malloc+0x1c3 > Sep 9 14:20:08 otaku kernel: #2 0xc063a902 at unp_connect+0x162 > Sep 9 14:20:08 otaku kernel: #3 0xc063d6c9 at uipc_connect+0x49 > Sep 9 14:20:08 otaku kernel: #4 0xc062fde2 at soconnect+0x52 > Sep 9 14:20:08 otaku kernel: #5 0xc0638eb6 at kern_connect+0x96 > Sep 9 14:20:08 otaku kernel: #6 0xc0742c7b at linux_connect+0x3b > Sep 9 14:20:08 otaku kernel: #7 0xc0742f22 at linux_socketcall+0x1e2 > Sep 9 14:20:08 otaku kernel: #8 0xc0772f56 at syscall+0x2a6 > Sep 9 14:20:08 otaku kernel: #9 0xc07568b0 at Xint0x80_syscall+0x20 > Sep 9 14:20:08 otaku kernel: Free backtrace: > Sep 9 14:20:08 otaku kernel: #0 0xc0709a3a at redzone_check+0x17a > Sep 9 14:20:08 otaku kernel: #1 0xc05bc32d at free+0x5d > Sep 9 14:20:08 otaku kernel: #2 0xc063bfb2 at uipc_detach+0x242 > Sep 9 14:20:08 otaku kernel: #3 0xc0632a7e at sofree+0x22e > Sep 9 14:20:08 otaku kernel: #4 0xc0632f26 at soclose+0x386 > Sep 9 14:20:08 otaku kernel: #5 0xc0617c49 at soo_close+0x29 > Sep 9 14:20:08 otaku kernel: #6 0xc0598b13 at _fdrop+0x43 > Sep 9 14:20:08 otaku kernel: #7 0xc059ab90 at closef+0x290 > Sep 9 14:20:08 otaku kernel: #8 0xc059af22 at kern_close+0x102 > Sep 9 14:20:08 otaku kernel: #9 0xc059b09a at close+0x1a > Sep 9 14:20:08 otaku kernel: #10 0xc0772f56 at syscall+0x2a6 > Sep 9 14:20:08 otaku kernel: #11 0xc07568b0 at Xint0x80_syscall+0x20 > Sep 9 14:20:09 otaku kernel: REDZONE: Buffer overflow detected. 4 bytes > corrupted after 0xccc653ea (106 bytes allocated). > Sep 9 14:20:09 otaku kernel: Allocation backtrace: > Sep 9 14:20:09 otaku kernel: #0 0xc0709aaa at redzone_setup+0x3a > Sep 9 14:20:09 otaku kernel: #1 0xc05bc673 at malloc+0x1c3 > Sep 9 14:20:09 otaku kernel: #2 0xc063a902 at unp_connect+0x162 > Sep 9 14:20:09 otaku kernel: #3 0xc063d6c9 at uipc_connect+0x49 > Sep 9 14:20:09 otaku kernel: #4 0xc062fde2 at soconnect+0x52 > Sep 9 14:20:09 otaku kernel: #5 0xc0638eb6 at kern_connect+0x96 > Sep 9 14:20:09 otaku kernel: #6 0xc0742c7b at linux_connect+0x3b > Sep 9 14:20:09 otaku kernel: #7 0xc0742f22 at linux_socketcall+0x1e2 > Sep 9 14:20:09 otaku kernel: #8 0xc0772f56 at syscall+0x2a6 > Sep 9 14:20:09 otaku kernel: #9 0xc07568b0 at Xint0x80_syscall+0x20 > Sep 9 14:20:09 otaku kernel: Free backtrace: > Sep 9 14:20:09 otaku kernel: #0 0xc0709a3a at redzone_check+0x17a > Sep 9 14:20:09 otaku kernel: #1 0xc05bc32d at free+0x5d > Sep 9 14:20:09 otaku kernel: #2 0xc063bfb2 at uipc_detach+0x242 > Sep 9 14:20:09 otaku kernel: #3 0xc0632a7e at sofree+0x22e > Sep 9 14:20:09 otaku kernel: #4 0xc0632f26 at soclose+0x386 > Sep 9 14:20:09 otaku kernel: #5 0xc0617c49 at soo_close+0x29 > Sep 9 14:20:09 otaku kernel: #6 0xc0598b13 at _fdrop+0x43 > Sep 9 14:20:09 otaku kernel: #7 0xc059ab90 at closef+0x290 > Sep 9 14:20:09 otaku kernel: #8 0xc059af22 at kern_close+0x102 > Sep 9 14:20:09 otaku kernel: #9 0xc059b09a at close+0x1a > Sep 9 14:20:09 otaku kernel: #10 0xc0772f56 at syscall+0x2a6 > Sep 9 14:20:09 otaku kernel: #11 0xc07568b0 at Xint0x80_syscall+0x20 > Sep 9 14:20:09 otaku kernel: REDZONE: Buffer overflow detected. 4 bytes > corrupted after 0xcf45a9ea (106 bytes allocated). > Sep 9 14:20:09 otaku kernel: Allocation backtrace: > Sep 9 14:20:09 otaku kernel: #0 0xc0709aaa at redzone_setup+0x3a > Sep 9 14:20:09 otaku kernel: #1 0xc05bc673 at malloc+0x1c3 > Sep 9 14:20:09 otaku kernel: #2 0xc063a902 at unp_connect+0x162 > Sep 9 14:20:09 otaku kernel: #3 0xc063d6c9 at uipc_connect+0x49 > Sep 9 14:20:09 otaku kernel: #4 0xc062fde2 at soconnect+0x52 > Sep 9 14:20:09 otaku kernel: #5 0xc0638eb6 at kern_connect+0x96 > Sep 9 14:20:09 otaku kernel: #6 0xc0742c7b at linux_connect+0x3b > Sep 9 14:20:09 otaku kernel: #7 0xc0742f22 at linux_socketcall+0x1e2 > Sep 9 14:20:09 otaku kernel: #8 0xc0772f56 at syscall+0x2a6 > Sep 9 14:20:09 otaku kernel: #9 0xc07568b0 at Xint0x80_syscall+0x20 > Sep 9 14:20:09 otaku kernel: Free backtrace: > Sep 9 14:20:09 otaku kernel: #0 0xc0709a3a at redzone_check+0x17a > Sep 9 14:20:09 otaku kernel: #1 0xc05bc32d at free+0x5d > Sep 9 14:20:09 otaku kernel: #2 0xc063bfb2 at uipc_detach+0x242 > Sep 9 14:20:09 otaku kernel: #3 0xc0632a7e at sofree+0x22e > Sep 9 14:20:09 otaku kernel: #4 0xc0632f26 at soclose+0x386 > Sep 9 14:20:09 otaku kernel: #5 0xc0617c49 at soo_close+0x29 > Sep 9 14:20:09 otaku kernel: #6 0xc0598b13 at _fdrop+0x43 > Sep 9 14:20:09 otaku kernel: #7 0xc059ab90 at closef+0x290 > Sep 9 14:20:09 otaku kernel: #8 0xc059b55a at fdfree+0x3ea > Sep 9 14:20:09 otaku kernel: #9 0xc05a57b3 at exit1+0x513 > Sep 9 14:20:09 otaku kernel: #10 0xc05d17f4 at sigexit+0xa14 > Sep 9 14:20:09 otaku kernel: #11 0xc05d19fd at postsig+0x1dd > Sep 9 14:20:09 otaku kernel: #12 0xc0608fca at ast+0x35a > Sep 9 14:20:09 otaku kernel: #13 0xc0757174 at doreti_ast+0x17 > > cheers. > alex -- Fifth Law of Procrastination: Procrastination avoids boredom; one never has the feeling that there is nothing important to do. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 15 20:15:08 2009 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 151C21065670 for ; Tue, 15 Sep 2009 20:15:08 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 857628FC19 for ; Tue, 15 Sep 2009 20:15:07 +0000 (UTC) Received: by bwz2 with SMTP id 2so2899623bwz.43 for ; Tue, 15 Sep 2009 13:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:organization:from :date:message-id:user-agent:mime-version:content-type; bh=TnuJkgJDtE7/aa5DGpXDcCyFyz3vYwOiOIo+3vbeF4U=; b=un3+IrWx7JyYVOFPGOqKop+rIc1BWLJrJGliKymYMwL9vE/eoJ/wpaR9OBc2bEnPD7 i/ZnyM8IC3H+nzB5AFTB9Co3fk0kqwR1sXbAPBje3Y2jXdD1n+bu0fOZY0XebkYb0gvP Uud1bErFkKQPkpDNbyGnMszBZohKnqR59Pqkw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:organization:from:date:message-id:user-agent :mime-version:content-type; b=NxSPQ2Zoi6gnB41Syv1NcJXXqn6dPXDNOFlo+8myr0CPP4Y4X6nTAEV7JcSptOhC/9 b2+8Y3Rx8RQmJLuYWzfuciMJAy9YPbRSjnIXtnopfPg2aKQ2mdvJhVQkqTTotbR0fTYj 9OhlwQVaxAS3TuE3iol43wvLrOJDh2HQhhNm0= Received: by 10.204.7.75 with SMTP id c11mr6578149bkc.119.1253045706248; Tue, 15 Sep 2009 13:15:06 -0700 (PDT) Received: from localhost (vpn-195-69-246-43.customer.onet.com.ua [195.69.246.43]) by mx.google.com with ESMTPS id 12sm1247223fks.47.2009.09.15.13.15.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Sep 2009 13:15:05 -0700 (PDT) To: freebsd-hackers@FreeBSD.org Organization: TOA Ukraine From: Mikolaj Golub Date: Tue, 15 Sep 2009 23:15:00 +0300 Message-ID: <868wgg2ce3.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: 7.1 panicked removing namecache entry from cache 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, 15 Sep 2009 20:15:08 -0000 Hi, Today we had vfs related panic on 7.1-RELEASE-p5. Does anybody have any idea? Might it have already been fixed in later versions? Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc07fd34b stack pointer = 0x28:0xe6a97bc8 frame pointer = 0x28:0xe6a97bdc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 49 (vnlru) trap number = 12 panic: page fault cpuid = 2 Uptime: 11h19m41s Physical memory: 3059 MB Dumping 275 MB: 260 244 228 212 196 180 164 148 132 116 100 84 68 52 36 20 4 (kgdb) where #0 doadump () at pcpu.h:196 #1 0xc07910a7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0791379 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0aa7bcc in trap_fatal (frame=0xe6a97b88, eva=0) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0aa7e50 in trap_pfault (frame=0xe6a97b88, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0aa880c in trap (frame=0xe6a97b88) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc0a8e67b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc07fd34b in cache_zap (ncp=0xcc33783c) at /usr/src/sys/kern/vfs_cache.c:276 #8 0xc07fd57c in cache_purge (vp=0xc890533c) at /usr/src/sys/kern/vfs_cache.c:613 #9 0xc080df18 in vgonel (vp=0xc890533c) at /usr/src/sys/kern/vfs_subr.c:2545 #10 0xc081174d in vnlru_free (count=270) at /usr/src/sys/kern/vfs_subr.c:870 #11 0xc0811ddc in vnlru_proc () at /usr/src/sys/kern/vfs_subr.c:733 #12 0xc076cc19 in fork_exit (callout=0xc0811cf0 , arg=0x0, frame=0xe6a97d38) at /usr/src/sys/kern/kern_fork.c:804 #13 0xc0a8e6f0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 267 static void 268 cache_zap(ncp) 269 struct namecache *ncp; 270 { 271 struct vnode *vp; 272 273 mtx_assert(&cache_lock, MA_OWNED); 274 CTR2(KTR_VFS, "cache_zap(%p) vp %p", ncp, ncp->nc_vp); 275 vp = NULL; 276 LIST_REMOVE(ncp, nc_hash); 277 LIST_REMOVE(ncp, nc_src); 278 if (LIST_EMPTY(&ncp->nc_dvp->v_cache_src)) { 279 vp = ncp->nc_dvp; 280 numcachehv--; 281 } 282 if (ncp->nc_vp) { 283 TAILQ_REMOVE(&ncp->nc_vp->v_cache_dst, ncp, nc_dst); 284 ncp->nc_vp->v_dd = NULL; 285 } else { 286 TAILQ_REMOVE(&ncneg, ncp, nc_dst); 287 numneg--; 288 } 289 numcache--; 290 cache_free(ncp); 291 if (vp) 292 vdrop(vp); 293 } 603 void 604 cache_purge(vp) 605 struct vnode *vp; 606 { 607 608 CTR1(KTR_VFS, "cache_purge(%p)", vp); 609 CACHE_LOCK(); 610 while (!LIST_EMPTY(&vp->v_cache_src)) 611 cache_zap(LIST_FIRST(&vp->v_cache_src)); 612 while (!TAILQ_EMPTY(&vp->v_cache_dst)) 613 cache_zap(TAILQ_FIRST(&vp->v_cache_dst)); 614 vp->v_dd = NULL; 615 CACHE_UNLOCK(); 616 } (kgdb) fr 8 #8 0xc07fd57c in cache_purge (vp=0xc890533c) at /usr/src/sys/kern/vfs_cache.c:613 613 struct namecache *ncp, *nnp; (kgdb) p *vp $1 = {v_type = VREG, v_tag = 0xc0b37e38 "ufs", v_op = 0xc0bfbdc0, v_data = 0x0, v_mount = 0x0, v_nmntvnodes = {tqe_next = 0xcc342450, tqe_prev = 0xcc31e350}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, v_hashlist = {le_next = 0x0, le_prev = 0xc65e99fc}, v_hash = 6643674, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0xcc33783c, tqh_last = 0xcc33784c}, v_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = { lk_object = {lo_name = 0xc0b37e38 "ufs", lo_type = 0xc0b37e38 "ufs", lo_flags = 70844416, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, lk_interlock = 0xc0c42d10, lk_flags = 262208, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80, lk_timo = 51, lk_lockholder = 0xc64bf8c0, lk_newlock = 0x0}, v_interlock = {lock_object = { lo_name = 0xc0b418b9 "vnode interlock", lo_type = 0xc0b418b9 "vnode interlock", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, v_vnlock = 0xc8905394, v_holdcnt = 1, v_usecount = 0, v_iflag = 128, v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0xcc30acf0, tqe_prev = 0xc0c4f3ac}, v_bufobj = { bo_mtx = 0xc89053c4, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xc8905400}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xc8905410}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xc0be8e40, bo_bsize = 16384, bo_object = 0x0, bo_synclist = {le_next = 0x0, le_prev = 0xc890520c}, bo_private = 0xc890533c, __bo_vnode = 0xc890533c}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} (kgdb) fr 7 #7 0xc07fd34b in cache_zap (ncp=0xcc33783c) at /usr/src/sys/kern/vfs_cache.c:276 276 LIST_REMOVE(ncp, nc_hash); (kgdb) p *ncp $2 = {nc_hash = {le_next = 0x0, le_prev = 0x0}, nc_src = {le_next = 0xcc31650c, le_prev = 0xcc2c51e4}, nc_dst = {tqe_next = 0x0, tqe_prev = 0x0}, nc_dvp = 0x0, nc_vp = 0x0, nc_flag = 0 '\0', nc_nlen = 0 '\0', nc_name = 0xcc33785e ""} -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 15 21:11:32 2009 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 A94C6106568B for ; Tue, 15 Sep 2009 21:11:32 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mail.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with ESMTP id F23E58FC1C for ; Tue, 15 Sep 2009 21:11:31 +0000 (UTC) Received: from localhost (unknown [192.168.1.2]) by ext.zirakzigil.org (Postfix) with ESMTP id 77ECF70CC1 for ; Tue, 15 Sep 2009 20:53:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from ext.zirakzigil.org ([192.168.1.2]) by localhost (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id n8YUOf0-F2vs for ; Tue, 15 Sep 2009 20:53:20 +0000 (UTC) Received: from [192.168.229.16] (unknown [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by ext.zirakzigil.org (Postfix) with ESMTPA id 204FA70CB4 for ; Tue, 15 Sep 2009 20:53:20 +0000 (UTC) Message-ID: <4AAFFEBB.4030907@zirakzigil.org> Date: Tue, 15 Sep 2009 22:53:15 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ZFS group ownership 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, 15 Sep 2009 21:11:32 -0000 I don't know if this is the correct list to discuss this matter, if not I apologize in advance. I've always understood group ownership as a way to allow members of the same group to operate on files / folders which belong to that group, while leaving out others. Let's suppose to have a directory /root/test (UFS file system) I do this: cd /root chmod -R 770 test chown -R www:www test (I use group www as an example, since it's already present on a base system) My user "gferro" also belongs to group www and has umask 007 su - gferro touch qweq mkdir asda If I watch now the file and directory I've just created: --------------------------------------------------------------- %ls -la total 6 drwxrwx--- 3 www www 512 Sep 12 13:39 . drwxr-xr-x 4 root wheel 512 Sep 12 13:02 .. drwxrwx--- 2 gferro www 512 Sep 12 13:39 asda -rw-rw---- 1 gferro www 0 Sep 12 13:38 qweq --------------------------------------------------------------- I see that both belongs to group www, even though gferro's base group is "gferro": --------------------------------------------------------------- id gferro uid=1001(gferro) gid=1001(gferro) groups=1001(gferro),80(www) --------------------------------------------------------------- This means that all those user's who belong to group "www" will be able to work with the files and directories I've created. Now I try to do the same on a zfs partition on the same machine This is what I see with ls --------------------------------------------------------------- ls -la total 4 drwxrwx--- 3 www www 4 Sep 12 13:43 . drwxr-xr-x 4 root wheel 4 Sep 12 13:43 .. drwxrwx--- 2 gferro gferro 2 Sep 12 13:43 asda -rw-rw---- 1 gferro gferro 0 Sep 12 13:43 qweq --------------------------------------------------------------- As you can see, both file and directory belongs now to "gferro" and not "www". This means that other users won't even be able to read my files / dir, let alone modify them. What I ask now is: is this a bug or a feature? How can I achieve my goal in ZFS, that is allowing members of the same group to operate with the files / dirs they create? Thanks in advance. From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 15 21:16:31 2009 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 D9368106566C for ; Tue, 15 Sep 2009 21:16:31 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mail.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with ESMTP id 52DFB8FC0C for ; Tue, 15 Sep 2009 21:16:31 +0000 (UTC) Received: from localhost (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id B94D370D03 for ; Tue, 15 Sep 2009 20:57:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by localhost (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id gMcikMwoFb4g for ; Tue, 15 Sep 2009 20:57:04 +0000 (UTC) Received: from [192.168.229.16] (unknown [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 79EBE70CFA for ; Tue, 15 Sep 2009 20:57:04 +0000 (UTC) Message-ID: <4AAFFF9B.80304@zirakzigil.org> Date: Tue, 15 Sep 2009 22:56:59 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ZFS group ownership 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, 15 Sep 2009 21:16:31 -0000 I don't know if this is the correct list to discuss this matter, if not I apologize in advance. I've always understood group ownership as a way to allow members of the same group to operate on files / folders which belong to that group, while leaving out others. Let's suppose to have a directory /root/test (UFS file system) I do this: cd /root chmod -R 770 test chown -R www:www test (I use group www as an example, since it's already present on a base system) My user "gferro" also belongs to group www and has umask 007 su - gferro touch qweq mkdir asda If I watch now the file and directory I've just created: --------------------------------------------------------------- %ls -la total 6 drwxrwx--- 3 www www 512 Sep 12 13:39 . drwxr-xr-x 4 root wheel 512 Sep 12 13:02 .. drwxrwx--- 2 gferro www 512 Sep 12 13:39 asda -rw-rw---- 1 gferro www 0 Sep 12 13:38 qweq --------------------------------------------------------------- I see that both belongs to group www, even though gferro's base group is "gferro": --------------------------------------------------------------- id gferro uid=1001(gferro) gid=1001(gferro) groups=1001(gferro),80(www) --------------------------------------------------------------- This means that all those user's who belong to group "www" will be able to work with the files and directories I've created. Now I try to do the same on a zfs partition on the same machine This is what I see with ls --------------------------------------------------------------- ls -la total 4 drwxrwx--- 3 www www 4 Sep 12 13:43 . drwxr-xr-x 4 root wheel 4 Sep 12 13:43 .. drwxrwx--- 2 gferro gferro 2 Sep 12 13:43 asda -rw-rw---- 1 gferro gferro 0 Sep 12 13:43 qweq --------------------------------------------------------------- As you can see, both file and directory belongs now to "gferro" and not "www". This means that other users won't even be able to read my files / dir, let alone modify them. What I ask now is: is this a bug or a feature? How can I achieve my goal in ZFS, that is allowing members of the same group to operate with the files / dirs they create? Thanks in advance. From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 15 21:41:32 2009 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 518541065676 for ; Tue, 15 Sep 2009 21:41:32 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mail.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with ESMTP id BC82F8FC21 for ; Tue, 15 Sep 2009 21:41:31 +0000 (UTC) Received: from localhost (unknown [192.168.1.2]) by ext.zirakzigil.org (Postfix) with ESMTP id 6F31B6A9D3 for ; Sat, 12 Sep 2009 11:49:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from ext.zirakzigil.org ([192.168.1.2]) by localhost (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id 8ipdnatbhakH for ; Sat, 12 Sep 2009 11:49:41 +0000 (UTC) Received: from [192.168.229.16] (unknown [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by ext.zirakzigil.org (Postfix) with ESMTPA id 85A9D6A9C8 for ; Sat, 12 Sep 2009 11:49:41 +0000 (UTC) Message-ID: <4AAB8AD0.5010302@zirakzigil.org> Date: Sat, 12 Sep 2009 13:49:36 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ZFS group ownership 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, 15 Sep 2009 21:41:32 -0000 I don't know if this is the correct list to discuss this matter, if not I apologize in advance. I've always understood group ownership as a way to allow members of the same group to operate on files / folders which belong to that group, while leaving out others. Let's suppose to have a directory /root/test (UFS file system) I do this: cd /root chmod -R 770 test chown -R www:www test (I use group www as an example, since it's already present on a base system) My user "gferro" also belongs to group www and has umask 007 su - gferro touch qweq mkdir asda If I watch now the file and directory I've just created: --------------------------------------------------------------- %ls -la total 6 drwxrwx--- 3 www www 512 Sep 12 13:39 . drwxr-xr-x 4 root wheel 512 Sep 12 13:02 .. drwxrwx--- 2 gferro www 512 Sep 12 13:39 asda -rw-rw---- 1 gferro www 0 Sep 12 13:38 qweq --------------------------------------------------------------- I see that both belongs to group www, even though gferro's base group is "gferro": --------------------------------------------------------------- id gferro uid=1001(gferro) gid=1001(gferro) groups=1001(gferro),80(www) --------------------------------------------------------------- This means that all those user's who belong to group "www" will be able to work with the files and directories I've created. Now I try to do the same on a zfs partition on the same machine This is what I see with ls --------------------------------------------------------------- ls -la total 4 drwxrwx--- 3 www www 4 Sep 12 13:43 . drwxr-xr-x 4 root wheel 4 Sep 12 13:43 .. drwxrwx--- 2 gferro gferro 2 Sep 12 13:43 asda -rw-rw---- 1 gferro gferro 0 Sep 12 13:43 qweq --------------------------------------------------------------- As you can see, both file and directory belongs now to "gferro" and not "www". This means that other users won't even be able to read my files / dir, let alone modify them. What I ask now is: is this a bug or a feature? How can I achieve my goal in ZFS, that is allowing members of the same group to operate with the files / dirs they create? Thanks in advance. From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 15 22:37:00 2009 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 DA1DF106566B for ; Tue, 15 Sep 2009 22:37:00 +0000 (UTC) (envelope-from ben@b1c1l1.com) Received: from lancer.b1c1l1.com (unknown [IPv6:2607:f358:1a:1a:1000::]) by mx1.freebsd.org (Postfix) with ESMTP id C29708FC0C for ; Tue, 15 Sep 2009 22:37:00 +0000 (UTC) Received: from supra.b1c1l1.com (netops-172.sfo1.bitgravity.com [209.131.110.172]) by lancer.b1c1l1.com (Postfix) with ESMTPSA id 4B6F25C29; Tue, 15 Sep 2009 15:37:00 -0700 (PDT) Message-ID: <4AB01700.8060602@b1c1l1.com> Date: Tue, 15 Sep 2009 15:36:48 -0700 From: Benjamin Lee User-Agent: Thunderbird 2.0.0.23 (X11/20090829) MIME-Version: 1.0 To: Giulio Ferro References: <4AAB8AD0.5010302@zirakzigil.org> In-Reply-To: <4AAB8AD0.5010302@zirakzigil.org> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEFA3B20FA4024EFF897201B3" Cc: freebsd-hackers@freebsd.org Subject: Re: ZFS group ownership 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, 15 Sep 2009 22:37:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEFA3B20FA4024EFF897201B3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/12/2009 04:49 AM, Giulio Ferro wrote: [...] > How can I achieve my goal in ZFS, that is allowing members of the same > group to operate with the files / dirs they create? Does setting the setgid bit on the directory have any effect? --=20 Benjamin Lee http://www.b1c1l1.com/ --------------enigEFA3B20FA4024EFF897201B3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJKsBcLAAoJEHBW16CPoSMC77UP/3mioeP/if7wIX/DghBs/MDA sUY/xJ5Br3PcxbvUSN/4O9oW27eQlJBKcj/vcXcXJUlpwxtucU//yAkirwGQEKff iWAC2PLUhaz8pp6b3KbmBXZ/8V8TgG6xeqyRFdWyzP/1nzrEyoafLI9uPn+eKeDo ThxwZmU43c4XhCd3Tq7cU1ii9mJ9odCZBDnPW4hX2oLqjfA+GWVOfR2o6ps5UM+a wwhS2iFzA9i4ubEVsjlWKlq+fGkvoV+VAxfReKPEG36f7BRxWijImKwygn4++4J6 BdfikMoHbAG+/hi3KGGphdoROIkwiUrwrGn+G71W6NzuiLN7zOEdTJQ48MKMp5/w 5r695qvdsjIMyV6Bdb66zlIXPFKxqEMlfWXWlJQCInM6gi0KhwveK5LQZympcYtd ACQH/4bHmeCvwgIHFW23+fMk6gxJsEiUXb268i6s7TBkvZ+tOHiYeawNd2QKGapt rOXrj05LgC2oZ5PsbLDJnBHOjXDt8g018PgAkQZucYWNFMYClh7eumuzLiT3Iber jCAxEuUIFimh6assGtYQCuyfgZKY5y+YbRzRLQS73kcjCnwl5IM9TGTPTUF45dLs I/VCa0+OttthppNN0V0A9BHooynoseCzUhKs/73YVMwqZnxZg+qpqEuVN09YfqDd p17ilkpb6gXgycfOyIDK =u8R5 -----END PGP SIGNATURE----- --------------enigEFA3B20FA4024EFF897201B3-- From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 15 22:32:17 2009 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 AB6981065670 for ; Tue, 15 Sep 2009 22:32:15 +0000 (UTC) (envelope-from nate@thatsmathematics.com) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id 572AC8FC08 for ; Tue, 15 Sep 2009 22:32:15 +0000 (UTC) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n8FMIgo11326; Tue, 15 Sep 2009 15:18:42 -0700 (PDT) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n8FMIf819902; Tue, 15 Sep 2009 15:18:42 -0700 (PDT) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Tue, 15 Sep 2009 15:18:41 -0700 (PDT) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Giulio Ferro In-Reply-To: <4AAB8AD0.5010302@zirakzigil.org> Message-ID: References: <4AAB8AD0.5010302@zirakzigil.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 15 Sep 2009 22:41:41 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: ZFS group ownership 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, 15 Sep 2009 22:32:17 -0000 On Sat, 12 Sep 2009, Giulio Ferro wrote: > I don't know if this is the correct list to discuss this matter, if not > I apologize in advance. freebsd-questions might have been better, but I don't think you're too far off. It wasn't necessary to post three times though :) [On UFS, files are created with the same group as the directory that contains them. On ZFS, they are created with the primary group of the user who creates them.] > What I ask now is: is this a bug or a feature? Both, I think :) The behavior you describe on UFS (group comes from the directory) is standard for BSD-based systems like FreeBSD. On SysV-based systems, however, the default is that the group comes from the user, as you describe on ZFS. ZFS was originally developed for Solaris, a descendent of SysV, so it's not surprising that it also has this behavior. However, this is at least a documentation bug, since the open(2) man page describes the BSD behavior without mentioning exceptions. > How can I achieve my goal in ZFS, that is allowing members of the same > group to operate with the files / dirs they create? On SysV, you can get BSD-type behavior by setting the sgid bit on the directory in question, e.g. "chmod g+s dir". Then new files will inherit their group from the directory. I suspect this will work on FreeBSD/ZFS too even though "chmod g+s" on a directory is undocumented. -- Nate Eldredge nate@thatsmathematics.com From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 16 10:37:19 2009 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 CF539106566C for ; Wed, 16 Sep 2009 10:37:19 +0000 (UTC) (envelope-from ady@ady.ro) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id 723038FC08 for ; Wed, 16 Sep 2009 10:37:18 +0000 (UTC) Received: by ewy4 with SMTP id 4so4926681ewy.36 for ; Wed, 16 Sep 2009 03:37:18 -0700 (PDT) MIME-Version: 1.0 Sender: ady@ady.ro Received: by 10.210.60.13 with SMTP id i13mr2116311eba.8.1253097437594; Wed, 16 Sep 2009 03:37:17 -0700 (PDT) In-Reply-To: References: <4AAB8AD0.5010302@zirakzigil.org> From: Adrian Penisoara Date: Wed, 16 Sep 2009 12:36:57 +0200 X-Google-Sender-Auth: b514af0de0d78dfc Message-ID: <78cb3d3f0909160336m2d1f93dsad4aafb692395a80@mail.gmail.com> To: Nate Eldredge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Giulio Ferro Subject: Re: ZFS group ownership 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, 16 Sep 2009 10:37:19 -0000 Hi, On Wed, Sep 16, 2009 at 12:18 AM, Nate Eldredge wrote: [...] > [On UFS, files are created with the same group as the directory that > contains them. =A0On ZFS, they are created with the primary group of the = user > who creates them.] > >> What I ask now is: is this a bug or a feature? > > Both, I think :) > > The behavior you describe on UFS (group comes from the directory) is > standard for BSD-based systems like FreeBSD. =A0On SysV-based systems, > however, the default is that the group comes from the user, as you descri= be > on ZFS. =A0ZFS was originally developed for Solaris, a descendent of SysV= , so > it's not surprising that it also has this behavior. =A0However, this is a= t > least a documentation bug, since the open(2) man page describes the BSD > behavior without mentioning exceptions. Is the ownership of the new file decided by the open() syscall or by the filesystem layer ? On a superficial lookup through the sources it appears a filesystem layer choice... Which of the following would then be the best option (also taking POLA into account): * leave things are they are * make ZFS under FreeBSD behave the way open(2) describes * have a new ZFS property govern the behavior and default to one of the ab= ove Thanks, Adrian Penisoara EnterpriseBSD From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 16 11:12:38 2009 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 89665106566B for ; Wed, 16 Sep 2009 11:12:38 +0000 (UTC) (envelope-from romain@blogreen.org) Received: from marvin.blogreen.org (unknown [IPv6:2a01:e35:2f7d:58c0:0:2:1:2]) by mx1.freebsd.org (Postfix) with ESMTP id 3C2DE8FC0A for ; Wed, 16 Sep 2009 11:12:38 +0000 (UTC) Received: by marvin.blogreen.org (Postfix, from userid 1001) id 40F8D5C34C; Wed, 16 Sep 2009 13:12:37 +0200 (CEST) Date: Wed, 16 Sep 2009 13:12:37 +0200 From: Romain =?iso-8859-1?Q?Tarti=E8re?= To: Nate Eldredge Message-ID: <20090916111237.GB1700@blogreen.org> Mail-Followup-To: Nate Eldredge , Giulio Ferro , freebsd-hackers@freebsd.org References: <4AAB8AD0.5010302@zirakzigil.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MfFXiAuoTsnnDAfZ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key: http://romain.blogreen.org/pubkey.asc Cc: freebsd-hackers@freebsd.org, Giulio Ferro Subject: Re: ZFS group ownership 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, 16 Sep 2009 11:12:38 -0000 --MfFXiAuoTsnnDAfZ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 15, 2009 at 03:18:41PM -0700, Nate Eldredge wrote: > >What I ask now is: is this a bug or a feature? >=20 > Both, I think :) Or none, just different implementation of the same open() function complying with the Open Group Base Specifications ;-) Quotting http://www.opengroup.org/onlinepubs/009695399/functions/open.html ----------------8<------------------------------------------------------ O_CREAT [...] the file shall be created; the user ID of the file shall be set to the effective user ID of the process; the group ID of the file shall be set to the group ID of the file's parent directory or to the effective group ID of the process [...] Implementations shall provide a way to initialize the file's group ID to the group ID of the parent directory. Implementations may, but need not, provide an implementation-defined way to initialize the file's group ID to the effective group ID of the calling process. [...] The POSIX.1-1990 standard required that the group ID of a newly created file be set to the group ID of its parent directory or to the effective group ID of the creating process. FIPS 151-2 required that implementations provide a way to have the group ID be set to the group ID of the containing directory, but did not prohibit implementations also supporting a way to set the group ID to the effective group ID of the creating process. Conforming applications should not assume which group ID will be used. If it matters, an application can use chown() to set the group ID after the file is created, or determine under what conditions the implementation will set the desired group ID. ----------------8<------------------------------------------------------ This being said, two different behaviour on the same system, even if you =AB should not assume which group ID will be used =BB, is kind of weird. --=20 Romain Tarti=E8re http://romain.blogreen.org/ pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) (plain text =3Dnon-HTML=3D PGP/GPG encrypted/signed e-mail much appreciated) --MfFXiAuoTsnnDAfZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkqwyCUACgkQ2OmjP/9W/0OAOgCeMbFnHI/oCNsZoRzs1h6za7/d ClwAnRqdy/MLOx1kYeQcclHSOXwiFjE2 =TSmb -----END PGP SIGNATURE----- --MfFXiAuoTsnnDAfZ-- From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 16 13:00:53 2009 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 C4BEF106566B for ; Wed, 16 Sep 2009 13:00:53 +0000 (UTC) (envelope-from BATV+05b7dc4ffe83f00d9e0a+2215+infradead.org+hch@bombadil.srs.infradead.org) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:4830:2446:ff00:214:51ff:fe65:c65c]) by mx1.freebsd.org (Postfix) with ESMTP id 07EA68FC0C for ; Wed, 16 Sep 2009 13:00:52 +0000 (UTC) Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Mnu7o-000339-5j; Wed, 16 Sep 2009 13:00:44 +0000 Date: Wed, 16 Sep 2009 09:00:44 -0400 From: Christoph Hellwig To: Adrian Penisoara Message-ID: <20090916130044.GA2670@infradead.org> References: <4AAB8AD0.5010302@zirakzigil.org> <78cb3d3f0909160336m2d1f93dsad4aafb692395a80@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78cb3d3f0909160336m2d1f93dsad4aafb692395a80@mail.gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Cc: freebsd-hackers@freebsd.org, Giulio Ferro , Nate Eldredge Subject: Re: ZFS group ownership 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, 16 Sep 2009 13:00:53 -0000 On Wed, Sep 16, 2009 at 12:36:57PM +0200, Adrian Penisoara wrote: > Which of the following would then be the best option (also taking POLA > into account): > * leave things are they are > * make ZFS under FreeBSD behave the way open(2) describes > * have a new ZFS property govern the behavior and default to one of the above Btw, on Linux all the common filesystem support the SysV behaviour by default but have a mount option bsdgroups/grpid that turns on the BSD hebaviour. I would recommend you do the same just with reversed signs on FreeBSD. ??Having different default behaviour for different filesystems on a single OS is generally a bad idea. From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 16 13:52:49 2009 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 2EC7B106566B for ; Wed, 16 Sep 2009 13:52:49 +0000 (UTC) (envelope-from linda.messerschmidt@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id DC1458FC0A for ; Wed, 16 Sep 2009 13:52:48 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so1447367qwe.7 for ; Wed, 16 Sep 2009 06:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Fvyobz9jFvqcG4SSkbHY8MkqACsLYPkW/tUAwb71HZE=; b=BPv2/nF0iEhe6OQNYtldsJ4zrqtkHDJbIAxoL7K/RzUbH01pQIFr+XDl3hLgdE1DyF OkmwgJh7Yq2ugtayznybTGjf1JFuXSAY6crY0YYoupVGs4bM141ujqxl8IrIyVIQ8UmG 0losX7QEVXLDBAZPrZN9ZwzjjaZPTKL1S1V0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=jyNWH8oyZm5Qd3CcEzb33im+oBSccsr28kqmJQEWWKE0hn9O0Cx06xKTj6KGsRDZ9O G6dB9KHxoqhjzuvQYZEz19X3FF7kiEG89bm2lMYOjLcBJuJrj0o+zOVdx8waPar5sxE/ jD3Nq6bkMUHIQf+GEYXI7NKaZok8rubADWKX4= MIME-Version: 1.0 Received: by 10.229.49.137 with SMTP id v9mr2517336qcf.21.1253109167999; Wed, 16 Sep 2009 06:52:47 -0700 (PDT) In-Reply-To: <20090916130044.GA2670@infradead.org> References: <4AAB8AD0.5010302@zirakzigil.org> <78cb3d3f0909160336m2d1f93dsad4aafb692395a80@mail.gmail.com> <20090916130044.GA2670@infradead.org> Date: Wed, 16 Sep 2009 09:52:47 -0400 Message-ID: <237c27100909160652u4bb141fcl6f29385ea9bad03e@mail.gmail.com> From: Linda Messerschmidt To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: ZFS group ownership 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, 16 Sep 2009 13:52:49 -0000 On Wed, Sep 16, 2009 at 9:00 AM, Christoph Hellwig wrot= e: > Btw, on Linux all the common filesystem support the SysV behaviour > by default but have a mount option bsdgroups/grpid that turns on the BSD > hebaviour. =A0I would recommend you do the same just with reversed signs > on FreeBSD. =A0??Having different default behaviour for different > filesystems on a single OS is generally a bad idea. I agree; I have noticed a lot of confusion with this as well. In our case, we mount some ZFS and UFS2 filesystems over NFS, and the NFS client machine has no way of knowing what the NFS server is going to use for a default group. It would be fantastic if there were a way to get consistent behavior. However, some of the ZFS filesystems in question are exported from a Solaris machine, and on Solaris, I believe it's the NFS client that's expected to set the grpid flag, so in order to reliably help with this case, this might have to be a client-side NFS flag on FreeBSD as well. Otherwise it may wind up working differently for local ZFS filesystems versus ones mounted over NFS. From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 16 15:15:50 2009 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 D927710656A3 for ; Wed, 16 Sep 2009 15:15:50 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mail.giulioferro.it (mail.giulioferro.it [85.18.102.52]) by mx1.freebsd.org (Postfix) with ESMTP id 91C0C8FC17 for ; Wed, 16 Sep 2009 15:15:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.giulioferro.it (Postfix) with ESMTP id C1DA233CA6; Wed, 16 Sep 2009 16:53:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at giulioferro.it Received: from mail.giulioferro.it ([127.0.0.1]) by localhost (aurynwork1sv1.giulioferro.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJa+guJuUbeJ; Wed, 16 Sep 2009 16:53:10 +0200 (CEST) Received: from aurynmob2.giulioferro.it (localhost [127.0.0.1]) (Authenticated sender: gferro@giulioferro.it) by mail.giulioferro.it (Postfix) with ESMTP id 14FE933C2B; Wed, 16 Sep 2009 16:53:10 +0200 (CEST) Message-ID: <4AB0FC8A.3090604@zirakzigil.org> Date: Wed, 16 Sep 2009 16:56:10 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Adrian Penisoara References: <4AAB8AD0.5010302@zirakzigil.org> <78cb3d3f0909160336m2d1f93dsad4aafb692395a80@mail.gmail.com> In-Reply-To: <78cb3d3f0909160336m2d1f93dsad4aafb692395a80@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Nate Eldredge Subject: Re: ZFS group ownership 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, 16 Sep 2009 15:15:50 -0000 Adrian Penisoara wrote: > Is the ownership of the new file decided by the open() syscall or by > the filesystem layer ? > On a superficial lookup through the sources it appears a filesystem > layer choice... > > Which of the following would then be the best option (also taking POLA > into account): > * leave things are they are > * make ZFS under FreeBSD behave the way open(2) describes > * have a new ZFS property govern the behavior and default to one of the above > > Thanks, > Adrian Penisoara > EnterpriseBSD > Thanks all for answering (sorry for the multiple posts, I was tuning my mail server) I believe that on a same freebsd there should be a consistent behavior among different mounts. So in my opinion ZFS should conform to UFS (or UFS to ZFS, if that's desirable). The best thing would be to have a sysctl tunable to choose that (sysv5 / bsd). BSD should be default, since it makes more sense for workgroups... From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 17 02:00:58 2009 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 85AE3106566C for ; Thu, 17 Sep 2009 02:00:58 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 715828FC0C for ; Thu, 17 Sep 2009 02:00:58 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 250E41A3C5D; Wed, 16 Sep 2009 19:00:58 -0700 (PDT) Date: Wed, 16 Sep 2009 19:00:58 -0700 From: Alfred Perlstein To: hackers@freebsd.org Message-ID: <20090917020058.GD21946@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="s5/bjXLgkIwAv6Hi" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: peter@freebsd.org Subject: script(1) issue/question 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, 17 Sep 2009 02:00:58 -0000 --s5/bjXLgkIwAv6Hi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [[ peter cc'd cause he seemed to add the original "exec a non-shell option" to script(1) ]] Hello all, I noticed that when running "script" and passing a program to exec that ^Z does not seem to work (although ^C does). I'm trying to figure a workaround and what I was going to do was add ISIG to the term flags when spawning a non-shell utility. (should I also check /etc/shells to help preserve POLA further?) Any pointers on this? Would this be a good idea, or a bad idea? Terminal gurus give me a hand please! :) please ignore the sigflg part at the top for now, prepping for possible cli option to avoid POLA breakage. Is there a way to detect ^Z or other terminal signals and propogate them to the child in a better way? -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer --s5/bjXLgkIwAv6Hi Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="script1.diff" Index: script.c =================================================================== --- script.c (revision 195826) +++ script.c (working copy) @@ -68,6 +68,7 @@ int child; const char *fname; int qflg, ttyflg; +int sigflg; struct termios tt; @@ -104,6 +105,9 @@ case 'k': kflg = 1; break; + case 'S': + sigflg = 1; + break; case 't': flushtime = atoi(optarg); if (flushtime < 0) @@ -241,11 +245,20 @@ doshell(char **av) { const char *shell; + struct termios rtt; shell = getenv("SHELL"); if (shell == NULL) shell = _PATH_BSHELL; + if (av[0]) { + /* enable signals for non-shell programs */ + rtt = tt; + cfmakeraw(&rtt); + rtt.c_lflag &= ~ECHO; + rtt.c_lflag |= ISIG; + (void)tcsetattr(STDIN_FILENO, TCSAFLUSH, &rtt); + } (void)close(master); (void)fclose(fscript); login_tty(slave); --s5/bjXLgkIwAv6Hi-- From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 17 10:33:33 2009 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 4A445106566C for ; Thu, 17 Sep 2009 10:33:33 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id D7E838FC08 for ; Thu, 17 Sep 2009 10:33:32 +0000 (UTC) Received: from kas30pipe.localhost (localhost [127.0.0.1]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 430BB130D59 for ; Thu, 17 Sep 2009 14:15:46 +0400 (MSD) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by mailrelay1.rambler.ru (Postfix) with ESMTP id EAF1B130D19 for ; Thu, 17 Sep 2009 14:15:45 +0400 (MSD) Date: Thu, 17 Sep 2009 14:15:26 +0400 From: Igor Sysoev To: freebsd-hackers@freebsd.org Message-ID: <20090917101526.GF57619@rambler-co.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.33/RELEASE, bases: 02092009 #2738642, status: clean X-SpamTest-Envelope-From: is@rambler-co.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 9536 [Sen 02 2009] X-SpamTest-Info: {received from trusted relay: common white list} X-SpamTest-Method: white ip list X-SpamTest-Rate: 0 X-SpamTest-Status: Trusted X-SpamTest-Status-Extended: trusted X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Subject: fcntl(F_RDAHEAD) 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, 17 Sep 2009 10:33:33 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Hi, nginx-0.8.15 can use completely non-blocking sendfile() using SF_NODISKIO flag. When sendfile() returns EBUSY, nginx calls aio_read() to read single byte. The first aio_read() preloads the first 128K part of a file in VM cache, however, all successive aio_read()s preload just 16K parts of the file. This makes non-blocking sendfile() usage ineffective for files larger than 128K. I've created a small patch for Darwin compatible F_RDAHEAD fcntl: fcntl(fd, F_RDAHEAD, preload_size) There is small incompatibilty: Darwin's fcntl allows just to enable/disable read ahead, while the proposed patch allows to set exact preload size. Currently the preload size affects vn_read() code path only and does not affect on sendfile() code path. However, it can be easy extended on sendfile() part too. The preload size is still limited by sysctl vfs.read_max. The patch is against FreeBSD 7.2 and was tested on FreeBSD 7.2-STABLE only. -- Igor Sysoev http://sysoev.ru/en/ --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="patch.rdahead" --- sys/sys/fcntl.h 2009-06-02 19:05:17.000000000 +0400 +++ sys/sys/fcntl.h 2009-09-12 20:29:34.000000000 +0400 @@ -118,6 +118,10 @@ #if __BSD_VISIBLE /* Attempt to bypass buffer cache */ #define O_DIRECT 0x00010000 +#ifdef _KERNEL +/* Read ahead */ +#define O_RDAHEAD 0x00020000 +#endif #endif /* @@ -187,6 +191,7 @@ #define F_SETLK 12 /* set record locking information */ #define F_SETLKW 13 /* F_SETLK; wait if blocked */ #define F_SETLK_REMOTE 14 /* debugging support for remote locks */ +#define F_RDAHEAD 15 /* read ahead */ /* file descriptor flags (F_GETFD, F_SETFD) */ #define FD_CLOEXEC 1 /* close-on-exec flag */ --- sys/kern/vfs_vnops.c 2009-06-02 19:05:00.000000000 +0400 +++ sys/kern/vfs_vnops.c 2009-09-12 20:24:00.000000000 +0400 @@ -305,6 +305,9 @@ sequential_heuristic(struct uio *uio, struct file *fp) { + if (fp->f_flag & O_RDAHEAD) + return(fp->f_seqcount << IO_SEQSHIFT); + if ((uio->uio_offset == 0 && fp->f_seqcount > 0) || uio->uio_offset == fp->f_nextoff) { /* --- sys/kern/kern_descrip.c 2009-08-28 18:50:11.000000000 +0400 +++ sys/kern/kern_descrip.c 2009-09-12 20:23:36.000000000 +0400 @@ -411,6 +411,7 @@ u_int newmin; int error, flg, tmp; int vfslocked; + uint64_t bsize; vfslocked = 0; error = 0; @@ -694,6 +695,31 @@ vfslocked = 0; fdrop(fp, td); break; + + case F_RDAHEAD: + FILEDESC_SLOCK(fdp); + if ((fp = fdtofp(fd, fdp)) == NULL) { + FILEDESC_SUNLOCK(fdp); + error = EBADF; + break; + } + if (fp->f_type != DTYPE_VNODE) { + FILEDESC_SUNLOCK(fdp); + error = EBADF; + break; + } + FILE_LOCK(fp); + if (arg) { + bsize = fp->f_vnode->v_mount->mnt_stat.f_iosize; + fp->f_seqcount = (arg + bsize - 1) / bsize; + fp->f_flag |= O_RDAHEAD; + } else { + fp->f_flag &= ~O_RDAHEAD; + } + FILE_UNLOCK(fp); + FILEDESC_SUNLOCK(fdp); + break; + default: error = EINVAL; break; --VS++wcV0S1rZb1Fb-- From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 17 14:49:44 2009 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 460F01065676 for ; Thu, 17 Sep 2009 14:49:44 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mail.giulioferro.it (mail.giulioferro.it [85.18.102.52]) by mx1.freebsd.org (Postfix) with ESMTP id 017B98FC0A for ; Thu, 17 Sep 2009 14:49:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.giulioferro.it (Postfix) with ESMTP id 1DFCC33CB4; Thu, 17 Sep 2009 16:46:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at giulioferro.it Received: from mail.giulioferro.it ([127.0.0.1]) by localhost (aurynwork1sv1.giulioferro.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiBnvnAhOk1W; Thu, 17 Sep 2009 16:46:36 +0200 (CEST) Received: from aurynmob2.giulioferro.it (localhost [127.0.0.1]) (Authenticated sender: gferro@giulioferro.it) by mail.giulioferro.it (Postfix) with ESMTP id 8132333C8D; Thu, 17 Sep 2009 16:46:36 +0200 (CEST) Message-ID: <4AB24C80.2020308@zirakzigil.org> Date: Thu, 17 Sep 2009 16:49:36 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Nate Eldredge References: <4AAB8AD0.5010302@zirakzigil.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: ZFS group ownership 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, 17 Sep 2009 14:49:44 -0000 Nate Eldredge wrote: > On SysV, you can get BSD-type behavior by setting the sgid bit on the > directory in question, e.g. "chmod g+s dir". Then new files will > inherit their group from the directory. I suspect this will work on > FreeBSD/ZFS too even though "chmod g+s" on a directory is undocumented. > Yes, it does. Thanks, I'll use this for my needs. Giulio. From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 17 22:26:53 2009 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 21454106566B for ; Thu, 17 Sep 2009 22:26:53 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 641B78FC12 for ; Thu, 17 Sep 2009 22:26:52 +0000 (UTC) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 5F1975C025 for ; Fri, 18 Sep 2009 06:26:51 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 1DEE955CE091; Fri, 18 Sep 2009 06:26:51 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id ct9kd74Sg4SF; Fri, 18 Sep 2009 06:26:45 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id E533C55CE08A; Fri, 18 Sep 2009 06:26:43 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=uIokQqfY0zR1XpFj37SAnSdJV2ebV/Te+0dWtAjvUeLZ9wlcU3AdylCTrGVYFH/Mg AjVZ8xZ80TTkTyDvLs4UQ== Message-ID: <4AB2B7A1.5000601@delphij.net> Date: Thu, 17 Sep 2009 15:26:41 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.22 (X11/20090803) MIME-Version: 1.0 To: Igor Sysoev References: <20090917101526.GF57619@rambler-co.ru> In-Reply-To: <20090917101526.GF57619@rambler-co.ru> X-Enigmail-Version: 0.96.0 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------020507030401020101040202" Cc: freebsd-hackers@freebsd.org Subject: Re: fcntl(F_RDAHEAD) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 22:26:53 -0000 This is a multi-part message in MIME format. --------------020507030401020101040202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Igor, Igor Sysoev wrote: > Hi, > > nginx-0.8.15 can use completely non-blocking sendfile() using SF_NODISKIO > flag. When sendfile() returns EBUSY, nginx calls aio_read() to read single > byte. The first aio_read() preloads the first 128K part of a file in VM cache, > however, all successive aio_read()s preload just 16K parts of the file. > This makes non-blocking sendfile() usage ineffective for files larger > than 128K. > > I've created a small patch for Darwin compatible F_RDAHEAD fcntl: > > fcntl(fd, F_RDAHEAD, preload_size) > > There is small incompatibilty: Darwin's fcntl allows just to enable/disable > read ahead, while the proposed patch allows to set exact preload size. > > Currently the preload size affects vn_read() code path only and does not > affect on sendfile() code path. However, it can be easy extended on > sendfile() part too. The preload size is still limited by sysctl vfs.read_max. > > The patch is against FreeBSD 7.2 and was tested on FreeBSD 7.2-STABLE only. I have ported this as a patch against -HEAD (should apply on 8.0-R but it's too late for us to add a new feature) plus a manual page entry documenting the feature. I've used F_READAHEAD as the name, but reading the manual page, it looks like we can just use F_RDAHEAD since Darwin seems to just distinguish 0 and !=0 case so that programmers won't have to use #ifdef or something else to get code working on different platform? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqyt40ACgkQi+vbBBjt66AdKgCfXOo/Vn+zw0cCjS+gGJUgPo8t WToAmgKIXaVKsKUcqVOqTwHl4eTFsbkM =uP3m -----END PGP SIGNATURE----- --------------020507030401020101040202 Content-Type: text/plain; name="readahead.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="readahead.diff" Index: lib/libc/sys/fcntl.2 =================================================================== --- lib/libc/sys/fcntl.2 (revision 197297) +++ lib/libc/sys/fcntl.2 (working copy) @@ -28,7 +28,7 @@ .\" @(#)fcntl.2 8.2 (Berkeley) 1/12/94 .\" $FreeBSD$ .\" -.Dd March 8, 2008 +.Dd September 19, 2009 .Dt FCNTL 2 .Os .Sh NAME @@ -241,6 +241,14 @@ .Dv SA_RESTART (see .Xr sigaction 2 ) . +.It Dv F_READAHEAD +Set or clear the read ahead amount for sequential access to the third +argument, +.Fa arg , +which is rounded up to the nearest block size. +A zero value in +.Fa arg +turns off read ahead. .El .Pp When a shared lock has been set on a segment of a file, Index: sys/kern/kern_descrip.c =================================================================== --- sys/kern/kern_descrip.c (revision 197297) +++ sys/kern/kern_descrip.c (working copy) @@ -421,6 +421,7 @@ struct vnode *vp; int error, flg, tmp; int vfslocked; + uint64_t bsize; vfslocked = 0; error = 0; @@ -686,6 +687,31 @@ vfslocked = 0; fdrop(fp, td); break; + + case F_READAHEAD: + FILEDESC_SLOCK(fdp); + if ((fp = fdtofp(fd, fdp)) == NULL) { + FILEDESC_SUNLOCK(fdp); + error = EBADF; + break; + } + if (fp->f_type != DTYPE_VNODE) { + FILEDESC_SUNLOCK(fdp); + error = EBADF; + break; + } + fhold(fp); + FILEDESC_SUNLOCK(fdp); + if (arg) { + bsize = fp->f_vnode->v_mount->mnt_stat.f_iosize; + fp->f_seqcount = (arg + bsize - 1) / bsize; + fp->f_flag |= O_READAHEAD; + } else { + fp->f_flag &= ~O_READAHEAD; + } + fdrop(fp, td); + break; + default: error = EINVAL; break; Index: sys/kern/vfs_vnops.c =================================================================== --- sys/kern/vfs_vnops.c (revision 197297) +++ sys/kern/vfs_vnops.c (working copy) @@ -312,6 +312,9 @@ sequential_heuristic(struct uio *uio, struct file *fp) { + if (fp->f_flag & O_READAHEAD) + return (fp->f_seqcount << IO_SEQSHIFT); + /* * Offset 0 is handled specially. open() sets f_seqcount to 1 so * that the first I/O is normally considered to be slightly Index: sys/sys/fcntl.h =================================================================== --- sys/sys/fcntl.h (revision 197297) +++ sys/sys/fcntl.h (working copy) @@ -112,7 +112,11 @@ #if __BSD_VISIBLE /* Attempt to bypass buffer cache */ #define O_DIRECT 0x00010000 +#ifdef _KERNEL +/* Read ahead */ +#define O_READAHEAD 0x00020000 #endif +#endif /* Defined by POSIX Extended API Set Part 2 */ #if __BSD_VISIBLE @@ -218,6 +222,7 @@ #define F_SETLK 12 /* set record locking information */ #define F_SETLKW 13 /* F_SETLK; wait if blocked */ #define F_SETLK_REMOTE 14 /* debugging support for remote locks */ +#define F_READAHEAD 15 /* read ahead */ /* file descriptor flags (F_GETFD, F_SETFD) */ #define FD_CLOEXEC 1 /* close-on-exec flag */ --------------020507030401020101040202-- From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 17 22:50:36 2009 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 D60DF106566C for ; Thu, 17 Sep 2009 22:50:36 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C74608FC16 for ; Thu, 17 Sep 2009 22:50:36 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id A01291A3C8A; Thu, 17 Sep 2009 15:50:36 -0700 (PDT) Date: Thu, 17 Sep 2009 15:50:36 -0700 From: Alfred Perlstein To: d@delphij.net Message-ID: <20090917225036.GL21946@elvis.mu.org> References: <20090917101526.GF57619@rambler-co.ru> <4AB2B7A1.5000601@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AB2B7A1.5000601@delphij.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: fcntl(F_RDAHEAD) 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, 17 Sep 2009 22:50:36 -0000 Please do not make the option have the same name but different semantics. Strongly suggest adding the Darwin name as a toggle and a FreeBSD name as a specific size option. -Alfred * Xin LI [090917 15:27] wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Igor, > > Igor Sysoev wrote: > > Hi, > > > > nginx-0.8.15 can use completely non-blocking sendfile() using SF_NODISKIO > > flag. When sendfile() returns EBUSY, nginx calls aio_read() to read single > > byte. The first aio_read() preloads the first 128K part of a file in VM cache, > > however, all successive aio_read()s preload just 16K parts of the file. > > This makes non-blocking sendfile() usage ineffective for files larger > > than 128K. > > > > I've created a small patch for Darwin compatible F_RDAHEAD fcntl: > > > > fcntl(fd, F_RDAHEAD, preload_size) > > > > There is small incompatibilty: Darwin's fcntl allows just to enable/disable > > read ahead, while the proposed patch allows to set exact preload size. > > > > Currently the preload size affects vn_read() code path only and does not > > affect on sendfile() code path. However, it can be easy extended on > > sendfile() part too. The preload size is still limited by sysctl vfs.read_max. > > > > The patch is against FreeBSD 7.2 and was tested on FreeBSD 7.2-STABLE only. > > I have ported this as a patch against -HEAD (should apply on 8.0-R but > it's too late for us to add a new feature) plus a manual page entry > documenting the feature. > > I've used F_READAHEAD as the name, but reading the manual page, it looks > like we can just use F_RDAHEAD since Darwin seems to just distinguish 0 > and !=0 case so that programmers won't have to use #ifdef or something > else to get code working on different platform? > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.12 (FreeBSD) > > iEYEARECAAYFAkqyt40ACgkQi+vbBBjt66AdKgCfXOo/Vn+zw0cCjS+gGJUgPo8t > WToAmgKIXaVKsKUcqVOqTwHl4eTFsbkM > =uP3m > -----END PGP SIGNATURE----- > Index: lib/libc/sys/fcntl.2 > =================================================================== > --- lib/libc/sys/fcntl.2 (revision 197297) > +++ lib/libc/sys/fcntl.2 (working copy) > @@ -28,7 +28,7 @@ > .\" @(#)fcntl.2 8.2 (Berkeley) 1/12/94 > .\" $FreeBSD$ > .\" > -.Dd March 8, 2008 > +.Dd September 19, 2009 > .Dt FCNTL 2 > .Os > .Sh NAME > @@ -241,6 +241,14 @@ > .Dv SA_RESTART > (see > .Xr sigaction 2 ) . > +.It Dv F_READAHEAD > +Set or clear the read ahead amount for sequential access to the third > +argument, > +.Fa arg , > +which is rounded up to the nearest block size. > +A zero value in > +.Fa arg > +turns off read ahead. > .El > .Pp > When a shared lock has been set on a segment of a file, > Index: sys/kern/kern_descrip.c > =================================================================== > --- sys/kern/kern_descrip.c (revision 197297) > +++ sys/kern/kern_descrip.c (working copy) > @@ -421,6 +421,7 @@ > struct vnode *vp; > int error, flg, tmp; > int vfslocked; > + uint64_t bsize; > > vfslocked = 0; > error = 0; > @@ -686,6 +687,31 @@ > vfslocked = 0; > fdrop(fp, td); > break; > + > + case F_READAHEAD: > + FILEDESC_SLOCK(fdp); > + if ((fp = fdtofp(fd, fdp)) == NULL) { > + FILEDESC_SUNLOCK(fdp); > + error = EBADF; > + break; > + } > + if (fp->f_type != DTYPE_VNODE) { > + FILEDESC_SUNLOCK(fdp); > + error = EBADF; > + break; > + } > + fhold(fp); > + FILEDESC_SUNLOCK(fdp); > + if (arg) { > + bsize = fp->f_vnode->v_mount->mnt_stat.f_iosize; > + fp->f_seqcount = (arg + bsize - 1) / bsize; > + fp->f_flag |= O_READAHEAD; > + } else { > + fp->f_flag &= ~O_READAHEAD; > + } > + fdrop(fp, td); > + break; > + > default: > error = EINVAL; > break; > Index: sys/kern/vfs_vnops.c > =================================================================== > --- sys/kern/vfs_vnops.c (revision 197297) > +++ sys/kern/vfs_vnops.c (working copy) > @@ -312,6 +312,9 @@ > sequential_heuristic(struct uio *uio, struct file *fp) > { > > + if (fp->f_flag & O_READAHEAD) > + return (fp->f_seqcount << IO_SEQSHIFT); > + > /* > * Offset 0 is handled specially. open() sets f_seqcount to 1 so > * that the first I/O is normally considered to be slightly > Index: sys/sys/fcntl.h > =================================================================== > --- sys/sys/fcntl.h (revision 197297) > +++ sys/sys/fcntl.h (working copy) > @@ -112,7 +112,11 @@ > #if __BSD_VISIBLE > /* Attempt to bypass buffer cache */ > #define O_DIRECT 0x00010000 > +#ifdef _KERNEL > +/* Read ahead */ > +#define O_READAHEAD 0x00020000 > #endif > +#endif > > /* Defined by POSIX Extended API Set Part 2 */ > #if __BSD_VISIBLE > @@ -218,6 +222,7 @@ > #define F_SETLK 12 /* set record locking information */ > #define F_SETLKW 13 /* F_SETLK; wait if blocked */ > #define F_SETLK_REMOTE 14 /* debugging support for remote locks */ > +#define F_READAHEAD 15 /* read ahead */ > > /* file descriptor flags (F_GETFD, F_SETFD) */ > #define FD_CLOEXEC 1 /* close-on-exec flag */ > _______________________________________________ > 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" -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 18 04:40:30 2009 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 2645D1065679; Fri, 18 Sep 2009 04:40:30 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id 627DC8FC18; Fri, 18 Sep 2009 04:40:29 +0000 (UTC) Received: from kas30pipe.localhost (localhost [127.0.0.1]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 521F9130C77; Fri, 18 Sep 2009 08:40:28 +0400 (MSD) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by mailrelay1.rambler.ru (Postfix) with ESMTP id EDE91130C53; Fri, 18 Sep 2009 08:40:27 +0400 (MSD) Date: Fri, 18 Sep 2009 08:40:08 +0400 From: Igor Sysoev To: Alfred Perlstein Message-ID: <20090918044008.GB85663@rambler-co.ru> References: <20090917101526.GF57619@rambler-co.ru> <4AB2B7A1.5000601@delphij.net> <20090917225036.GL21946@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20090917225036.GL21946@elvis.mu.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.33/RELEASE, bases: 02092009 #2738642, status: clean X-SpamTest-Envelope-From: is@rambler-co.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 9536 [Sen 02 2009] X-SpamTest-Info: {received from trusted relay: common white list} X-SpamTest-Method: white ip list X-SpamTest-Rate: 0 X-SpamTest-Status: Trusted X-SpamTest-Status-Extended: trusted X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Cc: freebsd-hackers@freebsd.org, d@delphij.net Subject: Re: fcntl(F_RDAHEAD) 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, 18 Sep 2009 04:40:30 -0000 On Thu, Sep 17, 2009 at 03:50:36PM -0700, Alfred Perlstein wrote: > Please do not make the option have the same name but different > semantics. > > Strongly suggest adding the Darwin name as a toggle and a FreeBSD > name as a specific size option. Then it may be: case F_RDAHEAD: arg = arg ? 128 * 1024: 0; /* FALLTHROUGH F_READAHEAD */ case F_READAHEAD: > -Alfred > > * Xin LI [090917 15:27] wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi, Igor, > > > > Igor Sysoev wrote: > > > Hi, > > > > > > nginx-0.8.15 can use completely non-blocking sendfile() using SF_NODISKIO > > > flag. When sendfile() returns EBUSY, nginx calls aio_read() to read single > > > byte. The first aio_read() preloads the first 128K part of a file in VM cache, > > > however, all successive aio_read()s preload just 16K parts of the file. > > > This makes non-blocking sendfile() usage ineffective for files larger > > > than 128K. > > > > > > I've created a small patch for Darwin compatible F_RDAHEAD fcntl: > > > > > > fcntl(fd, F_RDAHEAD, preload_size) > > > > > > There is small incompatibilty: Darwin's fcntl allows just to enable/disable > > > read ahead, while the proposed patch allows to set exact preload size. > > > > > > Currently the preload size affects vn_read() code path only and does not > > > affect on sendfile() code path. However, it can be easy extended on > > > sendfile() part too. The preload size is still limited by sysctl vfs.read_max. > > > > > > The patch is against FreeBSD 7.2 and was tested on FreeBSD 7.2-STABLE only. > > > > I have ported this as a patch against -HEAD (should apply on 8.0-R but > > it's too late for us to add a new feature) plus a manual page entry > > documenting the feature. > > > > I've used F_READAHEAD as the name, but reading the manual page, it looks > > like we can just use F_RDAHEAD since Darwin seems to just distinguish 0 > > and !=0 case so that programmers won't have to use #ifdef or something > > else to get code working on different platform? > > > > Cheers, > > - -- > > Xin LI http://www.delphij.net/ > > FreeBSD - The Power to Serve! > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.12 (FreeBSD) > > > > iEYEARECAAYFAkqyt40ACgkQi+vbBBjt66AdKgCfXOo/Vn+zw0cCjS+gGJUgPo8t > > WToAmgKIXaVKsKUcqVOqTwHl4eTFsbkM > > =uP3m > > -----END PGP SIGNATURE----- > > > Index: lib/libc/sys/fcntl.2 > > =================================================================== > > --- lib/libc/sys/fcntl.2 (revision 197297) > > +++ lib/libc/sys/fcntl.2 (working copy) > > @@ -28,7 +28,7 @@ > > .\" @(#)fcntl.2 8.2 (Berkeley) 1/12/94 > > .\" $FreeBSD$ > > .\" > > -.Dd March 8, 2008 > > +.Dd September 19, 2009 > > .Dt FCNTL 2 > > .Os > > .Sh NAME > > @@ -241,6 +241,14 @@ > > .Dv SA_RESTART > > (see > > .Xr sigaction 2 ) . > > +.It Dv F_READAHEAD > > +Set or clear the read ahead amount for sequential access to the third > > +argument, > > +.Fa arg , > > +which is rounded up to the nearest block size. > > +A zero value in > > +.Fa arg > > +turns off read ahead. > > .El > > .Pp > > When a shared lock has been set on a segment of a file, > > Index: sys/kern/kern_descrip.c > > =================================================================== > > --- sys/kern/kern_descrip.c (revision 197297) > > +++ sys/kern/kern_descrip.c (working copy) > > @@ -421,6 +421,7 @@ > > struct vnode *vp; > > int error, flg, tmp; > > int vfslocked; > > + uint64_t bsize; > > > > vfslocked = 0; > > error = 0; > > @@ -686,6 +687,31 @@ > > vfslocked = 0; > > fdrop(fp, td); > > break; > > + > > + case F_READAHEAD: > > + FILEDESC_SLOCK(fdp); > > + if ((fp = fdtofp(fd, fdp)) == NULL) { > > + FILEDESC_SUNLOCK(fdp); > > + error = EBADF; > > + break; > > + } > > + if (fp->f_type != DTYPE_VNODE) { > > + FILEDESC_SUNLOCK(fdp); > > + error = EBADF; > > + break; > > + } > > + fhold(fp); > > + FILEDESC_SUNLOCK(fdp); > > + if (arg) { > > + bsize = fp->f_vnode->v_mount->mnt_stat.f_iosize; > > + fp->f_seqcount = (arg + bsize - 1) / bsize; > > + fp->f_flag |= O_READAHEAD; > > + } else { > > + fp->f_flag &= ~O_READAHEAD; > > + } > > + fdrop(fp, td); > > + break; > > + > > default: > > error = EINVAL; > > break; > > Index: sys/kern/vfs_vnops.c > > =================================================================== > > --- sys/kern/vfs_vnops.c (revision 197297) > > +++ sys/kern/vfs_vnops.c (working copy) > > @@ -312,6 +312,9 @@ > > sequential_heuristic(struct uio *uio, struct file *fp) > > { > > > > + if (fp->f_flag & O_READAHEAD) > > + return (fp->f_seqcount << IO_SEQSHIFT); > > + > > /* > > * Offset 0 is handled specially. open() sets f_seqcount to 1 so > > * that the first I/O is normally considered to be slightly > > Index: sys/sys/fcntl.h > > =================================================================== > > --- sys/sys/fcntl.h (revision 197297) > > +++ sys/sys/fcntl.h (working copy) > > @@ -112,7 +112,11 @@ > > #if __BSD_VISIBLE > > /* Attempt to bypass buffer cache */ > > #define O_DIRECT 0x00010000 > > +#ifdef _KERNEL > > +/* Read ahead */ > > +#define O_READAHEAD 0x00020000 > > #endif > > +#endif > > > > /* Defined by POSIX Extended API Set Part 2 */ > > #if __BSD_VISIBLE > > @@ -218,6 +222,7 @@ > > #define F_SETLK 12 /* set record locking information */ > > #define F_SETLKW 13 /* F_SETLK; wait if blocked */ > > #define F_SETLK_REMOTE 14 /* debugging support for remote locks */ > > +#define F_READAHEAD 15 /* read ahead */ > > > > /* file descriptor flags (F_GETFD, F_SETFD) */ > > #define FD_CLOEXEC 1 /* close-on-exec flag */ > > > _______________________________________________ > > 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" > > -- > - Alfred Perlstein > .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 > .- FreeBSD committer -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 18 07:12:01 2009 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 F0323106566C for ; Fri, 18 Sep 2009 07:12:00 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 74B4B8FC1E for ; Fri, 18 Sep 2009 07:12:00 +0000 (UTC) Received: from park.js.berklix.net (p549A4C21.dip.t-dialin.net [84.154.76.33]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id n8I71YD2095991 for ; Fri, 18 Sep 2009 07:01:35 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id n8HM7RBI051313 for ; Fri, 18 Sep 2009 00:07:27 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id n8HM9k4q043009 for ; Fri, 18 Sep 2009 00:09:51 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200909172209.n8HM9k4q043009@fire.js.berklix.net> To: hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Fri, 18 Sep 2009 00:09:46 +0200 Sender: jhs@berklix.com Cc: Subject: genuine cpu I386_CPU kernel 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: Fri, 18 Sep 2009 07:12:01 -0000 Hi hackers, I'm trying to get my Genuine 386 running 7.2. It currently runs 4.11. 386 was first base of FreeBSD, a shame to lose it. So far I've hacked diffs as below + the normal /etc/make.conf CFLAGS += -march=i386 cross compiled all bins libs etc & setenv DESTDIR /usr/7.2 i cd /usr/src/etc l make distrib-dirs cd .. ; make install But manually unloading 4.11 kernel & loading 7.2 kernel & booting doesnt yet boot far enough to encourage me to move bins yet, I think I need to do a bit more kernel before that ? This is what I gave so far. Input welcome. *** /pri/freebsd/releases/7.2-RELEASE/src/sys/./conf/options.i386 Wed Apr 15 05:14:26 2009 --- /usr/src/sys/./conf/options.i386 Thu Sep 17 10:53:11 2009 *************** *** 71,76 **** --- 71,78 ---- NO_MEMORY_HOLE opt_cpu.h # The CPU type affects the endian conversion functions all over the kernel. + // jhs@berklix added I386_CPU + I386_CPU opt_global.h I486_CPU opt_global.h I586_CPU opt_global.h I686_CPU opt_global.h *** /pri/freebsd/releases/7.2-RELEASE/src/sys/./crypto/blowfish/arch/i386/bf_enc.S Wed Apr 15 05:14:26 2009 --- /usr/src/sys/./crypto/blowfish/arch/i386/bf_enc.S Thu Sep 17 10:54:51 2009 *************** *** 10,16 **** * XXX Should use CPP symbols defined as a result of * XXX `cc -mcpu=pentiumpro'. */ ! #if defined(I486_CPU) || defined(I586_CPU) #include "bf_enc_586.S" #else #include "bf_enc_686.S" --- 10,17 ---- * XXX Should use CPP symbols defined as a result of * XXX `cc -mcpu=pentiumpro'. */ ! // jhs@berklix added I386_CPU ! #if defined(I386_CPU) || defined(I486_CPU) || defined(I586_CPU) #include "bf_enc_586.S" #else #include "bf_enc_686.S" *** /pri/freebsd/releases/7.2-RELEASE/src/sys/./i386/conf/GENERIC Wed Apr 15 05:14:26 2009 --- /usr/src/sys/./i386/conf/GENERIC Thu Sep 17 10:56:26 2009 *************** *** 18,23 **** --- 18,24 ---- # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.474.2.17.2.1 2009/04/15 03:14:26 kensmith Exp $ + cpu I386_CPU # jhs@berklix added I386_CPU cpu I486_CPU cpu I586_CPU cpu I686_CPU *** /pri/freebsd/releases/7.2-RELEASE/src/sys/./i386/i386/identcpu.c Wed Apr 15 05:14:26 2009 --- /usr/src/sys/./i386/i386/identcpu.c Thu Sep 17 11:05:05 2009 *************** *** 622,627 **** --- 622,628 ---- break; case CPUCLASS_386: printf("386"); + // jhs@berklix do we need to add code ? break; #if defined(I486_CPU) case CPUCLASS_486: *************** *** 909,915 **** { #if !defined(lint) ! #if !defined(I486_CPU) && !defined(I586_CPU) && !defined(I686_CPU) #error This kernel is not configured for one of the supported CPUs #endif #else /* lint */ --- 910,917 ---- { #if !defined(lint) ! // jhs@berklix added I386_CPU ! #if !defined(I386_CPU) && !defined(I486_CPU) && !defined(I586_CPU) && !defined(I686_CPU) #error This kernel is not configured for one of the supported CPUs #endif #else /* lint */ *************** *** 920,926 **** --- 922,930 ---- */ switch (cpu_class) { case CPUCLASS_286: /* a 286 should not make it this far, anyway */ + #if !defined(I386_CPU) // jhs@berklix added I386_CPU case CPUCLASS_386: + #endif // jhs@berklix added I386_CPU #if !defined(I486_CPU) case CPUCLASS_486: #endif Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail ASCII plain text not HTML & Base64. http://asciiribbon.org Virused Microsoft PCs cause spam. http://berklix.com/free/ From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 18 07:40:55 2009 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 464DC106566B for ; Fri, 18 Sep 2009 07:40:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id BA57F8FC1F for ; Fri, 18 Sep 2009 07:40:54 +0000 (UTC) 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 n8I7eR0h046250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Sep 2009 10:40:28 +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.3/8.14.3) with ESMTP id n8I7eRp8077333; Fri, 18 Sep 2009 10:40:27 +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 n8I7eRvY077332; Fri, 18 Sep 2009 10:40:27 +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, 18 Sep 2009 10:40:27 +0300 From: Kostik Belousov To: d@delphij.net Message-ID: <20090918074027.GI47688@deviant.kiev.zoral.com.ua> References: <20090917101526.GF57619@rambler-co.ru> <4AB2B7A1.5000601@delphij.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iWiB/3aOFpG2Ko/s" Content-Disposition: inline In-Reply-To: <4AB2B7A1.5000601@delphij.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at 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 Cc: freebsd-hackers@freebsd.org Subject: Re: fcntl(F_RDAHEAD) 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, 18 Sep 2009 07:40:55 -0000 --iWiB/3aOFpG2Ko/s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 17, 2009 at 03:26:41PM -0700, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi, Igor, >=20 > Igor Sysoev wrote: > > Hi, > >=20 > > nginx-0.8.15 can use completely non-blocking sendfile() using SF_NODISK= IO > > flag. When sendfile() returns EBUSY, nginx calls aio_read() to read sin= gle > > byte. The first aio_read() preloads the first 128K part of a file in VM= cache, > > however, all successive aio_read()s preload just 16K parts of the file. > > This makes non-blocking sendfile() usage ineffective for files larger > > than 128K. > >=20 > > I've created a small patch for Darwin compatible F_RDAHEAD fcntl: > >=20 > > fcntl(fd, F_RDAHEAD, preload_size) > >=20 > > There is small incompatibilty: Darwin's fcntl allows just to enable/dis= able > > read ahead, while the proposed patch allows to set exact preload size. > >=20 > > Currently the preload size affects vn_read() code path only and does not > > affect on sendfile() code path. However, it can be easy extended on > > sendfile() part too. The preload size is still limited by sysctl vfs.re= ad_max. > >=20 > > The patch is against FreeBSD 7.2 and was tested on FreeBSD 7.2-STABLE o= nly. >=20 > I have ported this as a patch against -HEAD (should apply on 8.0-R but > it's too late for us to add a new feature) plus a manual page entry > documenting the feature. >=20 > I've used F_READAHEAD as the name, but reading the manual page, it looks > like we can just use F_RDAHEAD since Darwin seems to just distinguish 0 > and !=3D0 case so that programmers won't have to use #ifdef or something > else to get code working on different platform? What I dislike about the patch is the new kernel-private flag that is eaten from the open(2) flags namespace. We do already have FHASLOCK, so far the only such flag. --iWiB/3aOFpG2Ko/s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkqzOWsACgkQC3+MBN1Mb4jncwCg9zvfscnUBgH4Jsu1g/vRDRaJ En4An1ZLbdjiRLaEOqhvEUmRoCrP8pq3 =mP+3 -----END PGP SIGNATURE----- --iWiB/3aOFpG2Ko/s-- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 18 13:16:40 2009 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 98E48106566C for ; Fri, 18 Sep 2009 13:16:40 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 4E0D28FC1B for ; Fri, 18 Sep 2009 13:16:40 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 9CE8419997E; Fri, 18 Sep 2009 14:56:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 8E3D419997D; Fri, 18 Sep 2009 14:56:59 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 791C0199976; Fri, 18 Sep 2009 14:56:59 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2FP1HF244) with ESMTP id 2009091814565831-62461 ; Fri, 18 Sep 2009 14:56:58 +0200 Received: by wep4035 (sSMTP sendmail emulation); Fri, 18 Sep 2009 14:56:59 +0200 Date: Fri, 18 Sep 2009 14:56:59 +0200 From: Alexey Shuvaev To: "Julian H. Stacey" Message-ID: <20090918125659.GA88218@wep4035.physik.uni-wuerzburg.de> References: <200909172209.n8HM9k4q043009@fire.js.berklix.net> Mime-Version: 1.0 In-Reply-To: <200909172209.n8HM9k4q043009@fire.js.berklix.net> User-Agent: Mutt/1.4.2.3i Organization: Universitaet Wuerzburg X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 09/18/2009 02:56:58 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 09/18/2009 02:56:58 PM, Serialize complete at 09/18/2009 02:56:58 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: hackers@freebsd.org Subject: Re: genuine cpu I386_CPU kernel 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: Fri, 18 Sep 2009 13:16:40 -0000 On Fri, Sep 18, 2009 at 12:09:46AM +0200, Julian H. Stacey wrote: > Hi hackers, > I'm trying to get my Genuine 386 running 7.2. It currently runs 4.11. > 386 was first base of FreeBSD, a shame to lose it. > So far I've hacked diffs as below + the normal > /etc/make.conf CFLAGS += -march=i386 > cross compiled all bins libs etc & > setenv DESTDIR /usr/7.2 i > cd /usr/src/etc l make distrib-dirs > cd .. ; make install > But manually unloading 4.11 kernel & loading 7.2 kernel & booting > doesnt yet boot far enough to encourage me to move bins yet, > I think I need to do a bit more kernel before that ? > This is what I gave so far. Input welcome. > > [snip] > Have you already looked at svn r137784 (and possibly some later commits)? http://svn.freebsd.org/viewvc/base?view=revision&revision=137784 0.02$, Alexey. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 18 18:39:17 2009 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 6FF98106566B for ; Fri, 18 Sep 2009 18:39:17 +0000 (UTC) (envelope-from remodeler@alentogroup.org) Received: from courriel.marmotmail.com (courriel.marmotmail.com [85.17.36.172]) by mx1.freebsd.org (Postfix) with ESMTP id 317CF8FC15 for ; Fri, 18 Sep 2009 18:39:16 +0000 (UTC) Received: from bruce.epifora.com (localhost.local [127.0.0.1]) by courriel.marmotmail.com (Postfix) with ESMTP id B9AE1239547 for ; Fri, 18 Sep 2009 21:52:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bruce.epifora.com (Postfix) with ESMTP id 5D2534761F9 for ; Fri, 18 Sep 2009 14:49:00 -0400 (EDT) Received: from bruce.epifora.com ([127.0.0.1]) by localhost (bruce.epifora.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17774-07 for ; Fri, 18 Sep 2009 14:48:58 -0400 (EDT) Received: from alentogroup.org (localhost [127.0.0.1]) by bruce.epifora.com (Postfix) with ESMTP id 33BCF4761F8 for ; Fri, 18 Sep 2009 14:48:58 -0400 (EDT) From: "remodeler" To: freebsd-hackers@freebsd.org Date: Fri, 18 Sep 2009 14:48:58 -0400 Message-Id: <20090918182520.M99301@alentogroup.org> X-OriginatingIP: 127.0.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Subject: SOLUTION MBR hack for serial console 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, 18 Sep 2009 18:39:17 -0000 This is a solution to the problem I had. I think others might struggle with it too. John Baldwin kindly helped on this list. The FreeBSD handbook article on setting up serial consoles says "Only sio0 through sio3 (COM1 through COM4) can be used; multiport serial cards will not work". I have a recent motherboard that does not have an on-board serial port, only only has PCI / PCI-e expansion slots. PCI dynamically assigns addresses to devices, and I cannot assign a COM1-COM4 address (0x3F8, 0x2F8, 0x3E8 or 0x2E8) to my single-port PCI serial card because a different PCI-PCI bridge has a bit set claiming the legacy addresses. I cannot modify the use of the legacy com address for the serial console in the boot0 code, due to its single-sector size and complexity. It uses PC BIOS calls to access a serial console, and I do not have access to the proprietary motherboard BIOS to change the mapping below boot0. For this reason, creating /boot.config with a flag enabling the serial console (-P, etc.) causes a lockup on boot before boot0 outputs the "F1: FreeBSD" menu. I can catch the serial console during initialization of the loader, though, and can drop to single-user mode or the loader prompt remotely. I specified my non-legacy serial console address in /etc/make.conf and rebuilt the kernel: BOOT_COMCONSOLE_PORT= 0xE800 I set the port and speed in the boot2 Makefile (/usr/src/sys/boot/i386 - it's an AMD64 machine but amd64 still uses the i386 boot blocks): BOOT_COMCONSOLE_PORT?= 0xe800 BOOT_COMCONSOLE_SPEED?= 115200 Rebuilt the boot blocks and wrote the new boot blocks out: # cd /sys/boot # make clean # make # make install # bsdlabel -B /dev/boot_disk I added the console flag to the serial device in /boot/device.hints (could be sio driver instead of uart, this is on 9.0-HEAD): hint.uart.0.port="0xE800" hint.uart.0.flags="0x10" hint.uart.0.irq="20" And last I set these environmental variables in /boot/loader.conf: console="comconsole" comconsole_speed="115200" My goal was a headless remote server w/o high-end server gear, so I didn't set "boot_multicons". I didn't see any effect to setting "boot_serial" in the loader configuration file. I have a fully functioning serial console ;) __ __ ________ ____ ___ ____ ____/ /__ / /__ _____ / ___/ _ \/ __ `__ \/ __ \/ __ / _ \/ / _ \/ ___/ / / / __/ / / / / / /_/ / /_/ / __/ / __/ / /_/ \___/_/ /_/ /_/\____/\__,_/\___/_/\___/_/ The information contained in this message is confidential and is intended for the addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 18 23:49:04 2009 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 93CE4106566B for ; Fri, 18 Sep 2009 23:49:04 +0000 (UTC) (envelope-from remodeler@alentogroup.org) Received: from courriel.marmotmail.com (courriel.marmotmail.com [85.17.36.172]) by mx1.freebsd.org (Postfix) with ESMTP id 5386F8FC14 for ; Fri, 18 Sep 2009 23:49:04 +0000 (UTC) Received: from bruce.epifora.com (localhost.local [127.0.0.1]) by courriel.marmotmail.com (Postfix) with ESMTP id EBFBE239524 for ; Sat, 19 Sep 2009 03:02:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bruce.epifora.com (Postfix) with ESMTP id 26F564761F9 for ; Fri, 18 Sep 2009 19:58:50 -0400 (EDT) Received: from bruce.epifora.com ([127.0.0.1]) by localhost (bruce.epifora.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22278-10 for ; Fri, 18 Sep 2009 19:58:48 -0400 (EDT) Received: from alentogroup.org (localhost [127.0.0.1]) by bruce.epifora.com (Postfix) with ESMTP id B66814761F8 for ; Fri, 18 Sep 2009 19:58:48 -0400 (EDT) From: "remodeler" To: freebsd-hackers@freebsd.org Date: Fri, 18 Sep 2009 19:58:48 -0400 Message-Id: <20090918235822.M19955@alentogroup.org> X-OriginatingIP: 127.0.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Subject: Re: SOLUTION MBR hack for serial console 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, 18 Sep 2009 23:49:04 -0000 > I found your Email most helpful thank you. if I may ask, how do you > get vim to display the correct rows and columns? > I am using a xterm on a 1440x900 monitor and ssh to another FreeBSD > machine that has my serial cable to my server. > vim appears a very small, do you know how to change this? > > Sam Fourman Jr. I left out the change to /etc/ttys in my original solution e-mail; something like the following to set a line type for the tty: ttyu0 "/usr/libexec/getty std.9600" vt100 on insecure vt100 is a 80 column x 24 line terminal. I think using vt100-w instead would give you a 132 column line (described in termcap(5)). __ __ ________ ____ ___ ____ ____/ /__ / /__ _____ / ___/ _ \/ __ `__ \/ __ \/ __ / _ \/ / _ \/ ___/ / / / __/ / / / / / /_/ / /_/ / __/ / __/ / /_/ \___/_/ /_/ /_/\____/\__,_/\___/_/\___/_/ The information contained in this message is confidential and is intended for the addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited.