From owner-freebsd-stable@FreeBSD.ORG Sun May 5 01:00:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 16675AE6 for ; Sun, 5 May 2013 01:00:13 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [186.193.48.13]) by mx1.freebsd.org (Postfix) with ESMTP id 96BCE8CB for ; Sun, 5 May 2013 01:00:11 +0000 (UTC) Received: from zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [127.0.0.1]) by zeus.linuxinfo.com.br (Postfix) with ESMTP id C4997466A45D for ; Sat, 4 May 2013 21:49:24 -0300 (BRT) X-Virus-Scanned: amavisd-new at zeus.linuxinfo.com.br Received: from zeus.linuxinfo.com.br ([127.0.0.1]) by zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7QwfUxPgHut for ; Sat, 4 May 2013 21:49:22 -0300 (BRT) Received: from MacBook-de-Gondim-2.local (unknown [186.193.54.69]) by zeus.linuxinfo.com.br (Postfix) with ESMTPSA id 6E508466A458 for ; Sat, 4 May 2013 21:49:15 -0300 (BRT) Message-ID: <5185AD0F.3060906@bsdinfo.com.br> Date: Sat, 04 May 2013 21:51:27 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Possible DoS in mpd 5.6 pppoe server References: <5172965A.9080600@bsdinfo.com.br> <5172BDDD.4010509@rdtc.ru> <5172CFB2.3010708@bsdinfo.com.br> <5172D14D.8040009@rdtc.ru> <51731FFE.5020304@bsdinfo.com.br> <5173F0C3.2040102@rdtc.ru> In-Reply-To: <5173F0C3.2040102@rdtc.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 01:00:13 -0000 Em 21/04/13 10:59, Eugene Grosbein escreveu: > On 21.04.2013 06:08, Marcelo Gondim wrote: >> Em 20/04/13 14:33, Eugene Grosbein escreveu: >>> On 21.04.2013 00:26, Marcelo Gondim wrote: >>> >>>>> You seem to use dummynet and the problem is not in mpd/pppoe code, >>>>> it's it the dummynet code. Look at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/162558 >>>>> for workarounds. >>>> Ok :) I will try this: >>>> >>>> - net.isr.bindthreads=1 in /boot/loader.conf; >>>> - net.isr.direct=1 and net.isr.direct_force=1 in /etc/sysctl.conf >>> For 9.x and newer, net.isr.XXX knobs names have changed but defaults are fine - >>> if you have not messed them, you should be OK. >>> >>> >>> >> Eugene, >> >> Does FreeBSD 8.3-STABLEis best for this use or this problem also occurs >> in 8.x? > I have not tried anything newer than 8.x for this task yet. > With noted tuning, this problem within dummynet occurs very seldom for me. > I had about two or three panics for many months. Another one described here: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/171711 > > Perhaps, using ng_car would be even more stable, I have not tried it. > > Eugene Grosbein > > Hi all, I changed hardware for motherboard Supermicro X9SCM-F and Xeon processor 3.2Ghz E31230 with 8Gb ram ECC. The problem stopped and the server was very stable. The problem could be with the Intel motherboard S5500BC? Because this was installed with 2 Xeon processors and two memory banks 4Gb. Could be FreeBSD incompatibility with the hardware or faulty hardware? Thanks and best regards, Gondim From owner-freebsd-stable@FreeBSD.ORG Sun May 5 07:22:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 350D89CC for ; Sun, 5 May 2013 07:22:13 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id CEE0C29F for ; Sun, 5 May 2013 07:22:12 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r457Lt2i032110; Sun, 5 May 2013 14:21:57 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5186088E.9040804@rdtc.ru> Date: Sun, 05 May 2013 14:21:50 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Marcelo Gondim Subject: Re: Possible DoS in mpd 5.6 pppoe server References: <5172965A.9080600@bsdinfo.com.br> <5172BDDD.4010509@rdtc.ru> <5172CFB2.3010708@bsdinfo.com.br> <5172D14D.8040009@rdtc.ru> <51731FFE.5020304@bsdinfo.com.br> <5173F0C3.2040102@rdtc.ru> <5185AD0F.3060906@bsdinfo.com.br> In-Reply-To: <5185AD0F.3060906@bsdinfo.com.br> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 07:22:13 -0000 On 05.05.2013 07:51, Marcelo Gondim wrote: > I changed hardware for motherboard Supermicro X9SCM-F and Xeon processor > 3.2Ghz E31230 with 8Gb ram ECC. The problem stopped and the server was > very stable. > The problem could be with the Intel motherboard S5500BC? Because this > was installed with 2 Xeon processors and two memory banks 4Gb. > Could be FreeBSD incompatibility with the hardware or faulty hardware? > > Thanks and best regards, I don't think so. The race problem is known. It has software nature and crash probability depends of many reasons. The change of hardware changes some of aspects, indeed :-) In your case it somehow made the server more stable but that's not any kind of hardware incompatibility. From owner-freebsd-stable@FreeBSD.ORG Sun May 5 13:04:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1D3241A5 for ; Sun, 5 May 2013 13:04:22 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [186.193.48.13]) by mx1.freebsd.org (Postfix) with ESMTP id B7988D5A for ; Sun, 5 May 2013 13:04:21 +0000 (UTC) Received: from zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [127.0.0.1]) by zeus.linuxinfo.com.br (Postfix) with ESMTP id CA625466A45D for ; Sun, 5 May 2013 10:02:05 -0300 (BRT) X-Virus-Scanned: amavisd-new at zeus.linuxinfo.com.br Received: from zeus.linuxinfo.com.br ([127.0.0.1]) by zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSBk8PsWi1nc for ; Sun, 5 May 2013 10:02:03 -0300 (BRT) Received: from MacBook-de-Gondim-2.local (unknown [186.193.54.69]) by zeus.linuxinfo.com.br (Postfix) with ESMTPSA id E7322466A45B for ; Sun, 5 May 2013 10:01:59 -0300 (BRT) Message-ID: <518658CC.70408@bsdinfo.com.br> Date: Sun, 05 May 2013 10:04:12 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Possible DoS in mpd 5.6 pppoe server References: <5172965A.9080600@bsdinfo.com.br> <5172BDDD.4010509@rdtc.ru> <5172CFB2.3010708@bsdinfo.com.br> <5172D14D.8040009@rdtc.ru> <51731FFE.5020304@bsdinfo.com.br> <5173F0C3.2040102@rdtc.ru> <5185AD0F.3060906@bsdinfo.com.br> <5186088E.9040804@rdtc.ru> In-Reply-To: <5186088E.9040804@rdtc.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 13:04:22 -0000 Em 05/05/13 04:21, Eugene Grosbein escreveu: > On 05.05.2013 07:51, Marcelo Gondim wrote: > >> I changed hardware for motherboard Supermicro X9SCM-F and Xeon processor >> 3.2Ghz E31230 with 8Gb ram ECC. The problem stopped and the server was >> very stable. >> The problem could be with the Intel motherboard S5500BC? Because this >> was installed with 2 Xeon processors and two memory banks 4Gb. >> Could be FreeBSD incompatibility with the hardware or faulty hardware? >> >> Thanks and best regards, > I don't think so. The race problem is known. It has software nature > and crash probability depends of many reasons. The change of hardware > changes some of aspects, indeed :-) In your case it somehow > made the server more stable but that's not any kind of hardware incompatibility. > > > Does any developer is seeing this problem? Because I saw the prthat has been going on since 2011. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/162558 I'm trying to replace severalMikrotik RouterOS (PPPoE server) for FreeBSD with mpd + freeradius + mysql. All my servers are FreeBSD except PPPoE Server. :( Best regards, From owner-freebsd-stable@FreeBSD.ORG Mon May 6 00:14:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 83A8615B for ; Mon, 6 May 2013 00:14:53 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 3EA4931A for ; Mon, 6 May 2013 00:14:53 +0000 (UTC) Received: by mail-vb0-f47.google.com with SMTP id x14so2523405vbb.6 for ; Sun, 05 May 2013 17:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=x-received:subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; bh=CWgmwochS0FNwxStOOfAeJkqOkKZ0r3ODwS2ruWz9ko=; b=R9CyqGKbiW0aa6357pKscSI/4rC6zonHcWTtouqRdd0m9GSj0WdmS7VdBHJtKP7x9B gC6m5uRYvbbJhMmD+tj+/KePP+qiQqVZC2vB/Inive3/7dvURpdclNxotOs5XrFaYUtq EEjvLQtn8pZFXyKwfuF5H+eNtfN5syOTLU060= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version:x-gm-message-state; bh=CWgmwochS0FNwxStOOfAeJkqOkKZ0r3ODwS2ruWz9ko=; b=k/l/b1D9FW/+7xSZe2Yn3AVOZXbCH9AiLbrojStktensKffNga4TW5LbZ6iecR3igR gT8MB0vezQml+Fm/5VT9HTTZJHNM4gUemMIFoXbsxkSom0pwCYL9pDizGkSYo2sgzybN m+0PQKZpPKfjSZwPeEa7HIVc39oK7nBFQOk1X5QN+jYJLL/wC0Tfjf1ipQJ0sEWw1j+9 hJn0LFyzNQescfCGAUg7ft2D9QzbwoYH+0/faOID7cG9vhNv02z3glyEuOi+6//r+hcJ s63FxZHB2JR7jGlkHYc0bnx4262Z3zTcZOX3Y6jWg93ygjKONta5Q6N86edDUBPCAeZQ 9yFw== X-Received: by 10.52.65.144 with SMTP id x16mr5193018vds.123.1367799292716; Sun, 05 May 2013 17:14:52 -0700 (PDT) Received: from [192.168.30.77] (24-236-152-143.dhcp.aldl.mi.charter.com. [24.236.152.143]) by mx.google.com with ESMTPSA id l6sm14941929vdh.3.2013.05.05.17.14.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 May 2013 17:14:51 -0700 (PDT) Subject: Login failures usefulness with OpenSSH 6.1 From: Jason Hellenthal X-Mailer: iPhone Mail (10B329) Message-Id: <358B4722-3277-4A3B-93F3-33479A7D4682@DataIX.net> Date: Sun, 5 May 2013 20:14:49 -0400 To: "freebsd-security@freebsd.org" , "freebsd-stable@freebsd.org" Mime-Version: 1.0 (1.0) X-Gm-Message-State: ALoCoQkumC9ncZlA2ilcGHrUwYghtmaHd6jRZ8jeedZqNzUcd+JcYo4okYKEU3e8PekT6ArxAvy+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 00:14:53 -0000 Hello everyone, It seems that the login failures reported by the security output of a nightl= y periodic job has become somewhat useless per OpenSSH 6.1. I used to get username and IP address in the output but it seems that the lo= gging format has changed. Instead of one line the log format now has two lin= es. One like the ones below and then another coinciding line that contains I= P address and username. I think it would be more beneficial outputting the lines with the ip and use= rname over the ones below for the security output. Not sure exactly when this changed but would like to gather some input befor= e I inspect further on the changes that would have to be made. My output is from SVN FreeBSD STABLE 8.3 as of yesterday. Thanks & Clean Regards, ...Sample output... login failures: May 4 00:04:35 disbatch sshd[48898]: fatal: Write failed: Operation not per= mitted May 4 14:54:14 disbatch sshd[9544]: input_userauth_request: invalid user ro= ot [preauth] May 4 18:44:04 disbatch sshd[18326]: fatal: Read from socket failed: Connec= tion reset by peer [preauth] --=20 Jason Hellenthal JJH48-ARIN -(2^(N-1)) From owner-freebsd-stable@FreeBSD.ORG Mon May 6 17:48:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A5618D3A for ; Mon, 6 May 2013 17:48:25 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 8548F603 for ; Mon, 6 May 2013 17:48:25 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id ro12so2124401pbb.4 for ; Mon, 06 May 2013 10:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=4c5cdQpQMoOo+rBLe+2jAI/HlzoDXdUyEWrLQfFnU0k=; b=QczitrvCXhaeXV8/wNdvZZEXGoNOTql1rCct6yw4vgLwntZe1CtrQXVKsbJQ82M0qy LOzv3pgpi/TuZVmpm7EeRZijzsDbjzAWy9dBVY7Qfcbx1Ek/HIuh9iQ/pXfCA1Arx+k7 vxr1XA8sch01hOwJHA3eRHcZcdTpEtUdx1kjZ5KiiDi64KnWOmnzkHn89seHiBL7Lbij 8vT+k46UeO5i9o6hmzRWt7RKjlfak2EG0r0mIRobkuF5Cb7+soEUA/HyTAgTzEws8toj bIviRpCja9tjTB+q8PAv6jrDtOD2xJdasgleZkNW4fg1zFcoI4BYjJZDIfCBa9aKMdyU vqGg== X-Received: by 10.66.74.170 with SMTP id u10mr27997654pav.202.1367862505337; Mon, 06 May 2013 10:48:25 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id 12sm3675994pay.5.2013.05.06.10.48.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 May 2013 10:48:23 -0700 (PDT) Message-ID: <5187ECE6.2030205@gmail.com> Date: Mon, 06 May 2013 10:48:22 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130506 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: multiple NFS mounts with bg,retrycount=0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 17:48:25 -0000 I updated a FreeBSD 9-STABLE system to r250290 and noticed an NFS oddity -- fstab entries that specify a retrycnt are mounted multiple times. I have this in /etc/fstab: xxxx:/remote/yyyy /local/zzzz nfs rw,bg,retrycnt=0 0 0 And this in /etc/rc.conf: rpcbind_enable="YES" nfs_client_enable="YES" nfs_server_enable="YES" nfsv4_server_enable="YES" nfsuserd_flags="-domain XXXXXX" rpc_lockd_enable="YES" rpc_statd_enable="YES" If I run mount immediately after the system boots up I don't see anything mounted on /local/zzzz. If I wait a minute or so and recheck I see two identical mounts on /local/zzzz. # mount | grep /local xxxx:/remote/yyyy on /local/zzzz (nfs) xxxx:/remote/yyyy on /local/zzzz (nfs) It is almost as if the system tried to mount the remote FS, failed, and then forked multiple (?) processes to retry the operation, and all of them succeed later. Unfortunately, I can't reboot the system for a couple of days so I can't go looking for mount_nfs processes right after a fresh boot. Regards, Navdeep From owner-freebsd-stable@FreeBSD.ORG Mon May 6 18:45:15 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 16C92E9D; Mon, 6 May 2013 18:45:15 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D0FEAA5F; Mon, 6 May 2013 18:45:14 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 36872DEE2; Mon, 6 May 2013 18:45:08 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id F252B35C4C; Mon, 6 May 2013 20:45:08 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jason Hellenthal Subject: Re: Login failures usefulness with OpenSSH 6.1 References: <358B4722-3277-4A3B-93F3-33479A7D4682@DataIX.net> Date: Mon, 06 May 2013 20:45:08 +0200 In-Reply-To: <358B4722-3277-4A3B-93F3-33479A7D4682@DataIX.net> (Jason Hellenthal's message of "Sun, 5 May 2013 20:14:49 -0400") Message-ID: <86vc6wgd6z.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-security@freebsd.org" , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 18:45:15 -0000 Jason Hellenthal writes: > I used to get username and IP address in the output but it seems that > the logging format has changed. Instead of one line the log format now > has two lines. One like the ones below and then another coinciding > line that contains IP address and username. It will be much easier to help you if you show us exactly what you expected and what you got instead. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Mon May 6 19:46:51 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CEA642AE for ; Mon, 6 May 2013 19:46:51 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id 951A9ECC for ; Mon, 6 May 2013 19:46:51 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id jy13so3554162veb.23 for ; Mon, 06 May 2013 12:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pIasxyIxJZR1aaYShs++q9ttg7EboJ/3ksv0aKYxog0=; b=FRJrJOkL8DA/3D2WgBg+8dJkIf6vVgylJR8bzvsTevrZ7Z6v6qw6Nu2vbufkGUd2S/ 4Hqkjh5tf0ZrzzkWHGDRhqQR5iNRiwyjGCE9Q++lpd7cVecN/PdIkBQbg8sRosV8h/sD OQKFuOXp27Rf+/Gd1VivR3NTlOD0JXcZDdPt9ko80rJxgeaVVAdseQKlWjKIXMuRN3rU gJuW0s1TFUfhEGadR+JV/ZMz1MPPlJOapFoiGA3H28CBIi1AS/RtwkGI6LGgG+7SRbW6 ueq+WyrLuyUi73Fny6dLtrBuCTMzR85kT1fvSFmz9Tzmqcw1Hi43hDtFIWZoa1KCS87L aRng== MIME-Version: 1.0 X-Received: by 10.52.19.66 with SMTP id c2mr1841566vde.2.1367869611209; Mon, 06 May 2013 12:46:51 -0700 (PDT) Received: by 10.220.33.135 with HTTP; Mon, 6 May 2013 12:46:51 -0700 (PDT) In-Reply-To: <5187ECE6.2030205@gmail.com> References: <5187ECE6.2030205@gmail.com> Date: Mon, 6 May 2013 15:46:51 -0400 Message-ID: Subject: Re: multiple NFS mounts with bg,retrycount=0 From: Zaphod Beeblebrox To: Navdeep Parhar Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 19:46:51 -0000 [about double background NFS mounts] I'm not sure on the fix to this, but I'm pretty sure it's because we retry the mount -a stuff twice at startup. If you watch your console, you'll see two places where it will "mount NFS filesystems" during boot. ... well... a fix to this would be to _not_ do that twice ... but hey :). From owner-freebsd-stable@FreeBSD.ORG Mon May 6 20:10:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7552F666 for ; Mon, 6 May 2013 20:10:04 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by mx1.freebsd.org (Postfix) with ESMTP id 5AD15DE for ; Mon, 6 May 2013 20:10:04 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta12.emeryville.ca.mail.comcast.net with comcast id Yigj1l0051zF43QACkA3iT; Mon, 06 May 2013 20:10:03 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta24.emeryville.ca.mail.comcast.net with comcast id YkA21l00M1t3BNj8kkA2gf; Mon, 06 May 2013 20:10:03 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 40ADC73A33; Mon, 6 May 2013 13:10:02 -0700 (PDT) Date: Mon, 6 May 2013 13:10:02 -0700 From: Jeremy Chadwick To: Zaphod Beeblebrox Subject: Re: multiple NFS mounts with bg,retrycount=0 Message-ID: <20130506201002.GA21928@icarus.home.lan> References: <5187ECE6.2030205@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367871003; bh=EjtLbpxVYmEJXGu6jzo1bLECWiej1Nkp2YnpqODJC6k=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=HW/egTUUm75rT5agqFrSjIHL7jquKbMKJoDZH6LjmW5HvE9Wxc/Gq9sRUgWBUtOVO 9sHudMxkqBURSsB2DHfWdRpQj8dTQx6ZjJRIIAFoMcazIFEJva0rlRHDQeQ7ZliWjz Bezlt0ZN2q41jNV3qUsvxX+TOiaJ1okNMMGRwt3xO+R/IwCY5uWxSUiajoJI107b5i W/Nj5Nqbrw1L1wtywSQKSD9r2A9bvDYlVY0JY8iwJIkaP8o+EKrz1x4N5H69jWCRMs wLE1XgniiDIaDlgHzemj+cKkbXVc4ilfB3JS7Z3e4Gy7Pfm0PxiFeLOHx6qOoV4iJy 42fHYQmGqs0VA== Cc: FreeBSD Stable , Navdeep Parhar X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 20:10:04 -0000 On Mon, May 06, 2013 at 03:46:51PM -0400, Zaphod Beeblebrox wrote: > [about double background NFS mounts] > > I'm not sure on the fix to this, but I'm pretty sure it's because we retry > the mount -a stuff twice at startup. If you watch your console, you'll see > two places where it will "mount NFS filesystems" during boot. > > ... well... a fix to this would be to _not_ do that twice ... but hey :). Preface: I'm not aware of mount(8) actually permitting the mounting of two NFS filesystems at the same mountpoint (e.g. wouldn't the 2nd one throw EPERM or some other condition?). When I ran my co-lo, we used NFS on many client machines (on RELENG_8 and RELENG_9) and we *never* saw multiple mounts (to the same mountpoint) on reboot. I also don't remember seeing the message in question twice -- only once. That said: Can you please determine if /etc/rc.d/mountcritremote is doing this? This is the only script which issues such echo statements. The relevant portion of the script: 35 mountcritremote_start() 36 { 37 # Mount nfs filesystems. 38 # 39 case "`/sbin/mount -d -a -t nfs`" in 40 '') 41 ;; 42 *) 43 echo -n 'Mounting NFS file systems:' 44 mount -a -t nfs 45 echo '.' 46 ;; 47 esac 48 49 # Mount other network filesystems if present in /etc/fstab. 50 case ${extra_netfs_types} in 51 [Nn][Oo]) 52 ;; 53 *) 54 netfs_types="${netfs_types} ${extra_netfs_types}" 55 ;; 56 esac 57 58 for i in ${netfs_types}; do 59 fstype=${i%:*} 60 fsdecr=${i#*:} 61 62 [ "${fstype}" = "nfs" ] && continue 63 64 case "`mount -d -a -t ${fstype}`" in 65 *mount_${fstype}*) 66 echo -n "Mounting ${fsdecr} file systems:" 67 mount -a -t ${fstype} 68 echo '.' 69 ;; 70 esac 71 done And the defaults for $netfs_types and $extra_netfs_types: netfs_types="nfs:NFS oldnfs:OLDNFS smbfs:SMB portalfs:PORTAL nwfs:NWFS" # Net filesystems. extra_netfs_types="NO" # List of network extra filesystem types for delayed Now look at lines 58 through 62 above (specifically 62). $fstype should contain "nfs" thus should be skipped over. And "oldnfs" would cause the echo statement to be "Mounting OLDNFS file systems:". If you could try to figure out where/what rc script is causing this for you, that'd be great. And a final point: disclose of exactly what FreeBSD version you're using (including build date or SVN rXXXXXX number) would be wonderful. The reason I mention that is because mountcritremote has been adjusted **after** 9.1-RELEASE (see r242153): http://svnweb.freebsd.org/base/stable/9/etc/rc.d/mountcritremote Let us know what you find. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon May 6 21:58:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 474B93AE for ; Mon, 6 May 2013 21:58:30 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 0CCC9A1A for ; Mon, 6 May 2013 21:58:29 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UZTQT-002pmE-0X>; Mon, 06 May 2013 23:58:29 +0200 Received: from f052014224.adsl.alicedsl.de ([78.52.14.224] helo=[192.168.0.128]) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UZTQS-002voA-S8>; Mon, 06 May 2013 23:58:28 +0200 Subject: Re: multiple NFS mounts with bg,retrycount=0 From: "O. Hartmann" To: Navdeep Parhar In-Reply-To: <5187ECE6.2030205@gmail.com> References: <5187ECE6.2030205@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-SU8coZc9EdGw++XBD2KQ" Date: Mon, 06 May 2013 23:58:28 +0200 Message-ID: <1367877508.2552.12.camel@thor.walstatt.dyndns.org> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Originating-IP: 78.52.14.224 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 21:58:30 -0000 --=-SU8coZc9EdGw++XBD2KQ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mon, 2013-05-06 at 10:48 -0700, Navdeep Parhar wrote: > I updated a FreeBSD 9-STABLE system to r250290 and noticed an NFS oddity > -- fstab entries that specify a retrycnt are mounted multiple times. >=20 > I have this in /etc/fstab: > xxxx:/remote/yyyy /local/zzzz nfs rw,bg,retrycnt=3D0 0 0 >=20 > And this in /etc/rc.conf: > rpcbind_enable=3D"YES" > nfs_client_enable=3D"YES" > nfs_server_enable=3D"YES" > nfsv4_server_enable=3D"YES" > nfsuserd_flags=3D"-domain XXXXXX" > rpc_lockd_enable=3D"YES" > rpc_statd_enable=3D"YES" >=20 > If I run mount immediately after the system boots up I don't see > anything mounted on /local/zzzz. If I wait a minute or so and recheck I > see two identical mounts on /local/zzzz. >=20 > # mount | grep /local > xxxx:/remote/yyyy on /local/zzzz (nfs) > xxxx:/remote/yyyy on /local/zzzz (nfs) >=20 > It is almost as if the system tried to mount the remote FS, failed, and > then forked multiple (?) processes to retry the operation, and all of > them succeed later. Unfortunately, I can't reboot the system for a > couple of days so I can't go looking for mount_nfs processes right after > a fresh boot. >=20 > Regards, > Navdeep I see the very same here on FreeBSD 10.0-CURRENT boxes (two boxes acting as NFSv4 server). The clients (all FBSD 10, one 9.1-STABLE) have two(!) identical mounts of the very same filesystem. /etc/fstab does contain the mount option "bg", but not "retrycnt=3D0". This behaviour happens on ALL FBSD 10.0-CURRENT boxes I administer (10.0-CURRENT #0 r250275: Sun May 5 18:40:17 CEST 2013 amd64). Regards, Oliver --=-SU8coZc9EdGw++XBD2KQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQEcBAABAgAGBQJRiCd/AAoJEOgBcD7A/5N8Fw4H/1KAm5Mfc1VUzmCQdvbKychW 6ErqU8gjL67YTGVheCJXC/6pCyQ3eKSzzoXclQIMgysqwdNMNbC5K7Ad/bvgM0Mt +WLhd1WMSKIKr6/KRFwRU8Kc1c+blEZffdMi7eq0lQtKmHrgyKLX7uklGROUylui TSGmv6/5mxcthIGQBdehptpuVeswJAr6piTzNUZGyVU68JKM58WZflRzwOTyN0pP hFfrY1xOlZxGoPGJ4AFX9lZLWY/VU/lcsfA/h6g/m+DSk9h58PgOcQ0dDdvp7diz Sh10kA60vOIdD+7m3k5Hp0B+8bY5778tXCrNKf2nU7lIo8JzAsPLjkczRlkLN68= =164N -----END PGP SIGNATURE----- --=-SU8coZc9EdGw++XBD2KQ-- From owner-freebsd-stable@FreeBSD.ORG Mon May 6 23:09:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4E8A960E for ; Mon, 6 May 2013 23:09:27 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 18C29E43 for ; Mon, 6 May 2013 23:09:26 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAAA3iFGDaFvO/2dsb2JhbABQgz6DPLtMgRx0gh8BAQEEAQEBIAQnIAsFFg4KAgINGQIpAQkmBggHBAEcBIdrDK91kHCBJIxbfjQHgkCBEwOUbIJCgSaQDoMpIDKBBDU X-IronPort-AV: E=Sophos;i="4.87,624,1363147200"; d="scan'208";a="28612602" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 06 May 2013 19:09:20 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 4C5F0B3F26; Mon, 6 May 2013 19:09:20 -0400 (EDT) Date: Mon, 6 May 2013 19:09:20 -0400 (EDT) From: Rick Macklem To: Zaphod Beeblebrox Message-ID: <1344702318.161364.1367881760297.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: multiple NFS mounts with bg,retrycount=0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: FreeBSD Stable , Navdeep Parhar X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 23:09:27 -0000 Zaphrod Beeblebrox wrote: > [about double background NFS mounts] > > I'm not sure on the fix to this, but I'm pretty sure it's because we > retry > the mount -a stuff twice at startup. If you watch your console, you'll > see > two places where it will "mount NFS filesystems" during boot. > > ... well... a fix to this would be to _not_ do that twice ... but hey > :). There was just a commit to head (r250253) which adds a "-L" option to mount, so that only "late" file systems are mounted, to avoid this. Without this, what I think happens is: A - "mount -a" --> initial mount attempt fails and goes background B - "mount -a -l" --> succeeds in doing the mount, since it isn't mounted yet - background mount_nfs from (A) wakes up and does the mount again Yes, doing the mount twice will work and the second mount covers up the first one. This is relatively harmless, although it will take 2 umounts to get rid of the mount (the first umount just uncovers the first mount). You could try marking the /etc/fstab line(s) for the mounts "late". (since you use "bg", I'm assuming they aren't needed to be done for the startup scripts) That way they would only be mounted for the "mount -a -l" case, I think. rick > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon May 6 23:15:59 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2FC04B98 for ; Mon, 6 May 2013 23:15:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id EE789EC1 for ; Mon, 6 May 2013 23:15:58 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAEk4iFGDaFvO/2dsb2JhbABGCoM+gzy7TIEcdIIfAQEBBAEBASArIAsFFg4KAgINGQIpAQkmBggHBAEcBIdrDK96kHCBJIxRCn40B4JAgRMDlGyCQoEmkA6DKSAygQQ1 X-IronPort-AV: E=Sophos;i="4.87,624,1363147200"; d="scan'208";a="28613059" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 06 May 2013 19:15:57 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C5580B3F47; Mon, 6 May 2013 19:15:57 -0400 (EDT) Date: Mon, 6 May 2013 19:15:57 -0400 (EDT) From: Rick Macklem To: Andrew Romanenko Message-ID: <1312928719.161414.1367882157754.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <51843432.6060401@gmail.com> Subject: Re: /usr/src over NFS: buildworld fail MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Jeremy Chadwick , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 23:15:59 -0000 Andrew Romanenko wrote: > On 05/02/2013 01:30 AM, Rick Macklem wrote: > > Andrew Romanenko wrote: > >> On 04/30/2013 02:51 AM, Jeremy Chadwick wrote: > >>> On Mon, Apr 29, 2013 at 09:42:06PM +0300, Andrew Romanenko wrote: > >>>> Hi everyone! > >>>> /usr/src imported via NFS > >>>> make buildworld is always fails in the same place with error: > >>>> "make: result too large". > >>>> Localy its works fine > >>>> Does anybody know how to fix it? > >>>> > >>>> i386 FreeBSD 9-STABLE (r250044) > >>> Actual output would have been more useful than a paraphrased > >>> response. > >>> The same goes for actual NFS server and client details (OS, > >>> backing > >>> filesystems, make.conf, src.conf, rc.conf, loader.conf, > >>> sysctl.conf, > >>> etc.). > >>> > >>> "Result too large" is error ERANGE (see /usr/include/errno.h), > >>> errno > >>> 34, > >>> assuming that it has a capital "R" ("Result", not "result"). > >>> > >>> I see no cases in src/usr.bin/make/* where ERANGE or errno 34 is > >>> returned directly. > >>> > >>> I do not believe NFS returns ERANGE either. > >>> > >>> There may be cases where the backing filesystem (i.e. the > >>> filesystem > >>> used on the NFS server) could return ERANGE. I know ZFS does, but > >>> only > >>> in one specific case (only if the compression property is > >>> enabled). > >>> I do see some other cases in the ZFS code pertaining to UTF-8 > >>> support > >>> that can return ERANGE but did not look at what those cases may > >>> be. > >>> > >>> You may end up having to do the following: > >>> > >>> rm -fr /usr/obj/* > >>> cd /usr/src > >>> ktrace -t+ -f /tmp/ktrace.out make buildworld > >>> {wait until the failure} > >>> cd /tmp > >>> kdump > >>> > >>> Then look to see what syscall/operation returns this. You may have > >>> to > >>> put this file up on the web somewhere (it should gzip quite well), > >>> and > >>> be aware there may be personal information in it (environment > >>> variables, > >>> contents of files, etc.), so choose wisely. > >>> > >>> Good luck. > >>> > >> Fixed. Trouble was in Linux NFS-server. > >> Also, thx Jeremy for the tip (ktrace + kdump) > >> thanks, everyone > >> > > Coule you please provide more information on the Linux NFS-server > > issue? > > It might be useful if/when others run into interoperability > > problems against a Linux NFS server. > > > > Thanks, rick > > > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to > >> "freebsd-stable-unsubscribe@freebsd.org" > Server: Linux Sabayon > (Linux localhost.localdomain 3.8.0-sabayon #1 SMP Fri Mar 29 13:54:24 > UTC 2013 i686 Genuine Intel(R) CPU T2080 @ 1.73GHz GenuineIntel > GNU/Linux) > Package: net-fs/nfs-utils-1.2.7 > > /etc/exports > /home/bsd/src > 192.168.56.1/24(rw,async,no_subtree_check,root_squash,anonuid=1000,anongid=1001,fsid=1000) > > Client: Freebsd 9-STABLE > (FreeBSD ion.uabsd.org 9.1-STABLE FreeBSD 9.1-STABLE #0 r250121: Wed > May 1 23:38:36 EEST 2013 > root@ion.uabsd.org:/usr/obj/usr/src/sys/GENERIC i386) > > mount command: > mount -t nfs -o ro,nfsv3,tcp 192.168.56.1:/home/bsd/src /usr/src > > Fix: add option fsid=(1000 or any number) to /etc/exports . I don't > understand, Why fsid is so important? Sounds like a question for the Linux NFS mailing list. All I can mention is that most NFS servers use an fsid to uniquely identify a file system on the server. It is often a part of the file handle. Anyhow, thanks for letting us know. If someone reports a similar problem, we can suggest trying adding fsid= to their Linux server's export line. Thanks, rick > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue May 7 06:30:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C0A8AF17 for ; Tue, 7 May 2013 06:30:11 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (mail.ismobile.com [IPv6:2a00:f680:101:11::4]) by mx1.freebsd.org (Postfix) with ESMTP id 7C5CD1CB for ; Tue, 7 May 2013 06:30:11 +0000 (UTC) Received: from mail.ismobile.com (localhost [127.0.0.1]) by dkim.mail.ismobile.com (Postfix) with ESMTP id DBC392B5491 for ; Tue, 7 May 2013 06:30:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ismobile.com; h=date:from :to:subject:message-id:mime-version:content-type :content-transfer-encoding; s=selector1; bh=wqoknhvqjJd6DXpTSuPF GwhznU4=; b=RtKy8HiVNH6Hdol/F/DytMBc7EWDJRt/Smhztjp11UED0icsgQtI k8N4Y3u2v/zNWXWIGn+oQTwAphFWczQiHMcWVYZQWprpapLfySY914VhaBE5DAdk Z2YnsUhD9bG22X2UQ6I37dRJPlnVA7+9DOhaCvjZBnsK/re6UK+i8tA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ismobile.com; h=date:from:to :subject:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=selector1; b=b6Au8QaWDIlVqa Lzq1h5JkPO+IuJxhfoD2fg18B4+Y1drtmpnn1+ZIOSt8H0WYswCXJ69eMAee4rbx nz+8V91PKNdcHE6VAQ9+7+oeVdNtEPwUfh5yVi8L8CUSQixFaLRxnEaXWGmtjKV4 ifmnptAOLmD03ngqDmufvy1zr/65A= Received: from [172.16.2.45] (unknown [172.16.2.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id 796E62B5490 for ; Tue, 7 May 2013 06:30:07 +0000 (UTC) Date: Tue, 07 May 2013 08:30:06 +0200 From: =?UTF-8?Q?G=C3=B6ran_L=C3=B6wkrantz?= To: freebsd-stable@freebsd.org Subject: Nullfs leaks i-nodes Message-ID: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 06:30:11 -0000 I created a PR, kern/178238, on this but would like to know if anyone has any ideas or patches? Have updated the system where I see this to FreeBSD 9.1-STABLE #0 r250229 and still have the problem. /glz From owner-freebsd-stable@FreeBSD.ORG Tue May 7 20:41:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4BEFB80A; Tue, 7 May 2013 20:41:56 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id B01B8DE; Tue, 7 May 2013 20:41:55 +0000 (UTC) Received: by mail-ea0-f174.google.com with SMTP id f15so560466eak.33 for ; Tue, 07 May 2013 13:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=3xiwp2rjIemQfbVaytw0d41LpzbUg2VfgyL11d0C8Ww=; b=g+lE6S+uQQsdWSXDf1JFs5Eh3uwpoSzWXbWbMJTW8GbR4Nz+W8uZTPXNIQVy954+5x RKlKe0uRJlDvoSVkOvmm+rXKUlyBt6goK/6PB1qAHXjWOMdjldxcwTKYlCcDuvCaUe4G Ju1voc722lZPV0Elm4GQRwDl3llvIiWRu+mVljl+KIR/EFmWmuIyXMRyk+7UTYYqBo7l RZix3D3cbhG0rBjJMOz5pyFYl0ZlaOkKohZrnsxit2ov+CydWQ9aVvuawDrjo/EoYfP9 9rI7TTmxgYKJ4GyfApF38BQQE1dReJsq4QX6la29B+hK5SwjHi58scpqbIuM3AsHeq4U WvEA== X-Received: by 10.14.202.201 with SMTP id d49mr9294005eeo.1.1367959314775; Tue, 07 May 2013 13:41:54 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPSA id w43sm35070452eeg.14.2013.05.07.13.41.52 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 07 May 2013 13:41:53 -0700 (PDT) Sender: Mikolaj Golub Date: Tue, 7 May 2013 23:41:51 +0300 From: Mikolaj Golub To: =?utf-8?B?R8O2cmFuIEzDtndrcmFudHo=?= Subject: Re: Nullfs leaks i-nodes Message-ID: <20130507204149.GA3267@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kostik Belousov , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 20:41:56 -0000 On Tue, May 07, 2013 at 08:30:06AM +0200, Göran Löwkrantz wrote: > I created a PR, kern/178238, on this but would like to know if anyone has > any ideas or patches? > > Have updated the system where I see this to FreeBSD 9.1-STABLE #0 r250229 > and still have the problem. I am observing an effect that might look like inode leak, which I think is due free nullfs vnodes caching, recently added by kib (r240285): free inode number does not increase after unlink; but if I purge the free vnodes cache (temporary setting vfs.wantfreevnodes to 0 and observing vfs.freevnodes decreasing to 0) the inode number grows back. You have only about 1000 inodes available on your underlying fs, while vfs.wantfreevnodes I think is much higher, resulting in running out of i-nodes. If it is really your case you can disable caching, mounting nullfs with nocache (it looks like caching is not important in your case). -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Tue May 7 22:36:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4CE9EE5A; Tue, 7 May 2013 22:36:50 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nschwmtas03p.mx.bigpond.com (nschwmtas03p.mx.bigpond.com [61.9.189.143]) by mx1.freebsd.org (Postfix) with ESMTP id 8B9DB74B; Tue, 7 May 2013 22:36:49 +0000 (UTC) Received: from nschwcmgw05p ([61.9.190.165]) by nschwmtas03p.mx.bigpond.com with ESMTP id <20130507223641.IOP2008.nschwmtas03p.mx.bigpond.com@nschwcmgw05p>; Tue, 7 May 2013 22:36:41 +0000 Received: from hermes.heuristicsystems.com.au ([58.172.113.247]) by nschwcmgw05p with BigPond Outbound id ZAcg1l00R5LKYmq01AcgPw; Tue, 07 May 2013 22:36:41 +0000 X-Authority-Analysis: v=2.0 cv=QJDqt33L c=1 sm=1 a=YibVxx38Z+cwdCKSMcELyg==:17 a=k4yzAXmc-yEA:10 a=8nJEP1OIZ-IA:10 a=GHIR_BbyAAAA:8 a=RmBvt3o0NWIA:10 a=6I5d2MoRAAAA:8 a=J8tqD64_rZ3NdKCdztYA:9 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=uhHikAKd3b9-GwYN:21 a=3gnV2ZkxXiNlYijp:21 a=YibVxx38Z+cwdCKSMcELyg==:117 Received: from black (black.hs [10.0.5.1]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id r47MZSg0091180 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 May 2013 08:35:29 +1000 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne Geraghty" To: "'Mikolaj Golub'" , "=?iso-8859-1?Q?'G=F6ran_L=F6wkrantz'?=" References: <20130507204149.GA3267@gmail.com> Subject: RE: Nullfs leaks i-nodes Date: Wed, 8 May 2013 08:35:18 +1000 Message-ID: <56EF269F84824D8DB413D289BB8CBE19@as.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20130507204149.GA3267@gmail.com> Thread-Index: Ac5LY1ryw14pMFB/RPi2FDMaUDaRngAC9cCw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable@freebsd.org, 'Kostik Belousov' X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 22:36:50 -0000 > -----Original Message----- > From: owner-freebsd-stable@freebsd.org=20 > [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Mikolaj Golub > Sent: Wednesday, 8 May 2013 6:42 AM > To: G=F6ran L=F6wkrantz > Cc: Kostik Belousov; freebsd-stable@freebsd.org > Subject: Re: Nullfs leaks i-nodes >=20 > On Tue, May 07, 2013 at 08:30:06AM +0200, G=F6ran L=F6wkrantz wrote: > > I created a PR, kern/178238, on this but would like to know=20 > if anyone has=20 > > any ideas or patches? > >=20 > > Have updated the system where I see this to FreeBSD=20 > 9.1-STABLE #0 r250229=20 > > and still have the problem. >=20 > I am observing an effect that might look like inode leak, which I > think is due free nullfs vnodes caching, recently added by kib > (r240285): free inode number does not increase after unlink; but if I > purge the free vnodes cache (temporary setting vfs.wantfreevnodes to 0 > and observing vfs.freevnodes decreasing to 0) the inode number grows > back. >=20 > You have only about 1000 inodes available on your underlying fs, while > vfs.wantfreevnodes I think is much higher, resulting in running out of > i-nodes. >=20 > If it is really your case you can disable caching, mounting nullfs > with nocache (it looks like caching is not important in your case). >=20 > --=20 > Mikolaj Golub > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to=20 > "freebsd-stable-unsubscribe@freebsd.org" >=20 Hi Goran, After I included Kib's vnode caching patch the performance on my "port = builder" machine, decreased significantly. The "port builder" is one of many jails and nullfs is used extensively. I was = starving the system of vnodes. Increasing the kern.maxvnodes, resulted in better performance than the original system configuration = without vnode caching. Thanks Kib :) I don't think you'll run out of vnodes as it is self adjusting (that was = my concern too) I changed kern.maxvnode to approx 3 times what it wanted and tuned for = my needs. Try it and keep an eye on: sysctl vfs.numvnodes vfs.wantfreevnodes vfs.freevnodes = vm.stats.vm.v_vnodepgsout vm.stats.vm.v_vnodepgsin Regards, Dewayne From owner-freebsd-stable@FreeBSD.ORG Tue May 7 23:16:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D75CB7E4 for ; Tue, 7 May 2013 23:16:36 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:56]) by mx1.freebsd.org (Postfix) with ESMTP id BBAD485D for ; Tue, 7 May 2013 23:16:36 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta06.emeryville.ca.mail.comcast.net with comcast id ZAuZ1l0051smiN4A6BGcju; Tue, 07 May 2013 23:16:36 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta20.emeryville.ca.mail.comcast.net with comcast id ZBEa1l00b1t3BNj8gBEbJV; Tue, 07 May 2013 23:14:35 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A772F73A33; Tue, 7 May 2013 16:14:34 -0700 (PDT) Date: Tue, 7 May 2013 16:14:34 -0700 From: Jeremy Chadwick To: Dewayne Geraghty Subject: Re: Nullfs leaks i-nodes Message-ID: <20130507231434.GA47954@icarus.home.lan> References: <20130507204149.GA3267@gmail.com> <56EF269F84824D8DB413D289BB8CBE19@as.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56EF269F84824D8DB413D289BB8CBE19@as.lan> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367968596; bh=WV+2rjtcH02LrSZPGEhZmkm9EfsDGqIkEAcXTu+oOnQ=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=JX6XDxYNGV8pSG3N23TKeHdVvyTEvM/bBR1F9UlJzDTgcL8XlM/Yiw9HbfH2BDhiW JfwD/ma3jHazGQJIKsPxUCRPuMSRGPGxXOW/7kKhXCkpHT7jH5pGUeDbFGjyejrzSh JWKoxxgIPmA57Ys6oE15ReH1IsIeI2Ry2ia76FdVE2escxliXJK91SDjbJHhw1bTxG cKcLq/qAPBaciQfy9hA8B5x60xFh6QhOekEMaLnIBQ5Eba+turWQNliAnegoVR8V+f n/9nEDwObWrPLUOFMMTl+nnq2C2s3V6SZUk3HzpqPkhZrbUcbolB5eSLwMmaHeOpGt 0UP3W1p0VdPRg== Cc: 'Mikolaj Golub' , freebsd-stable@freebsd.org, 'Kostik Belousov' X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 23:16:36 -0000 On Wed, May 08, 2013 at 08:35:18AM +1000, Dewayne Geraghty wrote: > > -----Original Message----- > > From: owner-freebsd-stable@freebsd.org > > [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Mikolaj Golub > > Sent: Wednesday, 8 May 2013 6:42 AM > > To: Göran Löwkrantz > > Cc: Kostik Belousov; freebsd-stable@freebsd.org > > Subject: Re: Nullfs leaks i-nodes > > > > On Tue, May 07, 2013 at 08:30:06AM +0200, Göran Löwkrantz wrote: > > > I created a PR, kern/178238, on this but would like to know > > if anyone has > > > any ideas or patches? > > > > > > Have updated the system where I see this to FreeBSD > > 9.1-STABLE #0 r250229 > > > and still have the problem. > > > > I am observing an effect that might look like inode leak, which I > > think is due free nullfs vnodes caching, recently added by kib > > (r240285): free inode number does not increase after unlink; but if I > > purge the free vnodes cache (temporary setting vfs.wantfreevnodes to 0 > > and observing vfs.freevnodes decreasing to 0) the inode number grows > > back. > > > > You have only about 1000 inodes available on your underlying fs, while > > vfs.wantfreevnodes I think is much higher, resulting in running out of > > i-nodes. > > > > If it is really your case you can disable caching, mounting nullfs > > with nocache (it looks like caching is not important in your case). > > > > -- > > Mikolaj Golub > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to > > "freebsd-stable-unsubscribe@freebsd.org" > > > > Hi Goran, > > After I included Kib's vnode caching patch the performance on my "port builder" machine, decreased significantly. The "port > builder" is one of many jails and nullfs is used extensively. I was starving the system of vnodes. Increasing the kern.maxvnodes, > resulted in better performance than the original system configuration without vnode caching. Thanks Kib :) > > I don't think you'll run out of vnodes as it is self adjusting (that was my concern too) > > I changed kern.maxvnode to approx 3 times what it wanted and tuned for my needs. > Try it and keep an eye on: > sysctl vfs.numvnodes vfs.wantfreevnodes vfs.freevnodes vm.stats.vm.v_vnodepgsout vm.stats.vm.v_vnodepgsin Telling people "keep an eye on these sysctls" is not exactly helpful when there isn't an understanding of what they represent -- it's akin to people using munin or SNMP polling software to "monitoring some MIBs" without actually knowing, truly, deep down inside, what it is they're looking at. (I cannot tell you how often this happens. In fact, most "systems monitoring" softwares/graphs/other crap I see these days tends to suffer from exactly this) The only thing I'm aware of is what's in vnode(9) and what I could find here: http://www.youtube.com/watch?v=SpS7Ajnx9Q8 http://bsd-id.blogspot.com/2007/11/vnode.html All said -- has anyone actually seen vfs.freevnodes hit 0? On some of my systems I've seen it reach "small numbers" (in the 3-digit range), but would later increase (to mid-4-digit range), even after lots of (new/unique, i.e. not previously cached) file I/O. So the "auto-adjusting" nature of this makes it very hard for one to say "keep an eye on these sysctls" when the administrator does not know when he/she should become concerned/considering increasing kern.maxvnodes. Next, maxvnodes - numvnodes != freevnodes, which doesn't make sense to me: $ sysctl kern.maxvnodes vfs.freevnodes vfs.wantfreevnodes vfs.numvnodes kern.maxvnodes: 393216 vfs.freevnodes: 51543 vfs.wantfreevnodes: 51545 vfs.numvnodes: 244625 $ expr 393216 - 244625 148591 And finally, the lack of sysctl description for vfs.wantfreevnodes is quite bothersome: $ sysctl -d kern.maxvnodes vfs.freevnodes vfs.wantfreevnodes vfs.numvnodes kern.maxvnodes: Maximum number of vnodes vfs.freevnodes: Number of vnodes in the free list vfs.wantfreevnodes: vfs.numvnodes: Number of vnodes in existence -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue May 7 23:50:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 079AAC52 for ; Tue, 7 May 2013 23:50:48 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nskntmtas04p.mx.bigpond.com (nskntmtas04p.mx.bigpond.com [61.9.168.146]) by mx1.freebsd.org (Postfix) with ESMTP id 9C6E7951 for ; Tue, 7 May 2013 23:50:47 +0000 (UTC) Received: from nskntcmgw08p ([61.9.169.168]) by nskntmtas04p.mx.bigpond.com with ESMTP id <20130507235046.HYZB2025.nskntmtas04p.mx.bigpond.com@nskntcmgw08p>; Tue, 7 May 2013 23:50:46 +0000 Received: from hermes.heuristicsystems.com.au ([58.172.113.247]) by nskntcmgw08p with BigPond Outbound id ZBql1l00P5LKYmq01Bql1a; Tue, 07 May 2013 23:50:46 +0000 X-Authority-Analysis: v=2.0 cv=FNuZNpUs c=1 sm=1 a=YibVxx38Z+cwdCKSMcELyg==:17 a=k4yzAXmc-yEA:10 a=kj9zAlcOel0A:10 a=GHIR_BbyAAAA:8 a=RmBvt3o0NWIA:10 a=zvi4VfkwKpCHMTezYlwA:9 a=CjuIK1q_8ugA:10 a=YibVxx38Z+cwdCKSMcELyg==:117 Received: from black (black.hs [10.0.5.1]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id r47Nmw1g093472 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 May 2013 09:48:59 +1000 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne Geraghty" To: "'Jeremy Chadwick'" References: <20130507204149.GA3267@gmail.com> <56EF269F84824D8DB413D289BB8CBE19@as.lan> <20130507231434.GA47954@icarus.home.lan> Subject: RE: Nullfs leaks i-nodes Date: Wed, 8 May 2013 09:48:58 +1000 Message-ID: <104348555EC042FC857467FACDD5E249@as.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20130507231434.GA47954@icarus.home.lan> Thread-Index: Ac5LePWpXCu83x1xQv+IHSXtLPI4jQAAyKeQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 23:50:48 -0000 Jeremy, Thank-you for your advice. I take your point that the next time that I have an idea that might help, that is, suggesting that maxvnodes should be increased and that vnode depletion vs starvation shouldn't be a concern; I'll reflect on your reply for my failure to review the vnode source and to fully understand the ramifications of examing the sysctl's. Regards, Dewayne. From owner-freebsd-stable@FreeBSD.ORG Wed May 8 07:17:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4EDA6273; Wed, 8 May 2013 07:17:19 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (mail.ismobile.com [IPv6:2a00:f680:101:11::4]) by mx1.freebsd.org (Postfix) with ESMTP id 0573EA5A; Wed, 8 May 2013 07:17:19 +0000 (UTC) Received: from mail.ismobile.com (localhost [127.0.0.1]) by dkim.mail.ismobile.com (Postfix) with ESMTP id B8D352B5578; Wed, 8 May 2013 07:17:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ismobile.com; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=selector1; bh=CaMk/5G al0wrRnaiP2j+7NWp5bQ=; b=GtGjrT8kG1R65NPL/HvcKV6BnOwg9HyAyNcefRW glYsrGUZQbvRfqgmRILGp1wS08o/bM6kRitNU2OulTfHFATv2W9BUHXfT1hjd3fU GdO2MYkisyTivOV5EEJ8DZC7+X57yNV4vKciPnMZdVkjQPuk1WZFVEzJPBrZndhR 1wow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ismobile.com; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=selector1; b=o 6hDO67lbvo5ODmDdv8LG5XMznSljxS/h6U+mKlfHxHPZDmy5k77gxQc17blX6/o+ Hl9p/LSB0BqyYE6rATJG2I0FOBbLP7yhuhLv+rJAaySG6sgnCaFTSTzE8xIN5GSp s6V3P3U9YIAopoM+nAMh/sdsrP8qYdU35diKagnQjw= Received: from [172.16.2.45] (glz-macbookpro.hq.ismobile.com [172.16.2.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id E95BE2B548E; Wed, 8 May 2013 07:17:14 +0000 (UTC) Date: Wed, 08 May 2013 09:17:13 +0200 From: =?UTF-8?Q?G=C3=B6ran_L=C3=B6wkrantz?= To: Mikolaj Golub Subject: Re: Nullfs leaks i-nodes Message-ID: In-Reply-To: <20130507204149.GA3267@gmail.com> References: <20130507204149.GA3267@gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Kostik Belousov , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 07:17:19 -0000 --On May 7, 2013 23:41:51 +0300 Mikolaj Golub wrote: > On Tue, May 07, 2013 at 08:30:06AM +0200, G=C3=B6ran L=C3=B6wkrantz = wrote: >> I created a PR, kern/178238, on this but would like to know if anyone >> has any ideas or patches? >> >> Have updated the system where I see this to FreeBSD 9.1-STABLE #0 >> r250229 and still have the problem. > > I am observing an effect that might look like inode leak, which I > think is due free nullfs vnodes caching, recently added by kib > (r240285): free inode number does not increase after unlink; but if I > purge the free vnodes cache (temporary setting vfs.wantfreevnodes to 0 > and observing vfs.freevnodes decreasing to 0) the inode number grows > back. > > You have only about 1000 inodes available on your underlying fs, while > vfs.wantfreevnodes I think is much higher, resulting in running out of > i-nodes. > > If it is really your case you can disable caching, mounting nullfs > with nocache (it looks like caching is not important in your case). > > -- > Mikolaj Golub Thanks Mikolaj, mounting the active fs with 'nocache' fixed it, keeping=20 ifree steady. Any idea how to "fix" this in NanoBSD? The data partition is created with=20 only 1024 i-nodes in the script, so any use that includes file deletion on=20 this r/w area will be bitten. As the nocache attribute is not valid for device mounts, I see no way to=20 inherit it to the nullfs mounts for this specific partition. Easiest thing could be to set vfs.wantfreevnodes=3D0 in the default=20 sysctl.conf, maybe? But will this have implications for non-nullfs=20 filesystems? Only UFS? Even ZFS? Thanks again, G=C3=B6ran From owner-freebsd-stable@FreeBSD.ORG Wed May 8 07:31:07 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8B53C5FA; Wed, 8 May 2013 07:31:07 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (mail.ismobile.com [IPv6:2a00:f680:101:11::4]) by mx1.freebsd.org (Postfix) with ESMTP id 0C37CAEB; Wed, 8 May 2013 07:31:07 +0000 (UTC) Received: from mail.ismobile.com (localhost [127.0.0.1]) by dkim.mail.ismobile.com (Postfix) with ESMTP id D8E142B5578; Wed, 8 May 2013 07:30:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ismobile.com; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=selector1; bh=0a4+mqw Bld+MWKhNky6TKgbKK/Q=; b=dsuk3hV5slkAjbah7mS6TsadcknyEcWY2j3zUOz jr4l0FazSMmTuS2P7W5xBOZePVDtdkoYy0otXgm5//hBqH1OCEhL78fPBIkj3No9 o4p8EDYxQbIgt7IuSlBcQCaxv4n8n6M3kw6TrD6R0arO7EAhKVTCaVlEjHF2f9Zc qwRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ismobile.com; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=selector1; b=K 4r9iY6VSbizRvmtrVdFSQ5Bez1WsWOAxivzFgnEt2v2AWEl9jWE/PZ9cnfxcWKWu 0SJ4r/yURzOE0Q+z/uryV6rLrTQSvQ5rXJC6umzwpuVfr+EIfhTw3li8VmiIiWn0 OgYC5603bIMS7dg0hYwunTzI1TqKesu0+UevOaHhhI= Received: from [172.16.2.45] (glz-macbookpro.hq.ismobile.com [172.16.2.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id 739082B5573; Wed, 8 May 2013 07:30:58 +0000 (UTC) Date: Wed, 08 May 2013 09:30:57 +0200 From: =?UTF-8?Q?G=C3=B6ran_L=C3=B6wkrantz?= To: Dewayne Geraghty , 'Mikolaj Golub' Subject: RE: Nullfs leaks i-nodes Message-ID: <2FBC9C8F12387387C1AEF445@[172.16.2.45]> In-Reply-To: <56EF269F84824D8DB413D289BB8CBE19@as.lan> References: <20130507204149.GA3267@gmail.com> <56EF269F84824D8DB413D289BB8CBE19@as.lan> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: freebsd-stable@freebsd.org, 'Kostik Belousov' X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 07:31:07 -0000 --On May 8, 2013 8:35:18 +1000 Dewayne Geraghty=20 wrote: >> -----Original Message----- >> From: owner-freebsd-stable@freebsd.org >> [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Mikolaj Golub >> Sent: Wednesday, 8 May 2013 6:42 AM >> To: G=C3=B6ran L=C3=B6wkrantz >> Cc: Kostik Belousov; freebsd-stable@freebsd.org >> Subject: Re: Nullfs leaks i-nodes >> >> On Tue, May 07, 2013 at 08:30:06AM +0200, G=C3=B6ran L=C3=B6wkrantz = wrote: >> > I created a PR, kern/178238, on this but would like to know >> if anyone has >> > any ideas or patches? >> > >> > Have updated the system where I see this to FreeBSD >> 9.1-STABLE #0 r250229 >> > and still have the problem. >> >> I am observing an effect that might look like inode leak, which I >> think is due free nullfs vnodes caching, recently added by kib >> (r240285): free inode number does not increase after unlink; but if I >> purge the free vnodes cache (temporary setting vfs.wantfreevnodes to 0 >> and observing vfs.freevnodes decreasing to 0) the inode number grows >> back. >> >> You have only about 1000 inodes available on your underlying fs, while >> vfs.wantfreevnodes I think is much higher, resulting in running out of >> i-nodes. >> >> If it is really your case you can disable caching, mounting nullfs >> with nocache (it looks like caching is not important in your case). >> >> -- >> Mikolaj Golub >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" >> > > Hi Goran, > > After I included Kib's vnode caching patch the performance on my "port > builder" machine, decreased significantly. The "port builder" is one of > many jails and nullfs is used extensively. I was starving the system of > vnodes. Increasing the kern.maxvnodes, resulted in better performance > than the original system configuration without vnode caching. Thanks Kib > :) > > I don't think you'll run out of vnodes as it is self adjusting (that was > my concern too) > > I changed kern.maxvnode to approx 3 times what it wanted and tuned for my > needs. Try it and keep an eye on: > sysctl vfs.numvnodes vfs.wantfreevnodes vfs.freevnodes > vm.stats.vm.v_vnodepgsout vm.stats.vm.v_vnodepgsin > > Regards, Dewayne > Hi Dewayne, I got a few of those too but I didn't connect them with the FW problem as=20 here there seems to be reclaim pressure. On the FW I get these numbers: vfs.numvnodes: 7500 vfs.wantfreevnodes: 27936 vfs.freevnodes: 5663 vm.stats.vm.v_vnodepgsout: 0 vm.stats.vm.v_vnodepgsin: 4399 while on the jail systems I get something like this: vfs.numvnodes: 51212 vfs.wantfreevnodes: 35668 vfs.freevnodes: 35665 vm.stats.vm.v_vnodepgsout: 5952 vm.stats.vm.v_vnodepgsin: 939563 and as far as I can understand, the fact that vfs.wantfreevnodes and=20 vfs.freevnodes are almost the same suggests that we have a reclaim = pressure. So one fix for small NanoBSD systems would be to lower vfs.wantfreevnodes=20 and I will test that on a virtual machine and see if I can get better=20 reclaim. MVH G=C3=B6ran From owner-freebsd-stable@FreeBSD.ORG Wed May 8 09:13:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 85665B9A; Wed, 8 May 2013 09:13:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D5D82FD0; Wed, 8 May 2013 09:13:27 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r489DHs7022210; Wed, 8 May 2013 12:13:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r489DHs7022210 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r489DHoY022209; Wed, 8 May 2013 12:13:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 8 May 2013 12:13:17 +0300 From: Konstantin Belousov To: G??ran L??wkrantz Subject: Re: Nullfs leaks i-nodes Message-ID: <20130508091317.GJ3047@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wICysDeFgFMelglS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: pho@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 09:13:28 -0000 --wICysDeFgFMelglS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 07, 2013 at 08:30:06AM +0200, G??ran L??wkrantz wrote: > I created a PR, kern/178238, on this but would like to know if anyone has= =20 > any ideas or patches? >=20 > Have updated the system where I see this to FreeBSD 9.1-STABLE #0 r250229= =20 > and still have the problem. The patch below should fix the issue for you, at least it did so in my limited testing. What is does: 1. When inactivating a nullfs vnode, check if the lower vnode is unlinked, and reclaim upper vnode if so. [This fixes your case]. 2. Besides a callback to the upper filesystems for the lower vnode reclaimation, it also calls the upper fs for lower vnode unlink. This allows nullfs to purge cached vnodes for the unlinked lower. [This fixes an opposite case, when the vnode is removed from the lower mount, but upper aliases prevent the vnode from being recycled]. 3. Fix a wart which existed from the introduction of the nullfs caching, do not unlock lower vnode in the nullfs_reclaim_lowervp(). It should be completely innocent, but now it is also formally safe. 4. Fix vnode reference leak in nullfs_reclaim_lowervp(). Please note that the patch is basically not tested, I only verified your scenario and a mirror of it as described in item 2. diff --git a/sys/fs/nullfs/null.h b/sys/fs/nullfs/null.h index 4f37020..a624be6 100644 --- a/sys/fs/nullfs/null.h +++ b/sys/fs/nullfs/null.h @@ -53,8 +53,11 @@ struct null_node { LIST_ENTRY(null_node) null_hash; /* Hash list */ struct vnode *null_lowervp; /* VREFed once */ struct vnode *null_vnode; /* Back pointer */ + u_int null_flags; }; =20 +#define NULLV_NOUNLOCK 0x0001 + #define MOUNTTONULLMOUNT(mp) ((struct null_mount *)((mp)->mnt_data)) #define VTONULL(vp) ((struct null_node *)(vp)->v_data) #define NULLTOV(xp) ((xp)->null_vnode) diff --git a/sys/fs/nullfs/null_vfsops.c b/sys/fs/nullfs/null_vfsops.c index 02932bd..544c358 100644 --- a/sys/fs/nullfs/null_vfsops.c +++ b/sys/fs/nullfs/null_vfsops.c @@ -65,7 +65,6 @@ static vfs_statfs_t nullfs_statfs; static vfs_unmount_t nullfs_unmount; static vfs_vget_t nullfs_vget; static vfs_extattrctl_t nullfs_extattrctl; -static vfs_reclaim_lowervp_t nullfs_reclaim_lowervp; =20 /* * Mount null layer @@ -391,8 +390,22 @@ nullfs_reclaim_lowervp(struct mount *mp, struct vnode = *lowervp) vp =3D null_hashget(mp, lowervp); if (vp =3D=3D NULL) return; + VTONULL(vp)->null_flags |=3D NULLV_NOUNLOCK; vgone(vp); - vn_lock(lowervp, LK_EXCLUSIVE | LK_RETRY); + vput(vp); +} + +static void +nullfs_unlink_lowervp(struct mount *mp, struct vnode *lowervp) +{ + struct vnode *vp; + + vp =3D null_hashget(mp, lowervp); + if (vp =3D=3D NULL || vp->v_usecount > 1) + return; + VTONULL(vp)->null_flags |=3D NULLV_NOUNLOCK; + vgone(vp); + vput(vp); } =20 static struct vfsops null_vfsops =3D { @@ -408,6 +421,7 @@ static struct vfsops null_vfsops =3D { .vfs_unmount =3D nullfs_unmount, .vfs_vget =3D nullfs_vget, .vfs_reclaim_lowervp =3D nullfs_reclaim_lowervp, + .vfs_unlink_lowervp =3D nullfs_unlink_lowervp, }; =20 VFS_SET(null_vfsops, nullfs, VFCF_LOOPBACK | VFCF_JAIL); diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c index f59865f..3c41124 100644 --- a/sys/fs/nullfs/null_vnops.c +++ b/sys/fs/nullfs/null_vnops.c @@ -692,18 +692,21 @@ null_unlock(struct vop_unlock_args *ap) static int null_inactive(struct vop_inactive_args *ap __unused) { - struct vnode *vp; + struct vnode *vp, *lvp; struct mount *mp; struct null_mount *xmp; =20 vp =3D ap->a_vp; + lvp =3D NULLVPTOLOWERVP(vp); mp =3D vp->v_mount; xmp =3D MOUNTTONULLMOUNT(mp); - if ((xmp->nullm_flags & NULLM_CACHE) =3D=3D 0) { + if ((xmp->nullm_flags & NULLM_CACHE) =3D=3D 0 || + (lvp->v_vflag & VV_NOSYNC) !=3D 0) { /* * If this is the last reference and caching of the - * nullfs vnodes is not enabled, then free up the - * vnode so as not to tie up the lower vnodes. + * nullfs vnodes is not enabled, or the lower vnode is + * deleted, then free up the vnode so as not to tie up + * the lower vnodes. */ vp->v_object =3D NULL; vrecycle(vp); @@ -748,7 +751,10 @@ null_reclaim(struct vop_reclaim_args *ap) */ if (vp->v_writecount > 0) VOP_ADD_WRITECOUNT(lowervp, -1); - vput(lowervp); + if ((xp->null_flags & NULLV_NOUNLOCK) !=3D 0) + vunref(lowervp); + else + vput(lowervp); free(xp, M_NULLFSNODE); =20 return (0); diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index de118f7..988a114 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -2700,19 +2700,20 @@ vgone(struct vnode *vp) } =20 static void -vgonel_reclaim_lowervp_vfs(struct mount *mp __unused, +notify_lowervp_vfs_dummy(struct mount *mp __unused, struct vnode *lowervp __unused) { } =20 /* - * Notify upper mounts about reclaimed vnode. + * Notify upper mounts about reclaimed or unlinked vnode. */ -static void -vgonel_reclaim_lowervp(struct vnode *vp) +void +vfs_notify_upper(struct vnode *vp, int event) { static struct vfsops vgonel_vfsops =3D { - .vfs_reclaim_lowervp =3D vgonel_reclaim_lowervp_vfs + .vfs_reclaim_lowervp =3D notify_lowervp_vfs_dummy, + .vfs_unlink_lowervp =3D notify_lowervp_vfs_dummy, }; struct mount *mp, *ump, *mmp; =20 @@ -2736,7 +2737,17 @@ vgonel_reclaim_lowervp(struct vnode *vp) } TAILQ_INSERT_AFTER(&mp->mnt_uppers, ump, mmp, mnt_upper_link); MNT_IUNLOCK(mp); - VFS_RECLAIM_LOWERVP(ump, vp); + switch (event) { + case VFS_NOTIFY_UPPER_RECLAIM: + VFS_RECLAIM_LOWERVP(ump, vp); + break; + case VFS_NOTIFY_UPPER_UNLINK: + VFS_UNLINK_LOWERVP(ump, vp); + break; + default: + KASSERT(0, ("invalid event %d", event)); + break; + } MNT_ILOCK(mp); ump =3D TAILQ_NEXT(mmp, mnt_upper_link); TAILQ_REMOVE(&mp->mnt_uppers, mmp, mnt_upper_link); @@ -2783,7 +2794,7 @@ vgonel(struct vnode *vp) active =3D vp->v_usecount; oweinact =3D (vp->v_iflag & VI_OWEINACT); VI_UNLOCK(vp); - vgonel_reclaim_lowervp(vp); + vfs_notify_upper(vp, VFS_NOTIFY_UPPER_RECLAIM); =20 /* * Clean out any buffers associated with the vnode. diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c index 29cb7bd..a004ea0 100644 --- a/sys/kern/vfs_syscalls.c +++ b/sys/kern/vfs_syscalls.c @@ -1846,6 +1846,7 @@ restart: if (error) goto out; #endif + vfs_notify_upper(vp, VFS_NOTIFY_UPPER_UNLINK); error =3D VOP_REMOVE(nd.ni_dvp, vp, &nd.ni_cnd); #ifdef MAC out: @@ -3825,6 +3826,7 @@ restart: return (error); goto restart; } + vfs_notify_upper(vp, VFS_NOTIFY_UPPER_UNLINK); error =3D VOP_RMDIR(nd.ni_dvp, nd.ni_vp, &nd.ni_cnd); vn_finished_write(mp); out: diff --git a/sys/sys/mount.h b/sys/sys/mount.h index a9c86f6..a953dae 100644 --- a/sys/sys/mount.h +++ b/sys/sys/mount.h @@ -608,7 +608,7 @@ typedef int vfs_mount_t(struct mount *mp); typedef int vfs_sysctl_t(struct mount *mp, fsctlop_t op, struct sysctl_req *req); typedef void vfs_susp_clean_t(struct mount *mp); -typedef void vfs_reclaim_lowervp_t(struct mount *mp, struct vnode *lowervp= ); +typedef void vfs_notify_lowervp_t(struct mount *mp, struct vnode *lowervp); =20 struct vfsops { vfs_mount_t *vfs_mount; @@ -626,7 +626,8 @@ struct vfsops { vfs_extattrctl_t *vfs_extattrctl; vfs_sysctl_t *vfs_sysctl; vfs_susp_clean_t *vfs_susp_clean; - vfs_reclaim_lowervp_t *vfs_reclaim_lowervp; + vfs_notify_lowervp_t *vfs_reclaim_lowervp; + vfs_notify_lowervp_t *vfs_unlink_lowervp; }; =20 vfs_statfs_t __vfs_statfs; @@ -747,6 +748,14 @@ vfs_statfs_t __vfs_statfs; } \ } while (0) =20 +#define VFS_UNLINK_LOWERVP(MP, VP) do { \ + if (*(MP)->mnt_op->vfs_unlink_lowervp !=3D NULL) { \ + VFS_PROLOGUE(MP); \ + (*(MP)->mnt_op->vfs_unlink_lowervp)((MP), (VP)); \ + VFS_EPILOGUE(MP); \ + } \ +} while (0) + #define VFS_KNOTE_LOCKED(vp, hint) do \ { \ if (((vp)->v_vflag & VV_NOKNOTE) =3D=3D 0) \ @@ -759,6 +768,9 @@ vfs_statfs_t __vfs_statfs; VN_KNOTE((vp), (hint), 0); \ } while (0) =20 +#define VFS_NOTIFY_UPPER_RECLAIM 1 +#define VFS_NOTIFY_UPPER_UNLINK 2 + #include =20 /* @@ -840,6 +852,7 @@ int vfs_modevent(module_t, int, void *); void vfs_mount_error(struct mount *, const char *, ...); void vfs_mountroot(void); /* mount our root filesystem */ void vfs_mountedfrom(struct mount *, const char *from); +void vfs_notify_upper(struct vnode *, int); void vfs_oexport_conv(const struct oexport_args *oexp, struct export_args *exp); void vfs_ref(struct mount *); --wICysDeFgFMelglS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRihcsAAoJEJDCuSvBvK1BTKAP/3X9R+Z3LWS3qarpGobad/oJ Ro4NJaOX+T8Bq84dJKC4vUfaMT0tU10v5erO/7991qWzb7XBoBOzph7WGbdy5LmR IBr88bqyjMUeX+PZXlRNP57GRtjNGPRa6vLnlYmtevX/jP6gN+Laa+ck+xZN9pQJ CijODfARyvt0eWLhqPYbEhbYkgAmmjV1g3qotFN6BCrwUemddJ+nvVlq1fYPvHUE 9r+d8nNbWyTZOuIoNuS5icGesNxNvMJUQi5HgBJLFCvsoJz8GjPPNXTv4xaAG+X2 k3xaqQy/q6SeAHtbqOdZLbSWFPHTd+3PGOh6I/28kutVXU6IxdJI0Nz6qt/ezks8 smidVcggmuyqKl3u1vdntgfijaW2JR0EKMs2QR/Hvvk+28DPK3YyA+VrXrBcCbjY eD6OIDQAVKX1NVjqEline6lObqOExIT4Nkjh+jhcYBxDHBe65pgPf1px6fs5Aw86 ITMVlJbCQp+IeUiS2zcdzTvLuNoYkGQ2+hV7iMf3ZSt5NM94K2awWhYiHRXL44k5 g5f3ObJBT86lGTsAIPNpl/fIJUGbIBs5Q+9VrGvlLKZOk0XLoC+agVMijmQNjZCe Ncjj9/xJsLvxn4hDRylhkQ0zgHrJVIe2rtB6G1ccFid/UhLbrfSsJdn9aRGU6ygL 1v8Gn/5YdSjEYFRe6WjF =/jR1 -----END PGP SIGNATURE----- --wICysDeFgFMelglS-- From owner-freebsd-stable@FreeBSD.ORG Wed May 8 10:52:57 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1C6E46CE for ; Wed, 8 May 2013 10:52:57 +0000 (UTC) (envelope-from markcallahan@jangomail.com) Received: from xl18-g.jsmtp.net (xl18-g.jsmtp.net [173.244.184.196]) by mx1.freebsd.org (Postfix) with ESMTP id C51056DD for ; Wed, 8 May 2013 10:52:56 +0000 (UTC) Message-ID: <184082928276758618471@jngomktg.net> Subject: Access to 2 million CV's From: "Brett - TalentSpa" Date: Wed, 8 May 2013 09:07:25 +0000 To: stable@freebsd.org X-Priority: 3 MIME-Version: 1.0 X-Mailer: N/A X-UserID: 1840829.282767586 X-VConfig: 18471 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Brett - TalentSpa List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 10:52:57 -0000 iProfile launches 'TalentSpa'  - access to over 2 million CV’s   iProfile, Europe’s largest CV exchange of over 7 million candidate has launched TalentSpa, a continuously updating source of more than 2 million CV’s.   Make more placements through our huge source of unique candidatesSignificantly reduce your spend on job board advertisingFind candidates faster with our world leading search technology   Access TalentSpa for only £100 per user per month on a 3 month trial.   To find out more or to book a demo click here. This e-mail was sent by iProfile, located at International House, Castle Hill, Victoria Road, Douglas, Isle of Man IM2 4RB (United Kindom). To receive no further e-mails, please reply to this e-mail with "unlist" in the Subject line. From owner-freebsd-stable@FreeBSD.ORG Wed May 8 17:14:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F3A7C31F for ; Wed, 8 May 2013 17:14:54 +0000 (UTC) (envelope-from jim@ohlste.in) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id B97AF8C for ; Wed, 8 May 2013 17:14:54 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id e1so1148125qcy.36 for ; Wed, 08 May 2013 10:14:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=l7MIXjEK/pLJJv11qfkayaI7nNzvnnYj3Ulnc1dRcRg=; b=aGkMNjx0jIP0d3iPtZd2MB25I0SBjxogdiyBD9P9nE/cRdS1/LsNSFt3+60PKlmTAh 8V555OfL0AXyXd9V3/p+eai/DwD1zKPha5D6oa4Xq/tl+xj6RVOiw1Cpwg3zZzII8u9w do6hKsgpBT6pSnEcyQN2J2wzdn8y0gA2aK4IZrSEly3j4VboyX3kzqCPeTDaj9wmP3Ki Vg7MYuQAmdYkuMGV4HWHvAq4dzDAYLgPFfn/TnS9yZ1mqbZzu/tdZfUJlGkvyjChlykX SML1XljfQonLs52GJvlxh2HLTxN0DPiYBaUJGAynOmrPILIoZSx+/be/2noJl0EQTlkA RuaQ== X-Received: by 10.49.61.226 with SMTP id t2mr6493134qer.40.1368033294225; Wed, 08 May 2013 10:14:54 -0700 (PDT) Received: from [192.168.1.10] (pool-74-110-99-189.nrflva.fios.verizon.net. [74.110.99.189]) by mx.google.com with ESMTPSA id z20sm43108688qeb.4.2013.05.08.10.14.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 10:14:53 -0700 (PDT) Message-ID: <518A880C.3090906@ohlste.in> Date: Wed, 08 May 2013 13:14:52 -0400 From: Jim Ohlstein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Apparent regression in r250359 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQktZEBqvkwEk90Ljmc8MWp1Fx6sLsxNwmdMm2q/8dDU62Usr9ztqi+xe412GkpFCGyEAOQT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 17:14:55 -0000 Hello, I upgraded my (custom) kernel earlier and found that multiple daemons (cups, hal, syslog, ntpd, csh) crashed and dumped cores at or shortly after boot. The error I saw several times on the console was: set_fpcontext err 22 I recompiled using the GENERIC kernel and saw the same error. The error appears to be in the changes made in r250359 in fpu.c, as r250358 boots as expected. # uname -a FreeBSD lucid-insanity 9.1-STABLE FreeBSD 9.1-STABLE #3 r250358: Wed May 8 11:56:43 EDT 2013 root@lucid-insanity:/usr/obj/usr/src/sys/GENERIC amd64 World and kernel are built with clang 3.2. r250359 produces the error and core dumps: Sample gdb output: # gdb cupsd cupsd.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `cupsd'. Program terminated with signal 10, Bus error. Reading symbols from /usr/local/lib/libcupsmime.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcupsmime.so.1 Reading symbols from /lib/libz.so.6...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /usr/lib/libssl.so.6...done. Loaded symbols for /usr/lib/libssl.so.6 Reading symbols from /lib/libcrypto.so.6...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /usr/local/lib/libpaper.so.2...done. Loaded symbols for /usr/local/lib/libpaper.so.2 Reading symbols from /usr/local/lib/libcups.so.2...done. Loaded symbols for /usr/local/lib/libcups.so.2 Reading symbols from /lib/libcrypt.so.5...done. Loaded symbols for /lib/libcrypt.so.5 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x00007ffffffff1e3 in ?? () [New Thread 802407400 (LWP 100450/cupsd)] (gdb) # gdb csh csh.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `csh'. Program terminated with signal 10, Bus error. Reading symbols from /lib/libncurses.so.8...done. Loaded symbols for /lib/libncurses.so.8 Reading symbols from /lib/libcrypt.so.5...done. Loaded symbols for /lib/libcrypt.so.5 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/libiconv.so...done. Loaded symbols for /usr/local/lib/libiconv.so Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x00007ffffffff1e3 in ?? () (gdb) I can produce more if anyone is interested. -- Jim Ohlstein From owner-freebsd-stable@FreeBSD.ORG Wed May 8 17:47:25 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4B6B7B65; Wed, 8 May 2013 17:47:25 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with ESMTP id 228981AA; Wed, 8 May 2013 17:47:24 +0000 (UTC) Received: from glenbarber.us (75-146-225-65-Philadelphia.hfc.comcastbusiness.net [75.146.225.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id E46B123F804; Wed, 8 May 2013 13:47:23 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.3 onyx.glenbarber.us E46B123F804 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Wed, 8 May 2013 13:47:21 -0400 From: Glen Barber To: freebsd-stable@FreeBSD.org Subject: FreeBSD 8.4-RC3 is now available Message-ID: <20130508174721.GD1651@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="C1iGAkRnbeBonpVg" Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Release Engineering Team X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 17:47:25 -0000 --C1iGAkRnbeBonpVg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The third RC build of the 8.4-RELEASE release cycle is now available on the FTP servers for the amd64, i386, and pc98 architectures. The SHA256/MD5 sums are tacked on to the bottom of this message. The ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/8.4/ (or any of the FreeBSD mirror sites). If you notice problems you can report them through the normal GNATS PR system or here on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system use "releng/8.4". Changes between -RC2 and -RC3 include: - Fix a bug that allows NFS clients to issue READDIR on files - Update sendmail to 8.14.7 - Fix rtld(1) $ORIGIN length - Fix randomly-changing default routes The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 8.4-RC3 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 7.x. Alternatively, the user can install misc/compat7x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install Checksums: 8.4-RC3 amd64: SHA256 (FreeBSD-8.4-RC3-amd64-bootonly.iso) = 3ff93b3870287f51fa6f2a05c98898699af1646c6e90c35a9ae3f33d7fa80f8e SHA256 (FreeBSD-8.4-RC3-amd64-disc1.iso) = 5ba207726007dab001c502c190b6bb354c845c6ed142f25c8a1164d631ebb9b1 SHA256 (FreeBSD-8.4-RC3-amd64-disc2.iso) = a6ef99e7547fa322d6494332c7c2db8dc54cfcb92450127094f3a67ea3340efd SHA256 (FreeBSD-8.4-RC3-amd64-disc3.iso) = 44cc186f4258bdc15072d83f600ce6fd05cbe06dbe20240805093012161edbad SHA256 (FreeBSD-8.4-RC3-amd64-dvd1.iso) = f3394e4a90995a0b845b87f7c407c7a96aeffca502c9b70735310dd1e53259e5 SHA256 (FreeBSD-8.4-RC3-amd64-livefs.iso) = 73aa1f6b78e7cbf6ba5d375783c282f752487e0ebdab2f38a9ab903652eaddb9 SHA256 (FreeBSD-8.4-RC3-amd64-memstick.img) = dc4f0004cc16c3e1f5f8adec51d2c8a039abf53ed9b7159e95c9a5ea75842f89 MD5 (FreeBSD-8.4-RC3-amd64-bootonly.iso) = d2d1d66db2d5f2e72c8c4a38dbd18312 MD5 (FreeBSD-8.4-RC3-amd64-disc1.iso) = 108cd0e0272400a3cf9021a818b56dca MD5 (FreeBSD-8.4-RC3-amd64-disc2.iso) = 279b7aa8cec90c998c71425e37b8c4dc MD5 (FreeBSD-8.4-RC3-amd64-disc3.iso) = 398a832d1982afa0d48876afab1e3279 MD5 (FreeBSD-8.4-RC3-amd64-dvd1.iso) = 23691d46cc7455fdd9b7c144923fd4eb MD5 (FreeBSD-8.4-RC3-amd64-livefs.iso) = d569535aff66de3f3c74bd178a2f00c4 MD5 (FreeBSD-8.4-RC3-amd64-memstick.img) = 1bcea93744c2e8443335c153d9556ac0 8.4-RC3 i386: SHA256 (FreeBSD-8.4-RC3-i386-bootonly.iso) = 099b1ce82ed0bcb7d07777362d0d2c760009e384ce0ce6f3ecaa06e48d05395b SHA256 (FreeBSD-8.4-RC3-i386-disc1.iso) = 32f5a30271db4719023a247c66db4fc01faf1e6fdcbaa4189f38c3bd2b6042d5 SHA256 (FreeBSD-8.4-RC3-i386-disc2.iso) = 43ef26e243f8bb3c131ca2c591286f64012612d4ef1855cac006de2c29ee41fd SHA256 (FreeBSD-8.4-RC3-i386-disc3.iso) = e97dd2adebfc432e1fdf49f2ccf6cd787b2022b58f2d019704deee45d0bb8395 SHA256 (FreeBSD-8.4-RC3-i386-dvd1.iso) = bf7783105f1c1f72f5fdda9eabc058848ef0730ff508dd8bbdad6900ba692a86 SHA256 (FreeBSD-8.4-RC3-i386-livefs.iso) = 1cf71492ea711bfd95731ffe3f022ac7c4c78c63ad5c9e7d36085f622f12575b SHA256 (FreeBSD-8.4-RC3-i386-memstick.img) = c8cccd2d2731ac30311585650b25c937e401f1ead73ea920865e65f59d240414 MD5 (FreeBSD-8.4-RC3-i386-bootonly.iso) = 7a8a734ea9ff2ed0c6e5ebe0d92d44e1 MD5 (FreeBSD-8.4-RC3-i386-disc1.iso) = dcfeee526c2704014733bc8435cc7a58 MD5 (FreeBSD-8.4-RC3-i386-disc2.iso) = b6f16061dc889957993c28f23b0274b8 MD5 (FreeBSD-8.4-RC3-i386-disc3.iso) = f8eac044f8d59ace934bc887b8b13620 MD5 (FreeBSD-8.4-RC3-i386-dvd1.iso) = b74e9ce95abdf3dc8c2cdcf40c8db8b4 MD5 (FreeBSD-8.4-RC3-i386-livefs.iso) = e1e9cbfb104f80a2eb45fd04c24fc098 MD5 (FreeBSD-8.4-RC3-i386-memstick.img) = 06e0cfb0733f8ab9d418d340c90d1007 8.4-RC3 pc98: SHA256 (FreeBSD-8.4-RC3-pc98-bootonly.iso) = c258247f93c347a48b1b9b7a79009d6f2989b2f8d29959c884100af8c7be9704 SHA256 (FreeBSD-8.4-RC3-pc98-disc1.iso) = 8f04b9ab03eff0ded59bc61780325ab3a3f4e57d3044fe9318c7489eaa8b0345 SHA256 (FreeBSD-8.4-RC3-pc98-livefs.iso) = 0e22b94964cd69dc46cc8357ad65ec66b85bc02e9fa4548edc104f586641d9d8 MD5 (FreeBSD-8.4-RC3-pc98-bootonly.iso) = 467f027d46d094241416128f344b166a MD5 (FreeBSD-8.4-RC3-pc98-disc1.iso) = a1ba10e8d957269cd90dc357ddcb6618 MD5 (FreeBSD-8.4-RC3-pc98-livefs.iso) = bd19c8ba32756cc1e62af7f14032bdfe Glen --C1iGAkRnbeBonpVg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRio+pAAoJEFJPDDeguUaj+zoIAI2xlQtLw7Rzcfbr25QjbBx4 YPoKPw8C17dKrW/+jMrvj+sfLD7SYUL3btQepJlEIff47Z7e24eZI+Uq/fH6q5My EGIqLdpkRU54BCpTVi1w4TEI+BahrNo90+E94vx+iY6Kupa9IjI80Q2zXorMJQEz 5ZPpDByeL+voxFHPGRDt1dU6ypmryr5/NOnXFt0hFL8deN3jep3E0Yczxao1kY4e h4jpovi0VrXDgpBuogF2jHkbNJMUq+ZxU1qBYKuAJsw+bJ/Ma01Usxpb1SxHyKO4 8s6bw4RPSMXsHG82r8RuqvnMglQUECaHin5n+wn+4qPZOiJzhMLpnFZVltRu0i0= =Jaz/ -----END PGP SIGNATURE----- --C1iGAkRnbeBonpVg-- From owner-freebsd-stable@FreeBSD.ORG Wed May 8 17:59:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E88FFE05 for ; Wed, 8 May 2013 17:59:04 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id A51FF22C for ; Wed, 8 May 2013 17:59:04 +0000 (UTC) Received: (qmail 62483 invoked from network); 8 May 2013 17:58:57 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay01.pair.com with SMTP; 8 May 2013 17:58:57 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id r48Hwuk9032414; Wed, 8 May 2013 19:58:56 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id r48Hwuc2032413; Wed, 8 May 2013 19:58:56 +0200 (CEST) (envelope-from pho) Date: Wed, 8 May 2013 19:58:56 +0200 From: Peter Holm To: Konstantin Belousov Subject: Re: Nullfs leaks i-nodes Message-ID: <20130508175856.GA32341@x2.osted.lan> References: <20130508091317.GJ3047@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130508091317.GJ3047@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 17:59:05 -0000 On Wed, May 08, 2013 at 12:13:17PM +0300, Konstantin Belousov wrote: > On Tue, May 07, 2013 at 08:30:06AM +0200, G??ran L??wkrantz wrote: > > I created a PR, kern/178238, on this but would like to know if anyone has > > any ideas or patches? > > > > Have updated the system where I see this to FreeBSD 9.1-STABLE #0 r250229 > > and still have the problem. > > The patch below should fix the issue for you, at least it did so in my > limited testing. > > What is does: > 1. When inactivating a nullfs vnode, check if the lower vnode is > unlinked, and reclaim upper vnode if so. [This fixes your case]. > > 2. Besides a callback to the upper filesystems for the lower vnode > reclaimation, it also calls the upper fs for lower vnode unlink. > This allows nullfs to purge cached vnodes for the unlinked lower. > [This fixes an opposite case, when the vnode is removed from the > lower mount, but upper aliases prevent the vnode from being > recycled]. > > 3. Fix a wart which existed from the introduction of the nullfs caching, > do not unlock lower vnode in the nullfs_reclaim_lowervp(). It should > be completely innocent, but now it is also formally safe. > > 4. Fix vnode reference leak in nullfs_reclaim_lowervp(). > > Please note that the patch is basically not tested, I only verified your > scenario and a mirror of it as described in item 2. > > diff --git a/sys/fs/nullfs/null.h b/sys/fs/nullfs/null.h > index 4f37020..a624be6 100644 I got this page fault after interrupting a nullfs test that had been running for three hours: http://people.freebsd.org/~pho/stress/log/kostik562.txt - Peter From owner-freebsd-stable@FreeBSD.ORG Wed May 8 20:48:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 21CE5D08 for ; Wed, 8 May 2013 20:48:50 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id D2C0FB90 for ; Wed, 8 May 2013 20:48:49 +0000 (UTC) Received: (qmail 23910 invoked from network); 8 May 2013 20:48:47 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay01.pair.com with SMTP; 8 May 2013 20:48:47 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id r48KmkIk003964; Wed, 8 May 2013 22:48:47 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id r48KmkIb003963; Wed, 8 May 2013 22:48:46 +0200 (CEST) (envelope-from pho) Date: Wed, 8 May 2013 22:48:46 +0200 From: Peter Holm To: Konstantin Belousov Subject: Re: Nullfs leaks i-nodes Message-ID: <20130508204846.GA3806@x2.osted.lan> References: <20130508091317.GJ3047@kib.kiev.ua> <20130508175856.GA32341@x2.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130508175856.GA32341@x2.osted.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 20:48:50 -0000 On Wed, May 08, 2013 at 07:58:56PM +0200, Peter Holm wrote: > On Wed, May 08, 2013 at 12:13:17PM +0300, Konstantin Belousov wrote: > > On Tue, May 07, 2013 at 08:30:06AM +0200, G??ran L??wkrantz wrote: > > > I created a PR, kern/178238, on this but would like to know if anyone has > > > any ideas or patches? > > > > > > Have updated the system where I see this to FreeBSD 9.1-STABLE #0 r250229 > > > and still have the problem. > > > > The patch below should fix the issue for you, at least it did so in my > > limited testing. > > > > What is does: > > 1. When inactivating a nullfs vnode, check if the lower vnode is > > unlinked, and reclaim upper vnode if so. [This fixes your case]. > > > > 2. Besides a callback to the upper filesystems for the lower vnode > > reclaimation, it also calls the upper fs for lower vnode unlink. > > This allows nullfs to purge cached vnodes for the unlinked lower. > > [This fixes an opposite case, when the vnode is removed from the > > lower mount, but upper aliases prevent the vnode from being > > recycled]. > > > > 3. Fix a wart which existed from the introduction of the nullfs caching, > > do not unlock lower vnode in the nullfs_reclaim_lowervp(). It should > > be completely innocent, but now it is also formally safe. > > > > 4. Fix vnode reference leak in nullfs_reclaim_lowervp(). > > > > Please note that the patch is basically not tested, I only verified your > > scenario and a mirror of it as described in item 2. > > > > diff --git a/sys/fs/nullfs/null.h b/sys/fs/nullfs/null.h > > index 4f37020..a624be6 100644 > > I got this page fault after interrupting a nullfs test that had been > running for three hours: > > http://people.freebsd.org/~pho/stress/log/kostik562.txt > Seems to be easily reproduced, so I compiled null_vnops.c and fifo_vnops.c without "-O" in order to get some more info: http://people.freebsd.org/~pho/stress/log/kostik563.txt - Peter From owner-freebsd-stable@FreeBSD.ORG Thu May 9 05:31:07 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 256AEC05 for ; Thu, 9 May 2013 05:31:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 876511E10 for ; Thu, 9 May 2013 05:31:06 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r495Uu2i083650; Thu, 9 May 2013 08:30:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r495Uu2i083650 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r495UtHT083647; Thu, 9 May 2013 08:30:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 May 2013 08:30:55 +0300 From: Konstantin Belousov To: Jim Ohlstein Subject: Re: Apparent regression in r250359 Message-ID: <20130509053055.GM3047@kib.kiev.ua> References: <518A880C.3090906@ohlste.in> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AA6ket75tXCPafnC" Content-Disposition: inline In-Reply-To: <518A880C.3090906@ohlste.in> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 05:31:07 -0000 --AA6ket75tXCPafnC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 08, 2013 at 01:14:52PM -0400, Jim Ohlstein wrote: > Hello, >=20 > I upgraded my (custom) kernel earlier and found that multiple daemons=20 > (cups, hal, syslog, ntpd, csh) crashed and dumped cores at or shortly=20 > after boot. >=20 > The error I saw several times on the console was: >=20 > set_fpcontext err 22 >=20 > I recompiled using the GENERIC kernel and saw the same error. >=20 >=20 > The error appears to be in the changes made in r250359 in fpu.c, as=20 > r250358 boots as expected. >=20 Quite weird, and the most troublesome part is that I cannot reproduce it locally. As a temporal workaround, you could set 'hw.use_xsave=3D0' at the loader prompt. The instructions below for kgdb assume that=20 you did not applied this workaround. What CPU do you have ? Please show me the verbose dmesg of the boot. Next, please do the following: run 'kgdb /boot/kernel/kernel /dev/mem', and from the kgdb prompt, do 'x/1xw use_xsave' and 'x/1xg xsave_mask'. Also, see below. > # uname -a > FreeBSD lucid-insanity 9.1-STABLE FreeBSD 9.1-STABLE #3 r250358: Wed May= =20 > 8 11:56:43 EDT 2013=20 > root@lucid-insanity:/usr/obj/usr/src/sys/GENERIC amd64 >=20 >=20 > World and kernel are built with clang 3.2. >=20 > r250359 produces the error and core dumps: >=20 > Sample gdb output: >=20 > # gdb cupsd cupsd.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain=20 > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "amd64-marcel-freebsd"...(no debugging=20 > symbols found)... > Core was generated by `cupsd'. > Program terminated with signal 10, Bus error. > Reading symbols from /usr/local/lib/libcupsmime.so.1...(no debugging=20 > symbols found)...done. > Loaded symbols for /usr/local/lib/libcupsmime.so.1 > Reading symbols from /lib/libz.so.6...done. > Loaded symbols for /lib/libz.so.6 > Reading symbols from /usr/lib/libssl.so.6...done. > Loaded symbols for /usr/lib/libssl.so.6 > Reading symbols from /lib/libcrypto.so.6...done. > Loaded symbols for /lib/libcrypto.so.6 > Reading symbols from /usr/local/lib/libpaper.so.2...done. > Loaded symbols for /usr/local/lib/libpaper.so.2 > Reading symbols from /usr/local/lib/libcups.so.2...done. > Loaded symbols for /usr/local/lib/libcups.so.2 > Reading symbols from /lib/libcrypt.so.5...done. > Loaded symbols for /lib/libcrypt.so.5 > Reading symbols from /lib/libm.so.5...done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /usr/local/lib/libiconv.so.3...done. > Loaded symbols for /usr/local/lib/libiconv.so.3 > Reading symbols from /lib/libthr.so.3...done. > Loaded symbols for /lib/libthr.so.3 > Reading symbols from /lib/libc.so.7...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x00007ffffffff1e3 in ?? () > [New Thread 802407400 (LWP 100450/cupsd)] > (gdb) >=20 > # gdb csh csh.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain=20 > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "amd64-marcel-freebsd"... > Core was generated by `csh'. > Program terminated with signal 10, Bus error. > Reading symbols from /lib/libncurses.so.8...done. > Loaded symbols for /lib/libncurses.so.8 > Reading symbols from /lib/libcrypt.so.5...done. > Loaded symbols for /lib/libcrypt.so.5 > Reading symbols from /lib/libc.so.7...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /usr/local/lib/libiconv.so...done. > Loaded symbols for /usr/local/lib/libiconv.so > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x00007ffffffff1e3 in ?? () > (gdb) =46rom the core dump above, please do 'info registers' then take the value from %rdi and do 'x/2xg $rdi+0x300', then take the first value printed (let denote it as XSAVEADDR) and do 'x/8xg XSAVEADDR'. >=20 > I can produce more if anyone is interested. >=20 >=20 > --=20 > Jim Ohlstein > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" --AA6ket75tXCPafnC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRizSPAAoJEJDCuSvBvK1BrMsP/27OZamW+XQR/05hg4DXzWB9 34sS25powuy8qvggSjjpBMBhjkmWvTcO7CfhuxgSkJAqQaWGN3BHVnbmSZuSo7o/ cenrC+hZiBGKQxqXstaGOxmYnv8jhVn6nexcBZnDvMPZ1YCTw1ArL0uF9PiJG9xk 1HG20gMDlydgCmj7tqDi7wuqHDKHteyIJmP1UP33+nNi1HAqD6npuVbSG2jEZxfh yvrf3S54oEPRaDUXl9TUNlSey0TGv/omxJgh6zqZuPdk5OENeodWAngZTd74XKTf FRa0iUFqm5KZhLNQMegenaG3FyvNdl2uUb+0MdZ1Ajoqe7XHVWk7lHKaacvWytUg 48+uNHcEdxdEWWiaG00252d6VQ7MfRhKFNlzmoc2lOsHKlKm0YYyhaCcgCKDbdEB hcUT4QCInRrq2s1FPhsVk0On80i0fncSrGIpdsxKBfvqeIxgICWOJD6ELvgIO4sX Jeir/I1Nz7LQD2BgpoRB6pGfjlSVrlkT8f2jb6L++M+3XU4Fa2SXJxrcSqqxUVpm Y6GhJSgWEN8C7NEC8aWUDj/FVdpEhiOtwEhkn9aPrUCB+8KmanAgZTcch5MUnokz /dL2IGiKmJ23tLdo1Y3qFkc25nk7tD59zWA9Yf2e+BtDm3X2DqyrShw6bi8CRMXB DnC3hpHC14tUC5c8d61m =x9n7 -----END PGP SIGNATURE----- --AA6ket75tXCPafnC-- From owner-freebsd-stable@FreeBSD.ORG Thu May 9 07:03:06 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 17EAA6DE for ; Thu, 9 May 2013 07:03:06 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id C9080353 for ; Thu, 9 May 2013 07:03:05 +0000 (UTC) Received: (qmail 15317 invoked from network); 9 May 2013 07:02:58 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay02.pair.com with SMTP; 9 May 2013 07:02:58 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id r4972vDA015984; Thu, 9 May 2013 09:02:57 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id r4972vw2015983; Thu, 9 May 2013 09:02:57 +0200 (CEST) (envelope-from pho) Date: Thu, 9 May 2013 09:02:56 +0200 From: Peter Holm To: Konstantin Belousov Subject: Re: Nullfs leaks i-nodes Message-ID: <20130509070256.GA15884@x2.osted.lan> References: <20130508091317.GJ3047@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130508091317.GJ3047@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 07:03:06 -0000 On Wed, May 08, 2013 at 12:13:17PM +0300, Konstantin Belousov wrote: > On Tue, May 07, 2013 at 08:30:06AM +0200, G??ran L??wkrantz wrote: > > I created a PR, kern/178238, on this but would like to know if anyone has > > any ideas or patches? > > > > Have updated the system where I see this to FreeBSD 9.1-STABLE #0 r250229 > > and still have the problem. > > The patch below should fix the issue for you, at least it did so in my > limited testing. > > What is does: > 1. When inactivating a nullfs vnode, check if the lower vnode is > unlinked, and reclaim upper vnode if so. [This fixes your case]. > > 2. Besides a callback to the upper filesystems for the lower vnode > reclaimation, it also calls the upper fs for lower vnode unlink. > This allows nullfs to purge cached vnodes for the unlinked lower. > [This fixes an opposite case, when the vnode is removed from the > lower mount, but upper aliases prevent the vnode from being > recycled]. > > 3. Fix a wart which existed from the introduction of the nullfs caching, > do not unlock lower vnode in the nullfs_reclaim_lowervp(). It should > be completely innocent, but now it is also formally safe. > > 4. Fix vnode reference leak in nullfs_reclaim_lowervp(). > > Please note that the patch is basically not tested, I only verified your > scenario and a mirror of it as described in item 2. > > diff --git a/sys/fs/nullfs/null.h b/sys/fs/nullfs/null.h > index 4f37020..a624be6 100644 > --- a/sys/fs/nullfs/null.h The page fault seen in fifo_close() seems unrelated to this patch, which I will continue testing some more. The scenario triggering the page fault is the "rm": mdconfig -a -t swap -s 1g -u 5 bsdlabel -w md5 auto newfs -U md5a mount /dev/md5a /mnt mount -t nullfs /mnt /mnt2 mkfifo /mnt2/fifo rm /mnt/fifo Not a problem on 8.3-STABLE r247938. - Peter From owner-freebsd-stable@FreeBSD.ORG Thu May 9 07:20:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8A512A60 for ; Thu, 9 May 2013 07:20:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id AC468402 for ; Thu, 9 May 2013 07:20:56 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r497KkxS010782; Thu, 9 May 2013 10:20:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r497KkxS010782 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r497Kk11010780; Thu, 9 May 2013 10:20:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 May 2013 10:20:46 +0300 From: Konstantin Belousov To: Peter Holm Subject: Re: Nullfs leaks i-nodes Message-ID: <20130509072046.GN3047@kib.kiev.ua> References: <20130508091317.GJ3047@kib.kiev.ua> <20130509070256.GA15884@x2.osted.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CzJ9BTjEYwHt6w7v" Content-Disposition: inline In-Reply-To: <20130509070256.GA15884@x2.osted.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 07:20:57 -0000 --CzJ9BTjEYwHt6w7v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 09, 2013 at 09:02:56AM +0200, Peter Holm wrote: > On Wed, May 08, 2013 at 12:13:17PM +0300, Konstantin Belousov wrote: > > On Tue, May 07, 2013 at 08:30:06AM +0200, G??ran L??wkrantz wrote: > > > I created a PR, kern/178238, on this but would like to know if anyone= has=20 > > > any ideas or patches? > > >=20 > > > Have updated the system where I see this to FreeBSD 9.1-STABLE #0 r25= 0229=20 > > > and still have the problem. > >=20 > > The patch below should fix the issue for you, at least it did so in my > > limited testing. > >=20 > > What is does: > > 1. When inactivating a nullfs vnode, check if the lower vnode is > > unlinked, and reclaim upper vnode if so. [This fixes your case]. > >=20 > > 2. Besides a callback to the upper filesystems for the lower vnode > > reclaimation, it also calls the upper fs for lower vnode unlink. > > This allows nullfs to purge cached vnodes for the unlinked lower. > > [This fixes an opposite case, when the vnode is removed from the > > lower mount, but upper aliases prevent the vnode from being > > recycled]. > >=20 > > 3. Fix a wart which existed from the introduction of the nullfs caching, > > do not unlock lower vnode in the nullfs_reclaim_lowervp(). It should > > be completely innocent, but now it is also formally safe. > >=20 > > 4. Fix vnode reference leak in nullfs_reclaim_lowervp(). > >=20 > > Please note that the patch is basically not tested, I only verified your > > scenario and a mirror of it as described in item 2. > >=20 > > diff --git a/sys/fs/nullfs/null.h b/sys/fs/nullfs/null.h > > index 4f37020..a624be6 100644 > > --- a/sys/fs/nullfs/null.h >=20 > The page fault seen in fifo_close() seems unrelated to this patch, > which I will continue testing some more. >=20 > The scenario triggering the page fault is the "rm": >=20 > mdconfig -a -t swap -s 1g -u 5 > bsdlabel -w md5 auto > newfs -U md5a > mount /dev/md5a /mnt > mount -t nullfs /mnt /mnt2 > mkfifo /mnt2/fifo > rm /mnt/fifo Yeah, I figured this out from the backtrace. The panic in kostik563 is related and directly caused by the patch, since patch erronously performs vgone() on the active (removed) vnode. As result, a spurious VOP_CLOSE() call is performed on the vnode, which is more or less innocent for regular files, but fatal for fifos and probably nfsv4 as well. Updated patch is below. >=20 > Not a problem on 8.3-STABLE r247938. Yes, new nullfs is only in HEAD and stable/9. diff --git a/sys/fs/nullfs/null.h b/sys/fs/nullfs/null.h index 4f37020..0972dfc 100644 --- a/sys/fs/nullfs/null.h +++ b/sys/fs/nullfs/null.h @@ -53,8 +53,12 @@ struct null_node { LIST_ENTRY(null_node) null_hash; /* Hash list */ struct vnode *null_lowervp; /* VREFed once */ struct vnode *null_vnode; /* Back pointer */ + u_int null_flags; }; =20 +#define NULLV_NOUNLOCK 0x0001 +#define NULLV_DROP 0x0002 + #define MOUNTTONULLMOUNT(mp) ((struct null_mount *)((mp)->mnt_data)) #define VTONULL(vp) ((struct null_node *)(vp)->v_data) #define NULLTOV(xp) ((xp)->null_vnode) diff --git a/sys/fs/nullfs/null_vfsops.c b/sys/fs/nullfs/null_vfsops.c index 02932bd..ad02236 100644 --- a/sys/fs/nullfs/null_vfsops.c +++ b/sys/fs/nullfs/null_vfsops.c @@ -65,7 +65,6 @@ static vfs_statfs_t nullfs_statfs; static vfs_unmount_t nullfs_unmount; static vfs_vget_t nullfs_vget; static vfs_extattrctl_t nullfs_extattrctl; -static vfs_reclaim_lowervp_t nullfs_reclaim_lowervp; =20 /* * Mount null layer @@ -391,8 +390,37 @@ nullfs_reclaim_lowervp(struct mount *mp, struct vnode = *lowervp) vp =3D null_hashget(mp, lowervp); if (vp =3D=3D NULL) return; + VTONULL(vp)->null_flags |=3D NULLV_NOUNLOCK; vgone(vp); - vn_lock(lowervp, LK_EXCLUSIVE | LK_RETRY); + vput(vp); +} + +static void +nullfs_unlink_lowervp(struct mount *mp, struct vnode *lowervp) +{ + struct vnode *vp; + struct null_node *xp; + + vp =3D null_hashget(mp, lowervp); + if (vp =3D=3D NULL) + return; + xp =3D VTONULL(vp); + xp->null_flags |=3D NULLV_DROP | NULLV_NOUNLOCK; + vhold(vp); + vunref(vp); + + /* + * If vunref() dropped the last use reference on the nullfs + * vnode, it must be reclaimed, and its lock was split from + * the lower vnode lock. Need to do extra unlock before + * allowing the final vdrop() to free the vnode. + */ + if (vp->v_usecount =3D=3D 0) { + KASSERT((vp->v_iflag & VI_DOOMED) !=3D 0, + ("not reclaimed %p", vp)); + VOP_UNLOCK(vp, 0); + } + vdrop(vp); } =20 static struct vfsops null_vfsops =3D { @@ -408,6 +436,7 @@ static struct vfsops null_vfsops =3D { .vfs_unmount =3D nullfs_unmount, .vfs_vget =3D nullfs_vget, .vfs_reclaim_lowervp =3D nullfs_reclaim_lowervp, + .vfs_unlink_lowervp =3D nullfs_unlink_lowervp, }; =20 VFS_SET(null_vfsops, nullfs, VFCF_LOOPBACK | VFCF_JAIL); diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c index f59865f..6ff15ee 100644 --- a/sys/fs/nullfs/null_vnops.c +++ b/sys/fs/nullfs/null_vnops.c @@ -692,18 +692,24 @@ null_unlock(struct vop_unlock_args *ap) static int null_inactive(struct vop_inactive_args *ap __unused) { - struct vnode *vp; + struct vnode *vp, *lvp; + struct null_node *xp; struct mount *mp; struct null_mount *xmp; =20 vp =3D ap->a_vp; + xp =3D VTONULL(vp); + lvp =3D NULLVPTOLOWERVP(vp); mp =3D vp->v_mount; xmp =3D MOUNTTONULLMOUNT(mp); - if ((xmp->nullm_flags & NULLM_CACHE) =3D=3D 0) { + if ((xmp->nullm_flags & NULLM_CACHE) =3D=3D 0 || + (xp->null_flags & NULLV_DROP) !=3D 0 || + (lvp->v_vflag & VV_NOSYNC) !=3D 0) { /* * If this is the last reference and caching of the - * nullfs vnodes is not enabled, then free up the - * vnode so as not to tie up the lower vnodes. + * nullfs vnodes is not enabled, or the lower vnode is + * deleted, then free up the vnode so as not to tie up + * the lower vnodes. */ vp->v_object =3D NULL; vrecycle(vp); @@ -748,7 +754,10 @@ null_reclaim(struct vop_reclaim_args *ap) */ if (vp->v_writecount > 0) VOP_ADD_WRITECOUNT(lowervp, -1); - vput(lowervp); + if ((xp->null_flags & NULLV_NOUNLOCK) !=3D 0) + vunref(lowervp); + else + vput(lowervp); free(xp, M_NULLFSNODE); =20 return (0); diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index de118f7..988a114 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -2700,19 +2700,20 @@ vgone(struct vnode *vp) } =20 static void -vgonel_reclaim_lowervp_vfs(struct mount *mp __unused, +notify_lowervp_vfs_dummy(struct mount *mp __unused, struct vnode *lowervp __unused) { } =20 /* - * Notify upper mounts about reclaimed vnode. + * Notify upper mounts about reclaimed or unlinked vnode. */ -static void -vgonel_reclaim_lowervp(struct vnode *vp) +void +vfs_notify_upper(struct vnode *vp, int event) { static struct vfsops vgonel_vfsops =3D { - .vfs_reclaim_lowervp =3D vgonel_reclaim_lowervp_vfs + .vfs_reclaim_lowervp =3D notify_lowervp_vfs_dummy, + .vfs_unlink_lowervp =3D notify_lowervp_vfs_dummy, }; struct mount *mp, *ump, *mmp; =20 @@ -2736,7 +2737,17 @@ vgonel_reclaim_lowervp(struct vnode *vp) } TAILQ_INSERT_AFTER(&mp->mnt_uppers, ump, mmp, mnt_upper_link); MNT_IUNLOCK(mp); - VFS_RECLAIM_LOWERVP(ump, vp); + switch (event) { + case VFS_NOTIFY_UPPER_RECLAIM: + VFS_RECLAIM_LOWERVP(ump, vp); + break; + case VFS_NOTIFY_UPPER_UNLINK: + VFS_UNLINK_LOWERVP(ump, vp); + break; + default: + KASSERT(0, ("invalid event %d", event)); + break; + } MNT_ILOCK(mp); ump =3D TAILQ_NEXT(mmp, mnt_upper_link); TAILQ_REMOVE(&mp->mnt_uppers, mmp, mnt_upper_link); @@ -2783,7 +2794,7 @@ vgonel(struct vnode *vp) active =3D vp->v_usecount; oweinact =3D (vp->v_iflag & VI_OWEINACT); VI_UNLOCK(vp); - vgonel_reclaim_lowervp(vp); + vfs_notify_upper(vp, VFS_NOTIFY_UPPER_RECLAIM); =20 /* * Clean out any buffers associated with the vnode. diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c index 29cb7bd..a004ea0 100644 --- a/sys/kern/vfs_syscalls.c +++ b/sys/kern/vfs_syscalls.c @@ -1846,6 +1846,7 @@ restart: if (error) goto out; #endif + vfs_notify_upper(vp, VFS_NOTIFY_UPPER_UNLINK); error =3D VOP_REMOVE(nd.ni_dvp, vp, &nd.ni_cnd); #ifdef MAC out: @@ -3825,6 +3826,7 @@ restart: return (error); goto restart; } + vfs_notify_upper(vp, VFS_NOTIFY_UPPER_UNLINK); error =3D VOP_RMDIR(nd.ni_dvp, nd.ni_vp, &nd.ni_cnd); vn_finished_write(mp); out: diff --git a/sys/sys/mount.h b/sys/sys/mount.h index a9c86f6..a953dae 100644 --- a/sys/sys/mount.h +++ b/sys/sys/mount.h @@ -608,7 +608,7 @@ typedef int vfs_mount_t(struct mount *mp); typedef int vfs_sysctl_t(struct mount *mp, fsctlop_t op, struct sysctl_req *req); typedef void vfs_susp_clean_t(struct mount *mp); -typedef void vfs_reclaim_lowervp_t(struct mount *mp, struct vnode *lowervp= ); +typedef void vfs_notify_lowervp_t(struct mount *mp, struct vnode *lowervp); =20 struct vfsops { vfs_mount_t *vfs_mount; @@ -626,7 +626,8 @@ struct vfsops { vfs_extattrctl_t *vfs_extattrctl; vfs_sysctl_t *vfs_sysctl; vfs_susp_clean_t *vfs_susp_clean; - vfs_reclaim_lowervp_t *vfs_reclaim_lowervp; + vfs_notify_lowervp_t *vfs_reclaim_lowervp; + vfs_notify_lowervp_t *vfs_unlink_lowervp; }; =20 vfs_statfs_t __vfs_statfs; @@ -747,6 +748,14 @@ vfs_statfs_t __vfs_statfs; } \ } while (0) =20 +#define VFS_UNLINK_LOWERVP(MP, VP) do { \ + if (*(MP)->mnt_op->vfs_unlink_lowervp !=3D NULL) { \ + VFS_PROLOGUE(MP); \ + (*(MP)->mnt_op->vfs_unlink_lowervp)((MP), (VP)); \ + VFS_EPILOGUE(MP); \ + } \ +} while (0) + #define VFS_KNOTE_LOCKED(vp, hint) do \ { \ if (((vp)->v_vflag & VV_NOKNOTE) =3D=3D 0) \ @@ -759,6 +768,9 @@ vfs_statfs_t __vfs_statfs; VN_KNOTE((vp), (hint), 0); \ } while (0) =20 +#define VFS_NOTIFY_UPPER_RECLAIM 1 +#define VFS_NOTIFY_UPPER_UNLINK 2 + #include =20 /* @@ -840,6 +852,7 @@ int vfs_modevent(module_t, int, void *); void vfs_mount_error(struct mount *, const char *, ...); void vfs_mountroot(void); /* mount our root filesystem */ void vfs_mountedfrom(struct mount *, const char *from); +void vfs_notify_upper(struct vnode *, int); void vfs_oexport_conv(const struct oexport_args *oexp, struct export_args *exp); void vfs_ref(struct mount *); --CzJ9BTjEYwHt6w7v Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRi05NAAoJEJDCuSvBvK1BuFkP/i4qzpF1cWvS3zmNFxrMK4HN QKEcbbUByJhzuwxTsgAKPI/VXI2zs8PW0by3ul4Tl4x9forfja578esLdaTW83QZ VGntUXYfJXYBEg5kC3IdfOWAyHZa5S84OZI/Dd3wur0ftxvQPPydE809Ri+Zh4Nw vzL0uroV6k6N3PUgE1HVTeIR99Ft+U1vy7aymQC/kSFYPahur0N9P7Z6U9cIQWkp SvOQ7xlQZd3o5FJ3hNT+D+IgjSz9PveePSobe7LqGgB1/Pj3wvW7jsaQKZ3OlV+N DkA6COQ2VaaOH4Cr9UGw+G0Vk1u7sKBKnDsP+7iIjv6T/nk5G2ry2ICmQFKTSlzb Y4eWp1h9VWh1+QalYBpXi8b3kdLGRf7pRO7TT8gX6ixZnhVYsY9mrSfSGZWeLVNO g5OHPXSVof7eje34LW9WEnUGrmteHzbzgIJGrC7++kEXdEdTgS59jhQwzoiHFObY U4brSroNEN8WJhftBU5cz/ahbNeAoEVt1aT1ZosZwOSLWQ6LpeIxe/0Bd1VrDKb1 W4CZ4saV43CbDcL77h2Fja1+MyxZqAgOxd9bZ4zlEROYcZWuYI7PelDQY7ICCvDv gF51ho0PwncD8+r/0R4bT8vjL4PGBV2T+CG2WRJFtGs61H4lyMUJJDrQK3STMM2y aTZhLmZTD55gEkC0QM+J =cA3q -----END PGP SIGNATURE----- --CzJ9BTjEYwHt6w7v-- From owner-freebsd-stable@FreeBSD.ORG Thu May 9 09:17:46 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B042A8D6; Thu, 9 May 2013 09:17:46 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) by mx1.freebsd.org (Postfix) with ESMTP id 78FA6AD1; Thu, 9 May 2013 09:17:46 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id D094FC4B72; Thu, 9 May 2013 09:17:38 +0000 (UTC) Date: Thu, 9 May 2013 11:17:38 +0200 From: Jeremie Le Hen To: Jamie Gritton Subject: Re: new jail(8) ignoring devfs_ruleset? Message-ID: <20130509091738.GC4437@caravan.chchile.org> Mail-Followup-To: Jamie Gritton , Miroslav Lachman <000.fbsd@quip.cz>, Harald Schmalzbauer , freebsd-jail@FreeBSD.org, freebsd-stable@FreeBSD.org References: <511E61F5.1000805@omnilan.de> <511EC759.4060704@FreeBSD.org> <5121EC52.5040502@omnilan.de> <20130219212430.GA92116@felucia.tataz.chchile.org> <514B9EF6.3000607@quip.cz> <514BA14F.3090609@FreeBSD.org> <514BA3D9.5010901@quip.cz> <514BAA01.20402@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <514BAA01.20402@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Harald Schmalzbauer , freebsd-jail@FreeBSD.org, freebsd-stable@FreeBSD.org, Miroslav Lachman <000.fbsd@quip.cz> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 09:17:46 -0000 On Thu, Mar 21, 2013 at 06:46:57PM -0600, Jamie Gritton wrote: > > It's not fixed anywhere yet - it sometimes works in current, and > sometimes doesn't. I've been meaning to patch it up, but it the problem > is what I think it is, the patching up is a pretty big operation. > > It doesn't mean you can't use jails with devfs in 9.1, just that you > can't use them with jail.conf. The old jail rc file that's all > shell-based is still the official jail startup method, and that one > still works. So existing systems will still work as expected, hence no > errata. Shouldn't we warn the user about that in the manpage though? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-stable@FreeBSD.ORG Thu May 9 12:11:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0FA06F91; Thu, 9 May 2013 12:11:55 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (mail.ismobile.com [176.57.193.164]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB4628A; Thu, 9 May 2013 12:11:54 +0000 (UTC) Received: from mail.ismobile.com (localhost [127.0.0.1]) by dkim.mail.ismobile.com (Postfix) with ESMTP id 652082B548F; Thu, 9 May 2013 12:11:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ismobile.com; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=selector1; bh=mZmKbQq iRajqyoECZ5qmISk368Y=; b=dUAJmmX3n6LCJbD1+gG2Hrw8lHjr70YgR732970 X8QTkNOllwZpseJIRBkNAYebxFWB9hr/iIkQp37C4zEN4sZaVHJPjhRYRKx9wx/F 60GjecRTEfBXQ5/kS8kXOHxRyo4YLjc6YSfgNn2qfvFqg3fphZ0G5zocRr4qa2me qG7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ismobile.com; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=selector1; b=l TeHNB8zd+imV7J2VnOL0QvvpwtnmTbTK+28r8UwbvnJ0+o5HmQJtvJbv54Ze9uvO YEZTeKbl15MuNBkY/DZvQfhbaHbid73I8vkdpeb4E52pWTxBuPQ8ndK0Su84wNDg A12LNaumBFASXoskWQ2nCh3WIauXCKDG09LCAao1QM= Received: from tor.glz.hidden-powers.com (h77-53-100-26.dynamic.se.alltele.net [77.53.100.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id 2D5F02B548E; Thu, 9 May 2013 12:11:45 +0000 (UTC) Date: Thu, 09 May 2013 14:11:44 +0200 From: Goran Lowkrantz To: Konstantin Belousov Subject: Re: Nullfs leaks i-nodes Message-ID: In-Reply-To: <20130508091317.GJ3047@kib.kiev.ua> References: <20130508091317.GJ3047@kib.kiev.ua> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: pho@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 12:11:55 -0000 --On Wednesday, 08 May, 2013 12:13 PM +0300 Konstantin Belousov wrote: > On Tue, May 07, 2013 at 08:30:06AM +0200, G??ran L??wkrantz wrote: >> I created a PR, kern/178238, on this but would like to know if anyone >> has any ideas or patches? >> >> Have updated the system where I see this to FreeBSD 9.1-STABLE #0 >> r250229 and still have the problem. > > The patch below should fix the issue for you, at least it did so in my > limited testing. > > What is does: > 1. When inactivating a nullfs vnode, check if the lower vnode is > unlinked, and reclaim upper vnode if so. [This fixes your case]. > > 2. Besides a callback to the upper filesystems for the lower vnode > reclaimation, it also calls the upper fs for lower vnode unlink. > This allows nullfs to purge cached vnodes for the unlinked lower. > [This fixes an opposite case, when the vnode is removed from the > lower mount, but upper aliases prevent the vnode from being > recycled]. > > 3. Fix a wart which existed from the introduction of the nullfs caching, > do not unlock lower vnode in the nullfs_reclaim_lowervp(). It should > be completely innocent, but now it is also formally safe. > > 4. Fix vnode reference leak in nullfs_reclaim_lowervp(). > > Please note that the patch is basically not tested, I only verified your > scenario and a mirror of it as described in item 2. > > diff --git a/sys/fs/nullfs/null.h b/sys/fs/nullfs/null.h > index 4f37020..a624be6 100644 > --- a/sys/fs/nullfs/null.h > +++ b/sys/fs/nullfs/null.h > @@ -53,8 +53,11 @@ struct null_node { > LIST_ENTRY(null_node) null_hash; /* Hash list */ > struct vnode *null_lowervp; /* VREFed once */ > struct vnode *null_vnode; /* Back pointer */ > + u_int null_flags; > }; > > +#define NULLV_NOUNLOCK 0x0001 > + > #define MOUNTTONULLMOUNT(mp) ((struct null_mount *)((mp)->mnt_data)) > #define VTONULL(vp) ((struct null_node *)(vp)->v_data) > #define NULLTOV(xp) ((xp)->null_vnode) > diff --git a/sys/fs/nullfs/null_vfsops.c b/sys/fs/nullfs/null_vfsops.c > index 02932bd..544c358 100644 > --- a/sys/fs/nullfs/null_vfsops.c > +++ b/sys/fs/nullfs/null_vfsops.c > @@ -65,7 +65,6 @@ static vfs_statfs_t nullfs_statfs; > static vfs_unmount_t nullfs_unmount; > static vfs_vget_t nullfs_vget; > static vfs_extattrctl_t nullfs_extattrctl; > -static vfs_reclaim_lowervp_t nullfs_reclaim_lowervp; > > /* > * Mount null layer > @@ -391,8 +390,22 @@ nullfs_reclaim_lowervp(struct mount *mp, struct > vnode *lowervp) vp = null_hashget(mp, lowervp); > if (vp == NULL) > return; > + VTONULL(vp)->null_flags |= NULLV_NOUNLOCK; > vgone(vp); > - vn_lock(lowervp, LK_EXCLUSIVE | LK_RETRY); > + vput(vp); > +} > + > +static void > +nullfs_unlink_lowervp(struct mount *mp, struct vnode *lowervp) > +{ > + struct vnode *vp; > + > + vp = null_hashget(mp, lowervp); > + if (vp == NULL || vp->v_usecount > 1) > + return; > + VTONULL(vp)->null_flags |= NULLV_NOUNLOCK; > + vgone(vp); > + vput(vp); > } > > static struct vfsops null_vfsops = { > @@ -408,6 +421,7 @@ static struct vfsops null_vfsops = { > .vfs_unmount = nullfs_unmount, > .vfs_vget = nullfs_vget, > .vfs_reclaim_lowervp = nullfs_reclaim_lowervp, > + .vfs_unlink_lowervp = nullfs_unlink_lowervp, > }; > > VFS_SET(null_vfsops, nullfs, VFCF_LOOPBACK | VFCF_JAIL); > diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c > index f59865f..3c41124 100644 > --- a/sys/fs/nullfs/null_vnops.c > +++ b/sys/fs/nullfs/null_vnops.c > @@ -692,18 +692,21 @@ null_unlock(struct vop_unlock_args *ap) > static int > null_inactive(struct vop_inactive_args *ap __unused) > { > - struct vnode *vp; > + struct vnode *vp, *lvp; > struct mount *mp; > struct null_mount *xmp; > > vp = ap->a_vp; > + lvp = NULLVPTOLOWERVP(vp); > mp = vp->v_mount; > xmp = MOUNTTONULLMOUNT(mp); > - if ((xmp->nullm_flags & NULLM_CACHE) == 0) { > + if ((xmp->nullm_flags & NULLM_CACHE) == 0 || > + (lvp->v_vflag & VV_NOSYNC) != 0) { > /* > * If this is the last reference and caching of the > - * nullfs vnodes is not enabled, then free up the > - * vnode so as not to tie up the lower vnodes. > + * nullfs vnodes is not enabled, or the lower vnode is > + * deleted, then free up the vnode so as not to tie up > + * the lower vnodes. > */ > vp->v_object = NULL; > vrecycle(vp); > @@ -748,7 +751,10 @@ null_reclaim(struct vop_reclaim_args *ap) > */ > if (vp->v_writecount > 0) > VOP_ADD_WRITECOUNT(lowervp, -1); > - vput(lowervp); > + if ((xp->null_flags & NULLV_NOUNLOCK) != 0) > + vunref(lowervp); > + else > + vput(lowervp); > free(xp, M_NULLFSNODE); > > return (0); > diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c > index de118f7..988a114 100644 > --- a/sys/kern/vfs_subr.c > +++ b/sys/kern/vfs_subr.c > @@ -2700,19 +2700,20 @@ vgone(struct vnode *vp) > } > > static void > -vgonel_reclaim_lowervp_vfs(struct mount *mp __unused, > +notify_lowervp_vfs_dummy(struct mount *mp __unused, > struct vnode *lowervp __unused) > { > } > > /* > - * Notify upper mounts about reclaimed vnode. > + * Notify upper mounts about reclaimed or unlinked vnode. > */ > -static void > -vgonel_reclaim_lowervp(struct vnode *vp) > +void > +vfs_notify_upper(struct vnode *vp, int event) > { > static struct vfsops vgonel_vfsops = { > - .vfs_reclaim_lowervp = vgonel_reclaim_lowervp_vfs > + .vfs_reclaim_lowervp = notify_lowervp_vfs_dummy, > + .vfs_unlink_lowervp = notify_lowervp_vfs_dummy, > }; > struct mount *mp, *ump, *mmp; > > @@ -2736,7 +2737,17 @@ vgonel_reclaim_lowervp(struct vnode *vp) > } > TAILQ_INSERT_AFTER(&mp->mnt_uppers, ump, mmp, mnt_upper_link); > MNT_IUNLOCK(mp); > - VFS_RECLAIM_LOWERVP(ump, vp); > + switch (event) { > + case VFS_NOTIFY_UPPER_RECLAIM: > + VFS_RECLAIM_LOWERVP(ump, vp); > + break; > + case VFS_NOTIFY_UPPER_UNLINK: > + VFS_UNLINK_LOWERVP(ump, vp); > + break; > + default: > + KASSERT(0, ("invalid event %d", event)); > + break; > + } > MNT_ILOCK(mp); > ump = TAILQ_NEXT(mmp, mnt_upper_link); > TAILQ_REMOVE(&mp->mnt_uppers, mmp, mnt_upper_link); > @@ -2783,7 +2794,7 @@ vgonel(struct vnode *vp) > active = vp->v_usecount; > oweinact = (vp->v_iflag & VI_OWEINACT); > VI_UNLOCK(vp); > - vgonel_reclaim_lowervp(vp); > + vfs_notify_upper(vp, VFS_NOTIFY_UPPER_RECLAIM); > > /* > * Clean out any buffers associated with the vnode. > diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c > index 29cb7bd..a004ea0 100644 > --- a/sys/kern/vfs_syscalls.c > +++ b/sys/kern/vfs_syscalls.c > @@ -1846,6 +1846,7 @@ restart: > if (error) > goto out; > #endif > + vfs_notify_upper(vp, VFS_NOTIFY_UPPER_UNLINK); > error = VOP_REMOVE(nd.ni_dvp, vp, &nd.ni_cnd); > #ifdef MAC > out: > @@ -3825,6 +3826,7 @@ restart: > return (error); > goto restart; > } > + vfs_notify_upper(vp, VFS_NOTIFY_UPPER_UNLINK); > error = VOP_RMDIR(nd.ni_dvp, nd.ni_vp, &nd.ni_cnd); > vn_finished_write(mp); > out: > diff --git a/sys/sys/mount.h b/sys/sys/mount.h > index a9c86f6..a953dae 100644 > --- a/sys/sys/mount.h > +++ b/sys/sys/mount.h > @@ -608,7 +608,7 @@ typedef int vfs_mount_t(struct mount *mp); > typedef int vfs_sysctl_t(struct mount *mp, fsctlop_t op, > struct sysctl_req *req); > typedef void vfs_susp_clean_t(struct mount *mp); > -typedef void vfs_reclaim_lowervp_t(struct mount *mp, struct vnode > *lowervp); +typedef void vfs_notify_lowervp_t(struct mount *mp, struct > vnode *lowervp); > struct vfsops { > vfs_mount_t *vfs_mount; > @@ -626,7 +626,8 @@ struct vfsops { > vfs_extattrctl_t *vfs_extattrctl; > vfs_sysctl_t *vfs_sysctl; > vfs_susp_clean_t *vfs_susp_clean; > - vfs_reclaim_lowervp_t *vfs_reclaim_lowervp; > + vfs_notify_lowervp_t *vfs_reclaim_lowervp; > + vfs_notify_lowervp_t *vfs_unlink_lowervp; > }; > > vfs_statfs_t __vfs_statfs; > @@ -747,6 +748,14 @@ vfs_statfs_t __vfs_statfs; > } \ > } while (0) > > +#define VFS_UNLINK_LOWERVP(MP, VP) do { \ > + if (*(MP)->mnt_op->vfs_unlink_lowervp != NULL) { \ > + VFS_PROLOGUE(MP); \ > + (*(MP)->mnt_op->vfs_unlink_lowervp)((MP), (VP)); \ > + VFS_EPILOGUE(MP); \ > + } \ > +} while (0) > + > #define VFS_KNOTE_LOCKED(vp, hint) do \ > { \ > if (((vp)->v_vflag & VV_NOKNOTE) == 0) \ > @@ -759,6 +768,9 @@ vfs_statfs_t __vfs_statfs; > VN_KNOTE((vp), (hint), 0); \ > } while (0) > > +#define VFS_NOTIFY_UPPER_RECLAIM 1 > +#define VFS_NOTIFY_UPPER_UNLINK 2 > + > #include > > /* > @@ -840,6 +852,7 @@ int vfs_modevent(module_t, int, void *); > void vfs_mount_error(struct mount *, const char *, ...); > void vfs_mountroot(void); /* mount our root filesystem */ > void vfs_mountedfrom(struct mount *, const char *from); > +void vfs_notify_upper(struct vnode *, int); > void vfs_oexport_conv(const struct oexport_args *oexp, > struct export_args *exp); > void vfs_ref(struct mount *); I assume this is CURRENT? Tried on STABLE but got this: cc1: warnings being treated as errors /usr/src/sys/kern/vfs_subr.c: In function 'vfs_notify_upper': /usr/src/sys/kern/vfs_subr.c:2801: warning: implicit declaration of function 'VFS_PROLOGUE' /usr/src/sys/kern/vfs_subr.c:2801: warning: nested extern declaration of 'VFS_PROLOGUE' [-Wnested-externs] /usr/src/sys/kern/vfs_subr.c:2801: warning: implicit declaration of function 'VFS_EPILOGUE' /usr/src/sys/kern/vfs_subr.c:2801: warning: nested extern declaration of 'VFS_EPILOGUE' [-Wnested-externs] *** [vfs_subr.o] Error code 1 /glz From owner-freebsd-stable@FreeBSD.ORG Thu May 9 12:31:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4EDF5765; Thu, 9 May 2013 12:31:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B9B8B38B; Thu, 9 May 2013 12:30:59 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r49CUuZP074069; Thu, 9 May 2013 15:30:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r49CUuZP074069 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r49CUu9m074065; Thu, 9 May 2013 15:30:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 May 2013 15:30:56 +0300 From: Konstantin Belousov To: Goran Lowkrantz Subject: Re: Nullfs leaks i-nodes Message-ID: <20130509123056.GS3047@kib.kiev.ua> References: <20130508091317.GJ3047@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uH+S4n7ozliZSft0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: pho@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 12:31:00 -0000 --uH+S4n7ozliZSft0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 09, 2013 at 02:11:44PM +0200, Goran Lowkrantz wrote: > I assume this is CURRENT? Tried on STABLE but got this: > cc1: warnings being treated as errors > /usr/src/sys/kern/vfs_subr.c: In function 'vfs_notify_upper': > /usr/src/sys/kern/vfs_subr.c:2801: warning: implicit declaration of=20 > function 'VFS_PROLOGUE' > /usr/src/sys/kern/vfs_subr.c:2801: warning: nested extern declaration of= =20 > 'VFS_PROLOGUE' [-Wnested-externs] > /usr/src/sys/kern/vfs_subr.c:2801: warning: implicit declaration of=20 > function 'VFS_EPILOGUE' > /usr/src/sys/kern/vfs_subr.c:2801: warning: nested extern declaration of= =20 > 'VFS_EPILOGUE' [-Wnested-externs] > *** [vfs_subr.o] Error code 1 Yes, the patch is for CURRENT. You can simply remove the VFS_PROLOGUE and VFS_EPILOGUE lines from the patch if applying on stable. Not sure whether it needs more trivial adjustments there. --uH+S4n7ozliZSft0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRi5b/AAoJEJDCuSvBvK1BUHYQAIiCK4j3DUFsX+ixGe8u3d0C akdnm/CWtypOsPa1J+yi6SWuk740Et30hmytU1dGSwyyzf184bkHvPb3g7ZwqGkP QMdExRS7kqDB+vQwQE6atZL8BUYb2jhCcb5RQliUK0m3dTVG420KoUm4pWv56wLc tzzW9yIVxtKv3s1LiF6nKJ+K5T7VHFu/2wzskpaTSbr/s0IfqylPQg1diRZ72UqP slpPV3YJkA5IlfzTm7GtIRWOypqUnZnNOB1/5isb6/RYZO0yhE5J76TjmKWEff3c 9Hjhhu994XxIR2TzGS/bqpoQzWIG60z4aRsuPnlzFHf4CmuinKvAJrFJprkh3GDr +kwIbm1Cm7fBSdj21KHYynlOSlMLf5GYJxsPTmHIE/hSER0TfVtRG9qaM75ytI9m ucxwMDsffP6Wa6UL15MX7RmY4lEHQCpfK08k8ROi3Re/E3ZGicNsMSTUCSR759vH unEmkrZBoMp5GvCRhoM/5Wi1cT33oeUNXHhP63bHypaErJ+2JMc9rSuOzKVbqGMR E0Z5oRqb1AfWal1Y0+6eSj7P5aXLXk6QYvsF1yNj6FQ/eSwOXklR++IfSQSmIlmA h/qghbxHDSNsijlFLqnNyTOn+YRqI0Ie5ssiZCiLUD7Ge17VKZ/0dFY9eOvNJXPT KBgyFwN2fggdMW2MeRZG =HVkw -----END PGP SIGNATURE----- --uH+S4n7ozliZSft0-- From owner-freebsd-stable@FreeBSD.ORG Thu May 9 13:18:51 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 33FF622D for ; Thu, 9 May 2013 13:18:51 +0000 (UTC) (envelope-from benjamindadams@gmail.com) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by mx1.freebsd.org (Postfix) with ESMTP id 032AE7CC for ; Thu, 9 May 2013 13:18:50 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id h1so3433173oag.11 for ; Thu, 09 May 2013 06:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=NwLSF+xAUy34eBfs9tqAqdHr3a57lwIKp/xWCXfvVLM=; b=plCmeQQvgtikcfAe0nNkENjitJObcglKR/FmQz85lls6t7LCd5XzHLzbpUTKzYnyKL 2AQMlTqPuaaGhfA0gW1LTdHdbO+aHo4eueYYG2NHg59Nor4/yZv5yuhoMrjbaHD8JtpR 7mNluzPr3EF0P9KKMSURiiLnj1XfEeibSSJY0uebCyabvL8nGXFU2b4XXLJyNMLo6Woi TzfmPDC9+w7c3IspDuIV/7itfO+Qdgcn0b9PdtXLEA3K2pEpslEmgmoEVsjn+jEMTHpy 43UNDvnnANru7OmDJK5CVCylFJRkixNH6gHovPan7BwyHDGlhAS2UZ6AuOqrxwKvFIrb 8ggQ== X-Received: by 10.60.17.234 with SMTP id r10mr4135247oed.58.1368105530230; Thu, 09 May 2013 06:18:50 -0700 (PDT) Received: from localhost.localdomain (cpe-67-249-53-57.twcny.res.rr.com. [67.249.53.57]) by mx.google.com with ESMTPSA id t3sm3090212obx.4.2013.05.09.06.18.49 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 09 May 2013 06:18:49 -0700 (PDT) Message-ID: <518BA237.3030700@gmail.com> Date: Thu, 09 May 2013 09:18:47 -0400 From: Benjamin Adams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: recommended memory for zfs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 13:18:51 -0000 Hello zfs question about memory. I heard zfs is very ram hungry. Service looking to run: - nginx - postgres - php-fpm - python I have a machine with two quad core cpus but only 4 G Memory I'm looking to buy more ram now. What would be the recommend amount of memory for zfs across 6 drives on this setup? Also can 9.1 now boot to zfs from the installer? (no tricks for post install) Thanks Ben From owner-freebsd-stable@FreeBSD.ORG Thu May 9 13:27:27 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D06523B0; Thu, 9 May 2013 13:27:27 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [199.192.164.235]) by mx1.freebsd.org (Postfix) with ESMTP id B2EAF818; Thu, 9 May 2013 13:27:27 +0000 (UTC) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by m2.gritton.org (8.14.5/8.14.5) with ESMTP id r49DRJeg012252; Thu, 9 May 2013 07:27:20 -0600 (MDT) (envelope-from jamie@FreeBSD.org) Message-ID: <518BA433.6050605@FreeBSD.org> Date: Thu, 09 May 2013 07:27:15 -0600 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120126 Thunderbird/9.0 MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz>, Harald Schmalzbauer , freebsd-jail@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: new jail(8) ignoring devfs_ruleset? References: <511E61F5.1000805@omnilan.de> <511EC759.4060704@FreeBSD.org> <5121EC52.5040502@omnilan.de> <20130219212430.GA92116@felucia.tataz.chchile.org> <514B9EF6.3000607@quip.cz> <514BA14F.3090609@FreeBSD.org> <514BA3D9.5010901@quip.cz> <514BAA01.20402@FreeBSD.org> <20130509091738.GC4437@caravan.chchile.org> In-Reply-To: <20130509091738.GC4437@caravan.chchile.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 13:27:27 -0000 On 05/09/13 03:17, Jeremie Le Hen wrote: > On Thu, Mar 21, 2013 at 06:46:57PM -0600, Jamie Gritton wrote: >> >> It's not fixed anywhere yet - it sometimes works in current, and >> sometimes doesn't. I've been meaning to patch it up, but it the problem >> is what I think it is, the patching up is a pretty big operation. >> >> It doesn't mean you can't use jails with devfs in 9.1, just that you >> can't use them with jail.conf. The old jail rc file that's all >> shell-based is still the official jail startup method, and that one >> still works. So existing systems will still work as expected, hence no >> errata. > > Shouldn't we warn the user about that in the manpage though? Well really we ought to fix it. I guess the man page could have something in the meantime, about an assumption that when you specify a devfs ruleset, that the ruleset in question must actually exist at the time. - Jamie From owner-freebsd-stable@FreeBSD.ORG Thu May 9 13:52:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EFCFD8AE for ; Thu, 9 May 2013 13:52:39 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 7E02D916 for ; Thu, 9 May 2013 13:52:39 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id fl20so2871286lab.9 for ; Thu, 09 May 2013 06:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7GDitFT8aT7KJ6kzKHeAFfxA59bmiz09qAeWmyXKokk=; b=J93cKsYrzEjeHEsW78CDjAcl+dQh3jT/+DhfstnIXPGR4BR9Eb/ka27mjUuMn+Hz0w siuguO2Ovs8tG8T5mKa0xycjeDEFarLgeEfX0NNXAKMBDqvaVM16JvX5tk902L1+nUaI u+KefF8UsRP9pzyqEyrraniwyqH8voMZcvNXYIJUkuD8YS0vsgBEvz5CkcMwqfa8nlcq gMviyHTO82pK/atAIpqtZgsoApxbBF/MnuSVK4TCVb/62tYuMbybVnCoSINEOV+g+KeL 3CJceMXV0PEVigouqKPDSudQnV1scVsRC4D4ztIjNzY3zpjJ7joWFi+Vgs0ZtvyZTJXp StcQ== MIME-Version: 1.0 X-Received: by 10.152.21.106 with SMTP id u10mr5466847lae.11.1368107558359; Thu, 09 May 2013 06:52:38 -0700 (PDT) Received: by 10.112.202.137 with HTTP; Thu, 9 May 2013 06:52:38 -0700 (PDT) In-Reply-To: <518BA237.3030700@gmail.com> References: <518BA237.3030700@gmail.com> Date: Thu, 9 May 2013 14:52:38 +0100 Message-ID: Subject: Re: recommended memory for zfs From: Tom Evans To: Benjamin Adams Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 13:52:40 -0000 On Thu, May 9, 2013 at 2:18 PM, Benjamin Adams wrote: > Hello zfs question about memory. > I heard zfs is very ram hungry. > Service looking to run: > - nginx > - postgres > - php-fpm > - python > > I have a machine with two quad core cpus but only 4 G Memory > > I'm looking to buy more ram now. > What would be the recommend amount of memory for zfs across 6 drives on this > setup? > There is no right answer to this question. ZFS does not use a lot of RAM, but it will use as much as you allow as cache (in the ARC). How much data is your working set? How much of your working set do you need to keep in cache? You need that much memory (plus whatever to run your applications). > > Also can 9.1 now boot to zfs from the installer? > (no tricks for post install) > Can you clarify? The installer still cannot setup zfs pools, you must do so manually (but then can return to the installer). Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Thu May 9 14:13:18 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 44087BDE for ; Thu, 9 May 2013 14:13:18 +0000 (UTC) (envelope-from jim@ohlste.in) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by mx1.freebsd.org (Postfix) with ESMTP id 04D089FD for ; Thu, 9 May 2013 14:13:17 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id f11so1681062qae.5 for ; Thu, 09 May 2013 07:13:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type:x-gm-message-state; bh=ohzi6ht+IkTnHXEq1RQSeegzuDKQkV+GOj4e9eYtsuY=; b=j6dwCHG6mwFQw7ljqTu8l0uYUiVViFexD8+sMJCP2lCsmwFHZ8lc+uHXB+Ls/4qsYt Llb/IgvYyy7KYED/oJ1JgynKR4uBZL5QBVdaFNgBcAbLbRni1SbA2yDu4FAiqy1BXBci F3KqaGzwx6RgpjFMmbYzmRsxKU43+d6FFHNSuh9BO9rucxJ1lzyd9dAH7bq66yHJYPOX 5CWLfg6076e4jKADpiEb6ygkgWWY8ytarMKaphseBFKdQNHqrANVMAa46/lH9w7FIdZ6 BKsLDvAqcCYdeFiTlZ0NPpqCcKDzv/g6jFcjTUBf/QkoERxylGwHdfwT/gopW6iFQXZM laCg== X-Received: by 10.49.96.104 with SMTP id dr8mr9752286qeb.43.1368108797513; Thu, 09 May 2013 07:13:17 -0700 (PDT) Received: from [192.168.1.10] (pool-74-110-99-189.nrflva.fios.verizon.net. [74.110.99.189]) by mx.google.com with ESMTPSA id i5sm3543561qaf.0.2013.05.09.07.13.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 07:13:16 -0700 (PDT) Message-ID: <518BAEFB.5090204@ohlste.in> Date: Thu, 09 May 2013 10:13:15 -0400 From: Jim Ohlstein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Apparent regression in r250359 References: <518A880C.3090906@ohlste.in> <20130509053055.GM3047@kib.kiev.ua> In-Reply-To: <20130509053055.GM3047@kib.kiev.ua> Content-Type: multipart/mixed; boundary="------------040300000003010303010409" X-Gm-Message-State: ALoCoQkMYAKfzlCXvJEzUrgYX9H610aDngqrdd4TREPZcqp8TcLzpTXeAZZZ6pYKCg88nRHRpWWA Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 14:13:18 -0000 This is a multi-part message in MIME format. --------------040300000003010303010409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/09/13 01:30, Konstantin Belousov wrote: > On Wed, May 08, 2013 at 01:14:52PM -0400, Jim Ohlstein wrote: >> Hello, >> >> I upgraded my (custom) kernel earlier and found that multiple daemons >> (cups, hal, syslog, ntpd, csh) crashed and dumped cores at or shortly >> after boot. >> >> The error I saw several times on the console was: >> >> set_fpcontext err 22 >> >> I recompiled using the GENERIC kernel and saw the same error. >> >> >> The error appears to be in the changes made in r250359 in fpu.c, as >> r250358 boots as expected. >> > Quite weird, and the most troublesome part is that I cannot reproduce > it locally. As a temporal workaround, you could set 'hw.use_xsave=0' > at the loader prompt. The instructions below for kgdb assume that > you did not applied this workaround. > > What CPU do you have ? Please show me the verbose dmesg of the boot. # sysctl hw.model hw.model: AMD FX(tm)-8350 Eight-Core Processor dmesg to follow privately. Recompiling the kernel with a large enough 'MSGBUF_SIZE' to handle the output. > > Next, please do the following: > run 'kgdb /boot/kernel/kernel /dev/mem', and from the kgdb prompt, > do 'x/1xw use_xsave' and 'x/1xg xsave_mask'. Attached > > Also, see below. > >> # uname -a >> FreeBSD lucid-insanity 9.1-STABLE FreeBSD 9.1-STABLE #3 r250358: Wed May >> 8 11:56:43 EDT 2013 >> root@lucid-insanity:/usr/obj/usr/src/sys/GENERIC amd64 >> >> >> World and kernel are built with clang 3.2. >> >> r250359 produces the error and core dumps: >> >> Sample gdb output: >> >> # gdb cupsd cupsd.core >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "amd64-marcel-freebsd"...(no debugging >> symbols found)... >> Core was generated by `cupsd'. >> Program terminated with signal 10, Bus error. >> Reading symbols from /usr/local/lib/libcupsmime.so.1...(no debugging >> symbols found)...done. >> Loaded symbols for /usr/local/lib/libcupsmime.so.1 >> Reading symbols from /lib/libz.so.6...done. >> Loaded symbols for /lib/libz.so.6 >> Reading symbols from /usr/lib/libssl.so.6...done. >> Loaded symbols for /usr/lib/libssl.so.6 >> Reading symbols from /lib/libcrypto.so.6...done. >> Loaded symbols for /lib/libcrypto.so.6 >> Reading symbols from /usr/local/lib/libpaper.so.2...done. >> Loaded symbols for /usr/local/lib/libpaper.so.2 >> Reading symbols from /usr/local/lib/libcups.so.2...done. >> Loaded symbols for /usr/local/lib/libcups.so.2 >> Reading symbols from /lib/libcrypt.so.5...done. >> Loaded symbols for /lib/libcrypt.so.5 >> Reading symbols from /lib/libm.so.5...done. >> Loaded symbols for /lib/libm.so.5 >> Reading symbols from /usr/local/lib/libiconv.so.3...done. >> Loaded symbols for /usr/local/lib/libiconv.so.3 >> Reading symbols from /lib/libthr.so.3...done. >> Loaded symbols for /lib/libthr.so.3 >> Reading symbols from /lib/libc.so.7...done. >> Loaded symbols for /lib/libc.so.7 >> Reading symbols from /libexec/ld-elf.so.1...done. >> Loaded symbols for /libexec/ld-elf.so.1 >> #0 0x00007ffffffff1e3 in ?? () >> [New Thread 802407400 (LWP 100450/cupsd)] >> (gdb) >> >> # gdb csh csh.core >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "amd64-marcel-freebsd"... >> Core was generated by `csh'. >> Program terminated with signal 10, Bus error. >> Reading symbols from /lib/libncurses.so.8...done. >> Loaded symbols for /lib/libncurses.so.8 >> Reading symbols from /lib/libcrypt.so.5...done. >> Loaded symbols for /lib/libcrypt.so.5 >> Reading symbols from /lib/libc.so.7...done. >> Loaded symbols for /lib/libc.so.7 >> Reading symbols from /usr/local/lib/libiconv.so...done. >> Loaded symbols for /usr/local/lib/libiconv.so >> Reading symbols from /libexec/ld-elf.so.1...done. >> Loaded symbols for /libexec/ld-elf.so.1 >> #0 0x00007ffffffff1e3 in ?? () >> (gdb) > From the core dump above, please do > 'info registers' > then take the value from %rdi and do > 'x/2xg $rdi+0x300', > then take the first value printed (let denote it as XSAVEADDR) and do > 'x/8xg XSAVEADDR'. # gdb csh csh.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `csh'. Program terminated with signal 10, Bus error. Reading symbols from /lib/libncurses.so.8...done. Loaded symbols for /lib/libncurses.so.8 Reading symbols from /lib/libcrypt.so.5...done. Loaded symbols for /lib/libcrypt.so.5 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/libiconv.so...done. Loaded symbols for /usr/local/lib/libiconv.so Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x00007ffffffff1e3 in ?? () (gdb) info registers rax 0x16 22 rbx 0x101 257 rcx 0x7ffffffff1e3 140737488351715 rdx 0x7fffffffc980 140737488341376 rsi 0x1 1 rdi 0x7fffffffc980 140737488341376 rbp 0x7fffffffd000 0x7fffffffd000 rsp 0x7fffffffc968 0x7fffffffc968 r8 0x0 0 r9 0x19 25 r10 0x50 80 r11 0x203 515 r12 0x801460400 34381104128 r13 0x0 0 r14 0x7fffffffcfb0 140737488342960 r15 0x7fffffffcfd0 140737488342992 rip 0x7ffffffff1e3 0x7ffffffff1e3 eflags 0x10203 66051 cs 0x43 67 ss 0x3b 59 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) x/2xg 0x7fffffffc980+0x300 0x7fffffffcc80: 0x00007fffffffcd40 0x00000000000001c0 (gdb) x/8xg 0x00007fffffffcd40 0x7fffffffcd40: 0xffffffffffffffff 0x0000000000000000 0x7fffffffcd50: 0x0000000000000000 0x0000000000000000 0x7fffffffcd60: 0x0000000000000000 0x0000000000000000 0x7fffffffcd70: 0x0000000000000000 0x0000000000000000 (gdb) > >> >> I can produce more if anyone is interested. >> -- Jim Ohlstein --------------040300000003010303010409 Content-Type: text/plain; charset=us-ascii; name="kgdb.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kgdb.txt" # uname -a FreeBSD lucid-insanity 9.1-STABLE FreeBSD 9.1-STABLE #4 r250359: Wed May 8 12:29:28 EDT 2013 root@lucid-insanity:/usr/obj/usr/src/sys/GENERIC amd64 # # kgdb /boot/kernel/kernel /dev/mem GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: <6>pid 2016 (syslogd), uid 0: exited on signal 10 (core dumped) ahcich11: SNTF 0x0001 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko #0 sched_switch (td=0xffffffff81384300, newtd=0xfffffe000d66f920, flags=) at /usr/src/sys/kern/sched_ule.c:1920 1920 cpuid = PCPU_GET(cpuid); (kgdb) x/1xw use_xsave 0x1: Error accessing memory address 0x1: Bad address. (kgdb) x/1xg xsave_mask 0x4000000000000007: Error accessing memory address 0x4000000000000007: Bad address. (kgdb) quit # --------------040300000003010303010409-- From owner-freebsd-stable@FreeBSD.ORG Thu May 9 14:26:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D46A9D98 for ; Thu, 9 May 2013 14:26:00 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB21A69 for ; Thu, 9 May 2013 14:26:00 +0000 (UTC) Received: from [192.168.0.23] (4ab54-4-88-163-248-31.fbx.proxad.net [88.163.248.31]) by peterschmitt.fr (Postfix) with ESMTPSA id 9337871D2 for ; Thu, 9 May 2013 16:25:53 +0200 (CEST) Message-ID: <518BB1ED.9060309@peterschmitt.fr> Date: Thu, 09 May 2013 16:25:49 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: recommended memory for zfs References: <518BA237.3030700@gmail.com> In-Reply-To: <518BA237.3030700@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2TVFFWEGVSJRCBTRKOXKH" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 14:26:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2TVFFWEGVSJRCBTRKOXKH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le 09/05/2013 15:18, Benjamin Adams a =E9crit : > Hello zfs question about memory. > I heard zfs is very ram hungry. > Service looking to run: > - nginx > - postgres > - php-fpm > - python >=20 > I have a machine with two quad core cpus but only 4 G Memory >=20 > I'm looking to buy more ram now. > What would be the recommend amount of memory for zfs across 6 drives on= > this setup? >=20 >=20 > Also can 9.1 now boot to zfs from the installer? > (no tricks for post install) Without cache, footprint of ZFS is larger than any other filesystem but it is really very tiny (8Mio if my memory is good). I run my server on an Intel Atom with 2GB of RAM, with Apache22, PHP, MySQL database and ejabberd. If you want to get ZFS on your system at install time, there are many scripts on the Internet, and if you want you can take mine: http://projet.beastie.eu/?p=3Dfreebsd-zfs.git;a=3Dblob_plain;f=3Dzfs.sh;h= b=3DHEAD Hoping it will help you. --=20 Florent Peterschmitt +33 (0)6 64 33 97 92 florent@peterschmitt.fr ------------------------ O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ------enig2TVFFWEGVSJRCBTRKOXKH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRi7HwAAoJEMtO2Sol0IIm0u8H/17O/zebKxCMi2KCjZIvNGJ+ MlNRTUSIdztQbPSQRfry5H0s9WayIXevIMkbcBUM3fvjDXAxU4C+pNp4PsSpToG3 g71RAW/QdS+YnmwNdIt8AA4ChUHMazf6OXRPxHH++7f5f8iU4SWRevpVqcA62dkX 6WmVQXIcNNtbij9GV4XLpLuBys6chgxtp7YjimRPgsBRGvscNqZ20lqe6YGYBxRt iLU23bCQ55UaCLCFGqPMsiIDuqm8cnS52y8hRTIA8Pli8Obj6Qw9H+51YzXERp7q PRFVwcs8oaM11mXsaZiyF+c0ZdQ0zv+YDEGKfzEq6EzpzhD73l5B1YIZ4Ya4Usc= =fVvb -----END PGP SIGNATURE----- ------enig2TVFFWEGVSJRCBTRKOXKH-- From owner-freebsd-stable@FreeBSD.ORG Thu May 9 14:30:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 69459F4E for ; Thu, 9 May 2013 14:30:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D5C16AA1 for ; Thu, 9 May 2013 14:30:42 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r49EUcAD098519; Thu, 9 May 2013 17:30:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r49EUcAD098519 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r49EUcKx098518; Thu, 9 May 2013 17:30:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 May 2013 17:30:38 +0300 From: Konstantin Belousov To: Jim Ohlstein Subject: Re: Apparent regression in r250359 Message-ID: <20130509143038.GV3047@kib.kiev.ua> References: <518A880C.3090906@ohlste.in> <20130509053055.GM3047@kib.kiev.ua> <518BAEFB.5090204@ohlste.in> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LqgZP5keLUEdlDYR" Content-Disposition: inline In-Reply-To: <518BAEFB.5090204@ohlste.in> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 14:30:43 -0000 --LqgZP5keLUEdlDYR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, May 09, 2013 at 10:13:15AM -0400, Jim Ohlstein wrote: > # sysctl hw.model > hw.model: AMD FX(tm)-8350 Eight-Core Processor Ahh, so it seems that this is a CPU with the LWP. Please try the patch at the end of message. As another workaround, which does not disable AVX support, you could try loader tunable hw.xsave_mask=0x7. > #0 0x00007ffffffff1e3 in ?? () > (gdb) info registers > rax 0x16 22 > rbx 0x101 257 > rcx 0x7ffffffff1e3 140737488351715 > rdx 0x7fffffffc980 140737488341376 > rsi 0x1 1 > rdi 0x7fffffffc980 140737488341376 > rbp 0x7fffffffd000 0x7fffffffd000 > rsp 0x7fffffffc968 0x7fffffffc968 > r8 0x0 0 > r9 0x19 25 > r10 0x50 80 > r11 0x203 515 > r12 0x801460400 34381104128 > r13 0x0 0 > r14 0x7fffffffcfb0 140737488342960 > r15 0x7fffffffcfd0 140737488342992 > rip 0x7ffffffff1e3 0x7ffffffff1e3 > eflags 0x10203 66051 > cs 0x43 67 > ss 0x3b 59 > ds 0x0 0 > es 0x0 0 > fs 0x0 0 > gs 0x0 0 > (gdb) x/2xg 0x7fffffffc980+0x300 > 0x7fffffffcc80: 0x00007fffffffcd40 0x00000000000001c0 > (gdb) x/8xg 0x00007fffffffcd40 > 0x7fffffffcd40: 0xffffffffffffffff 0x0000000000000000 > 0x7fffffffcd50: 0x0000000000000000 0x0000000000000000 > 0x7fffffffcd60: 0x0000000000000000 0x0000000000000000 > 0x7fffffffcd70: 0x0000000000000000 0x0000000000000000 > (kgdb) x/1xw use_xsave > 0x1: Error accessing memory address 0x1: Bad address. > (kgdb) x/1xg xsave_mask > 0x4000000000000007: Error accessing memory address 0x4000000000000007: Bad address. diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c index de79baa..61ce94d 100644 --- a/sys/amd64/amd64/fpu.c +++ b/sys/amd64/amd64/fpu.c @@ -687,7 +687,7 @@ fpugetregs(struct thread *td) offsetof(struct xstate_hdr, xstate_bv)); max_ext_n = flsl(xsave_mask); for (i = 0; i < max_ext_n; i++) { - bit = 1 << i; + bit = 1ULL << i; if ((*xstate_bv & bit) != 0) continue; bcopy((char *)fpu_initialstate + --LqgZP5keLUEdlDYR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRi7MOAAoJEJDCuSvBvK1BM0EP/iWHYSQvKMpSECKu24cpLx4w LQxdbbOApdJ0rR10Cd95Gjrt1MoaXoEyM/UHreHTR96q1HVftl74eeo3aLKcujVi tcBQibdPyTII+FpEkKiVfk29zN1kbZX7bdZRadCJ85jhWNbB7USynvVQoeJWVWjP qn9O4GVYjDmvMzp0SVkyjklN4RCtzCMNwMRNyYVGXlw0/G+MB2vjnEQAajRX5d7K FP4B5YWlg7IspFPApTli3c0qG3FU5PzGP5jZAD9kRtcvIQ4dX2QgEH/jiynllI96 xCjxySbxkTKUH7uRbNdoAJnYMLKKmBk0LGF1bTgY0gqOLcwL+xoaLAkIGDPojQbX sMRtb2IwOA1Ee/o9OEC+iDx+21/yhKMOpeOeoqSaqMrdOrfn3cYHBRP65JTRHCWv DgGaNTT9cjkIp2i5P/6HGZv+P5PLV21Pf/Vw4w0lLk0Mt9IRB3IPlUDiR2QorK88 kkDYVCQhYkoITFBEb47RSZpGQIRDev42hg8VwXYoT/EwD78vyWJDhJKBmwUZESNs 3WZABtZRwYAq/VoWzSq3DbhqKUbhKe2bKLObYk4w/TvqTBJZGLs4bk7/zDPoC9lF 4Y+nRPMzYOMLPB93t2L9V1Tq7JDL63iBWNkZCIyD9sRjBsHElTojCKCUQhvXUHUk NHosNUtdGluM4Ak9XBM2 =scO1 -----END PGP SIGNATURE----- --LqgZP5keLUEdlDYR-- From owner-freebsd-stable@FreeBSD.ORG Thu May 9 15:06:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1FEB8647 for ; Thu, 9 May 2013 15:06:28 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id E0E5BCC0 for ; Thu, 9 May 2013 15:06:27 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [172.17.17.101]) by email2.allantgroup.com (8.14.5/8.14.5) with ESMTP id r49F0ToW079077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 May 2013 10:00:29 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.7/8.14.6) with ESMTP id r49F0THX004849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 May 2013 10:00:29 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.7/8.14.6/Submit) id r49F0TZd004848; Thu, 9 May 2013 10:00:29 -0500 (CDT) (envelope-from dan) Date: Thu, 9 May 2013 10:00:29 -0500 From: Dan Nelson To: Benjamin Adams Subject: Re: recommended memory for zfs Message-ID: <20130509150029.GA20797@dan.emsphone.com> References: <518BA237.3030700@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <518BA237.3030700@gmail.com> X-OS: FreeBSD 9.1-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.8 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (email2.allantgroup.com [172.17.19.78]); Thu, 09 May 2013 10:00:30 -0500 (CDT) X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on email2.allantgroup.com X-Scanned-By: MIMEDefang 2.73 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 15:06:28 -0000 In the last episode (May 09), Benjamin Adams said: > Hello zfs question about memory. > I heard zfs is very ram hungry. > Service looking to run: > - nginx > - postgres > - php-fpm > - python > > I have a machine with two quad core cpus but only 4 G Memory > > I'm looking to buy more ram now. > What would be the recommend amount of memory for zfs across 6 drives on > this setup? As much as is reasonable to purchase. Postgres would probably appreciate the memory more than ZFS. You can run ZFS on memory-limited machines (I've gone as far down as 256MB), but the critical part is running a 64-bit kernel. ZFS does a lot of kernel malloc/free operations, and address space fragmentation on a 32-bit system will eventually cause a panic when ZFS can't malloc a contiguous 128k chunk. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Thu May 9 15:42:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A1B09E42 for ; Thu, 9 May 2013 15:42:30 +0000 (UTC) (envelope-from jim@ohlste.in) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id 6351BE39 for ; Thu, 9 May 2013 15:42:30 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id a11so1711383qcx.21 for ; Thu, 09 May 2013 08:42:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=fGY8hlh6eD7BqH7HaA5iL9nYBSSQB68EtHsynzAaFCI=; b=V84ArTewIFRVY9G1D1TzI42SsGdbTvgljiPzplDhukehJuKk1hlUQs6I4O0iVXYA2e sZX18c7y+5j3YyYwIgyNPt+Kjr0txQk4tXnmx/x3ZZ630mqcpvm6UQ5OYYtqb/pT7CPA w96/faAVCBE/9yMucgZXT0CMGwU9IzFKYc/zJdV/pLhNEe0/L/+AV5px6E1e24B+EfX8 JdSFke5ejPuTDYmPjw0M6QLK9v8/ARgQwFe4J4W2pHzf6fjQCmqvmb5hRzk7ry7zt8t9 fLGHCADVgNrZbmh9H3W84xnTiriLkmotjxjBvG2AKnNrykRrTd4Hh0Zl4odPeyoRMa9O xwdQ== X-Received: by 10.229.122.6 with SMTP id j6mr3604885qcr.111.1368114149893; Thu, 09 May 2013 08:42:29 -0700 (PDT) Received: from [192.168.1.10] (pool-74-110-99-189.nrflva.fios.verizon.net. [74.110.99.189]) by mx.google.com with ESMTPSA id fq5sm3806866qab.2.2013.05.09.08.42.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 08:42:29 -0700 (PDT) Message-ID: <518BC3E4.1030104@ohlste.in> Date: Thu, 09 May 2013 11:42:28 -0400 From: Jim Ohlstein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Apparent regression in r250359 References: <518A880C.3090906@ohlste.in> <20130509053055.GM3047@kib.kiev.ua> <518BAEFB.5090204@ohlste.in> <20130509143038.GV3047@kib.kiev.ua> In-Reply-To: <20130509143038.GV3047@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmxz6SSBpeZQns6RbOLEpvhsFVb2ErI6i9lMHpO4tsEH9I4jMHUeXVh83GUwDttBdAXAl5Q Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 15:42:30 -0000 On 05/09/13 10:30, Konstantin Belousov wrote: > On Thu, May 09, 2013 at 10:13:15AM -0400, Jim Ohlstein wrote: >> # sysctl hw.model >> hw.model: AMD FX(tm)-8350 Eight-Core Processor > Ahh, so it seems that this is a CPU with the LWP. > Please try the patch at the end of message. Same error > > As another workaround, which does not disable AVX support, you > could try loader tunable hw.xsave_mask=0x7. This works > > diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c > index de79baa..61ce94d 100644 > --- a/sys/amd64/amd64/fpu.c > +++ b/sys/amd64/amd64/fpu.c > @@ -687,7 +687,7 @@ fpugetregs(struct thread *td) > offsetof(struct xstate_hdr, xstate_bv)); > max_ext_n = flsl(xsave_mask); > for (i = 0; i < max_ext_n; i++) { > - bit = 1 << i; > + bit = 1ULL << i; > if ((*xstate_bv & bit) != 0) > continue; > bcopy((char *)fpu_initialstate + > -- Jim Ohlstein From owner-freebsd-stable@FreeBSD.ORG Thu May 9 16:04:41 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D0F314CB for ; Thu, 9 May 2013 16:04:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 61697F3B for ; Thu, 9 May 2013 16:04:41 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r49G4XJZ017404; Thu, 9 May 2013 19:04:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r49G4XJZ017404 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r49G4XNt017403; Thu, 9 May 2013 19:04:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 May 2013 19:04:33 +0300 From: Konstantin Belousov To: Jim Ohlstein Subject: Re: Apparent regression in r250359 Message-ID: <20130509160433.GW3047@kib.kiev.ua> References: <518A880C.3090906@ohlste.in> <20130509053055.GM3047@kib.kiev.ua> <518BAEFB.5090204@ohlste.in> <20130509143038.GV3047@kib.kiev.ua> <518BC3E4.1030104@ohlste.in> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dokHZ4yyOnLbJiR1" Content-Disposition: inline In-Reply-To: <518BC3E4.1030104@ohlste.in> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 16:04:41 -0000 --dokHZ4yyOnLbJiR1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 09, 2013 at 11:42:28AM -0400, Jim Ohlstein wrote: > On 05/09/13 10:30, Konstantin Belousov wrote: > > On Thu, May 09, 2013 at 10:13:15AM -0400, Jim Ohlstein wrote: > >> # sysctl hw.model > >> hw.model: AMD FX(tm)-8350 Eight-Core Processor > > Ahh, so it seems that this is a CPU with the LWP. > > Please try the patch at the end of message. >=20 > Same error >=20 > > > > As another workaround, which does not disable AVX support, you > > could try loader tunable hw.xsave_mask=3D0x7. >=20 > This works Hm, I see another bug in the next line as well. Could you try this updated patch ? diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c index de79baa..9bc8a2f 100644 --- a/sys/amd64/amd64/fpu.c +++ b/sys/amd64/amd64/fpu.c @@ -687,8 +687,8 @@ fpugetregs(struct thread *td) offsetof(struct xstate_hdr, xstate_bv)); max_ext_n =3D flsl(xsave_mask); for (i =3D 0; i < max_ext_n; i++) { - bit =3D 1 << i; - if ((*xstate_bv & bit) !=3D 0) + bit =3D 1ULL << i; + if ((xsave_mask & bit) =3D=3D 0 || (*xstate_bv & bit) !=3D 0) continue; bcopy((char *)fpu_initialstate + xsave_area_desc[i].offset, --dokHZ4yyOnLbJiR1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRi8kQAAoJEJDCuSvBvK1BoBwP/0Anmhlt8ca8Cc4rANdT1rbg dIio0nBwgtzH5465H+ZV7rm0X0ofcpev2JhjWOH/RyDg/jaBgBeDEwffBZIT2qmV lLohV7yy/56fihCER6zVr8IR4OCmrR0+f2LyKCUnnfd2JbnKdwzVOYR8wqQzEhSP t9g0JkQJSe05PB2CG/uTUAYymixOiMlfGcVrzHnvSP/OGEqrcYBDsUqEZDqYdjCe 7nvFDzW+rl2dQeGu1ndEowWlkfwoJIOYetetVO7nQ7SXP2aqskVXUosJ1J3Qfghr vomiEHm23QWxjzNArC1NVj8IBk14D+/hGDhyaMvG9FFKC5Z7771l7yxWFlW7um+H f83+mN8oXLHOZDGHlFgemkVwjfDe2pWRKEwP9RelgA8uR1bE6e+wJrPLGwxH7BUE Md4byEwZIg0Gk2iVGPud9G8aUXIRdR7s7ru6v4+hW6ZUcNxxn/x2QYRopm+tNhlO xW5TbK6U1k9Xkacu+NL5IOgzqidopOMAKFsWKo1uQscHoUrngUmIjn9sse9KlaNh u6hCJ+bEeqvsCp9EcvMbEYLOD3rpuCG+dq/6taZ1kOIAOxylz7E2JqXclS2OMvri x+Xde/SdyMBqiKmJ7JRy2k5ficBTD5wZ4FPVTqJjSUGZfs1FfEC8CGX/iav7A0pf 1jdsUVZCRzlM7zITr5Gi =8AEX -----END PGP SIGNATURE----- --dokHZ4yyOnLbJiR1-- From owner-freebsd-stable@FreeBSD.ORG Thu May 9 17:17:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8E2D7795 for ; Thu, 9 May 2013 17:17:31 +0000 (UTC) (envelope-from jim@ohlste.in) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id 50C9936E for ; Thu, 9 May 2013 17:17:31 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id a11so1788593qcx.35 for ; Thu, 09 May 2013 10:17:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=uKmMTvtLjf/vL7ctedV0oCttek01T0yp9pn7ESDck10=; b=ahgN2OLLdPLZY1Y4e1KQ7LyjMDC8CzoL8LG+WiyC2WuhddstTXeKu6UXKXNdMISiGz B2xqCEVObT0M+O5qQGYXZ++Vr0BpECTIeoVSzIt0fdqNd8ZBu64U1kfcJkO37Yu+EUVo pOPLEYqNO8CigD/Kg/E1tRt6cT68cKiT9qhtswdq/QARrlYc+UWtNQwMZM35uQhFHB8y Af/BtcYO/XcRSnhwI2ebx3DKYnqCRo8MxyaohvApRLpLRAPTEgPcVRD5XqeywDcW4ZW4 wxT3PHnTYwk+oRI/UhqSFHo6D5XNH04PBNGC0iDaAo9c8gJVSqQmivoAzDNWij80mhb5 aFTQ== X-Received: by 10.49.82.45 with SMTP id f13mr10413107qey.53.1368119850778; Thu, 09 May 2013 10:17:30 -0700 (PDT) Received: from [192.168.1.10] (pool-74-110-99-189.nrflva.fios.verizon.net. [74.110.99.189]) by mx.google.com with ESMTPSA id c7sm3368515qel.2.2013.05.09.10.17.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 10:17:30 -0700 (PDT) Message-ID: <518BDA28.20603@ohlste.in> Date: Thu, 09 May 2013 13:17:28 -0400 From: Jim Ohlstein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Apparent regression in r250359 References: <518A880C.3090906@ohlste.in> <20130509053055.GM3047@kib.kiev.ua> <518BAEFB.5090204@ohlste.in> <20130509143038.GV3047@kib.kiev.ua> <518BC3E4.1030104@ohlste.in> <20130509160433.GW3047@kib.kiev.ua> In-Reply-To: <20130509160433.GW3047@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmh3AiHJ6hDGaxQRBa1us0AyJz/TtDRtLya06VshtUBqRZqD/6U/d+Cnc4kXDi+tfiBD2Yb Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 17:17:31 -0000 On 05/09/13 12:04, Konstantin Belousov wrote: > On Thu, May 09, 2013 at 11:42:28AM -0400, Jim Ohlstein wrote: >> On 05/09/13 10:30, Konstantin Belousov wrote: >>> On Thu, May 09, 2013 at 10:13:15AM -0400, Jim Ohlstein wrote: >>>> # sysctl hw.model >>>> hw.model: AMD FX(tm)-8350 Eight-Core Processor >>> Ahh, so it seems that this is a CPU with the LWP. >>> Please try the patch at the end of message. >> >> Same error >> >>> >>> As another workaround, which does not disable AVX support, you >>> could try loader tunable hw.xsave_mask=0x7. >> >> This works > > Hm, I see another bug in the next line as well. Could you try this > updated patch ? This does work. > > diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c > index de79baa..9bc8a2f 100644 > --- a/sys/amd64/amd64/fpu.c > +++ b/sys/amd64/amd64/fpu.c > @@ -687,8 +687,8 @@ fpugetregs(struct thread *td) > offsetof(struct xstate_hdr, xstate_bv)); > max_ext_n = flsl(xsave_mask); > for (i = 0; i < max_ext_n; i++) { > - bit = 1 << i; > - if ((*xstate_bv & bit) != 0) > + bit = 1ULL << i; > + if ((xsave_mask & bit) == 0 || (*xstate_bv & bit) != 0) > continue; > bcopy((char *)fpu_initialstate + > xsave_area_desc[i].offset, > -- Jim Ohlstein From owner-freebsd-stable@FreeBSD.ORG Thu May 9 17:28:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1F935763 for ; Thu, 9 May 2013 17:28:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8B75423F for ; Thu, 9 May 2013 17:28:23 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r49HSJcx034951; Thu, 9 May 2013 20:28:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r49HSJcx034951 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r49HSJnI034950; Thu, 9 May 2013 20:28:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 May 2013 20:28:19 +0300 From: Konstantin Belousov To: Jim Ohlstein Subject: Re: Apparent regression in r250359 Message-ID: <20130509172819.GX3047@kib.kiev.ua> References: <518A880C.3090906@ohlste.in> <20130509053055.GM3047@kib.kiev.ua> <518BAEFB.5090204@ohlste.in> <20130509143038.GV3047@kib.kiev.ua> <518BC3E4.1030104@ohlste.in> <20130509160433.GW3047@kib.kiev.ua> <518BDA28.20603@ohlste.in> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y28OXOviaZ2K0KfR" Content-Disposition: inline In-Reply-To: <518BDA28.20603@ohlste.in> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 17:28:24 -0000 --Y28OXOviaZ2K0KfR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 09, 2013 at 01:17:28PM -0400, Jim Ohlstein wrote: > On 05/09/13 12:04, Konstantin Belousov wrote: > > Hm, I see another bug in the next line as well. Could you try this > > updated patch ? >=20 > This does work. Committed to head, should be merged back to stable/9 in three days. --Y28OXOviaZ2K0KfR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRi9yzAAoJEJDCuSvBvK1Bd7EP/R1kjdSCMxVopEbXKhuJr3pA 6FolEWz4kNXOU62UXUji1lXVBJ3K7HqwgZJiK0GUoFhr0f0O0UudQhzABj/EkZho lQB2t0kDDvTdrYheTF22L+Uu7hYseRxRoVE55oBAub1+aAlPdBN8EMf+DSR6EJdv NvsF9MT5dJyQo4q5l7bjeErnzx+wUCirG7QPRaCTWt2hq2fzdwvzaFuzo4Lpesn1 NjumnGrMX3z9ETGjsa0kP/fWG1FIazmm0qVjiQpF/pIoYg2qX4oRqwwvZ+0N+nrD 63Vk2iJ5ZaYp+qYwnzFLLvCSJt941/zCY3tQeOWKcJqug6hvC9RAB23ta2BJucx6 kS0NbkMiKvxlr9zQYPwEy2q+xg6SFI6fS6y2gyZddR5uZ4atdsZH7zzhMtFaefaM OEJr/rjsrPKL/O3SmDMYvd4kQmjlhaZneJssysnvX1FzwkhmWWNegZID2bIM4fWp 6sHfYir6znPZVM0/86bk4t0/mm+imZiRjh3GCUYYaegW2O6SSTH4VZGUFXzTYgap deO5EzlQmnk620NIYN/GbhDrfqnwn646w/jEx/GWXB9rWCabwgSUNApW4ZJOcAFD S0pzguKvgDAUbSKTil8/sba23UJ7Dp6KxMi9NecN/Apc9mXc356KzytB+tdN8zos dNq/k9qHJTTgGOQK+Bhj =j3vX -----END PGP SIGNATURE----- --Y28OXOviaZ2K0KfR-- From owner-freebsd-stable@FreeBSD.ORG Fri May 10 00:53:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C97B1647 for ; Fri, 10 May 2013 00:53:36 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by mx1.freebsd.org (Postfix) with ESMTP id 63E47E81 for ; Fri, 10 May 2013 00:53:36 +0000 (UTC) Received: from ppp247-71.static.internode.on.net (HELO leader.local) ([203.122.247.71]) by ipmail05.adl6.internode.on.net with ESMTP; 10 May 2013 10:23:35 +0930 Message-ID: <518C450B.5070809@ShaneWare.Biz> Date: Fri, 10 May 2013 10:23:31 +0930 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Benjamin Adams Subject: Re: recommended memory for zfs References: <518BA237.3030700@gmail.com> In-Reply-To: <518BA237.3030700@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 00:53:36 -0000 On 09/05/2013 22:48, Benjamin Adams wrote: > Hello zfs question about memory. > I heard zfs is very ram hungry. > Service looking to run: > - nginx > - postgres > - php-fpm > - python > > I have a machine with two quad core cpus but only 4 G Memory > > I'm looking to buy more ram now. > What would be the recommend amount of memory for zfs across 6 drives on > this setup? > I believe I heard a calculation of 1GB cache per 1TB of disk. But basically zfs will use all free ram available if you access that much data from disk. You will want to set vfs.zfs.arc_max to allow enough ram for your apps to work in. If you consider the files for your website and the data you store you may find that you would never fill more than 500MB of cache. If you will be serving large media files that will easily use up the cache you could give them their own filesystem that only caches metadata - zfs set primarycache=metadata zroot/mediafiles From owner-freebsd-stable@FreeBSD.ORG Fri May 10 01:47:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6B1EFB64 for ; Fri, 10 May 2013 01:47:30 +0000 (UTC) (envelope-from benjamindadams@gmail.com) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id EC093FB8 for ; Fri, 10 May 2013 01:47:29 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id xk17so1492550obc.39 for ; Thu, 09 May 2013 18:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OKuANdhMRqaio12VN9X9OJ0/QNUCsB599akR6vpMmf8=; b=WoOOPUntn+4mgfrXAe1Pw4oiStFbBc54nWD48F/QeRYUQrWOWMF1o+GMtEaZG9zfXB LJdPCqhmPPwr9rIkc+zIp/d838XYbwFzh/u+V4HMDsTy4GmC4v7qD3AQ1fFpqZ3+eatb KDrardy4h4IUmKxLjEFiz2SvzKkqavTWreaa6Nf20mLYs7dMHCnWg2BjznpccKzOQ8CK 2LcriD/qWd0lAk/ZqC3viydaGk4DPgGpUD1Cuyj8yHXxPdl8AJKY8g9Q86QXu/xvOVee EHH8BAc8uRisGHPfHNCFhvwVUK7rpe3BhP2bOeim231EefBRTWq1dfKolgZqc/LVeL8s oMNg== X-Received: by 10.60.141.164 with SMTP id rp4mr5993010oeb.38.1368150449514; Thu, 09 May 2013 18:47:29 -0700 (PDT) Received: from localhost.localdomain (cpe-67-249-53-57.twcny.res.rr.com. [67.249.53.57]) by mx.google.com with ESMTPSA id ri8sm875900oeb.0.2013.05.09.18.47.28 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 09 May 2013 18:47:28 -0700 (PDT) Message-ID: <518C51AF.5050609@gmail.com> Date: Thu, 09 May 2013 21:47:27 -0400 From: Benjamin Adams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: Shane Ambler Subject: Re: recommended memory for zfs References: <518BA237.3030700@gmail.com> <518C450B.5070809@ShaneWare.Biz> In-Reply-To: <518C450B.5070809@ShaneWare.Biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 01:47:30 -0000 On 05/09/2013 08:53 PM, Shane Ambler wrote: > On 09/05/2013 22:48, Benjamin Adams wrote: >> Hello zfs question about memory. >> I heard zfs is very ram hungry. >> Service looking to run: >> - nginx >> - postgres >> - php-fpm >> - python >> >> I have a machine with two quad core cpus but only 4 G Memory >> >> I'm looking to buy more ram now. >> What would be the recommend amount of memory for zfs across 6 drives on >> this setup? >> > > I believe I heard a calculation of 1GB cache per 1TB of disk. But > basically zfs will use all free ram available if you access that much > data from disk. You will want to set vfs.zfs.arc_max to allow enough > ram for your apps to work in. > > If you consider the files for your website and the data you store you > may find that you would never fill more than 500MB of cache. > > If you will be serving large media files that will easily use up the > cache you could give them their own filesystem that only caches > metadata - zfs set primarycache=metadata zroot/mediafiles > > Thanks for all the replies Size of DB and HD's are: Current DB Size = 23 GB HD sizes = (6) 500 GB drives From owner-freebsd-stable@FreeBSD.ORG Fri May 10 02:06:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B81C4EAF for ; Fri, 10 May 2013 02:06:30 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by mx1.freebsd.org (Postfix) with ESMTP id 85916BA for ; Fri, 10 May 2013 02:06:30 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta03.emeryville.ca.mail.comcast.net with comcast id Zwp81l00A1afHeLA326Vgj; Fri, 10 May 2013 02:06:29 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta17.emeryville.ca.mail.comcast.net with comcast id a26U1l0181t3BNj8d26VFP; Fri, 10 May 2013 02:06:29 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A9CA173A33; Thu, 9 May 2013 19:06:28 -0700 (PDT) Date: Thu, 9 May 2013 19:06:28 -0700 From: Jeremy Chadwick To: Benjamin Adams Subject: Re: recommended memory for zfs Message-ID: <20130510020628.GA98750@icarus.home.lan> References: <518BA237.3030700@gmail.com> <518C450B.5070809@ShaneWare.Biz> <518C51AF.5050609@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <518C51AF.5050609@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368151589; bh=brVG9nB3TAqQ14qWwyaI/biVAdT1B5TsUI+sX6lRPfo=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=D4i/y1M2wD3XzRw+gaBvBIb7S1UgOq41zvvTMe5r7TUBzqOzSWEYhD/nLV1mUeB7C 3SZLfE4tpArW1SmRdA3X4VuPEm9oDaX9ZRLWAZ1SXUQyAj26+0H6ybaXKwPOpd2f1V E8hgeedpQ199WyTkT4p4QRJ8edEjXecP+3FKMvlVDKWyMstzgGoWhZQKHA+gFCXZLT pkomeb+vBwyUzjwKwXR0gaYbDqI41DPwnxwt5xdS5anGxqHg19eDofopttsr40dr60 LpH4cRV6Nm0B0R2DR7KxpsHWhCwgf7yf20Y+5QKFRb08KBpcDwcMlWWYnxnQxVjMVA E84I1ZSGiuSiw== Cc: freebsd-stable@freebsd.org, Shane Ambler X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 02:06:30 -0000 On Thu, May 09, 2013 at 09:47:27PM -0400, Benjamin Adams wrote: > On 05/09/2013 08:53 PM, Shane Ambler wrote: > >On 09/05/2013 22:48, Benjamin Adams wrote: > >>Hello zfs question about memory. > >>I heard zfs is very ram hungry. > >>Service looking to run: > >>- nginx > >>- postgres > >>- php-fpm > >>- python > >> > >>I have a machine with two quad core cpus but only 4 G Memory > >> > >>I'm looking to buy more ram now. > >>What would be the recommend amount of memory for zfs across 6 drives on > >>this setup? > >> > > > >I believe I heard a calculation of 1GB cache per 1TB of disk. But > >basically zfs will use all free ram available if you access that > >much data from disk. You will want to set vfs.zfs.arc_max to allow > >enough ram for your apps to work in. > > > >If you consider the files for your website and the data you store > >you may find that you would never fill more than 500MB of cache. > > > >If you will be serving large media files that will easily use up > >the cache you could give them their own filesystem that only > >caches metadata - zfs set primarycache=metadata zroot/mediafiles > > > > > Thanks for all the replies Size of DB and HD's are: > > Current DB Size = 23 GB > HD sizes = (6) 500 GB drives Nobody is going to be able to give you a precise/accurate recommendation given the lack of detail provided, I'm sorry to say. What's the RES size of nginx (all processes combined)? What's the RES size of postgres (same)? Do you have PHP scripts that "run amok" for long periods of time and take up lots of RAM? Same with python? How many concurrent visitors and what sort of content are you hosting? Do you maintain/write your own PHP/Python code or are you using some crap like Wordpress? This is just a **small** list of questions -- and what may come as a shock is that I do not expect you to provide answers to any of them. They are questions that you should, for yourself, attempt to answer and work out what you need from there ("teach a man to fish" and all that). The advice of "1GB of RAM per 1TB of disk space" is absolute nonsense on numerous levels -- whoever gave this advice to Shane either has no understanding of how filesystems/ZFS works, or does but chose to simplify to the point where they're providing half-ass information. There is no direct, or even indirect, correlation between disk capacity and ZFS ARC size -- what matter is your "working set" (to quote Tom). You need to have some idea of how much disk I/O you're doing, and what type of I/O (sequential or random). If you want my general advice, Benjamin, it's this: get yourself a system with *minimum* 8GB of RAM but has the physical possibility of supporting more (and only add more RAM when/if you know you need it); do not bother with ZFS on a system with 4GB. Run amd64, not i386 (I don't recommend bothering with ZFS on i386 -- I am not going to get into a discussion about this either). Run stable/9, not 9.1-RELEASE. Avoid compression and dedup. And test disk failures as well (don't get caught with your pants down later). The above advice comes from someone who did hosting (web/ssh/etc.) for almost 20 years with KISS principle applied at all levels. YMMV though, depending on what all you're doing/what you truly need. Good luck. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri May 10 02:12:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BA5E61C6 for ; Fri, 10 May 2013 02:12:53 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 5614B110 for ; Fri, 10 May 2013 02:12:53 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id n12so3507341wgh.1 for ; Thu, 09 May 2013 19:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XKDEGhgGtBxlZ0JVn8gyOLKC7HlQioYarLs2YwpMgNo=; b=qz7jjBRjmZKeQ0JaxpM0FtrirobmFifnrsFCIHSUUKOEjn3QgWSHkf0w1wSztsOXu2 MqvMKuP+zXR3lqs3SCAR/Lb3rnX75+ncLFyVhxe4JpHQ1AKph5sPPR2OKiibGii/asNJ 0hT2NyIQZK/axFkEei7j/AAsH4D1eqAPh0GuKF5BzZJyeG3bWj5QW9e6pivi9NGHxdZ2 2RQgcEmp8rDqwQnU34+Lwn+Sf1pjujx59hGtwoWUCz4p+y2mcgI7QS7/jZsyKkiyhQr+ G2cQf0hwtpWWHxcEV2JnXeDIgXOWb3Eemy6rdNmbHGjQfIAgq2CYxE8EtYMkCbH+Gj+H qH/g== MIME-Version: 1.0 X-Received: by 10.194.92.231 with SMTP id cp7mr21493108wjb.3.1368151972456; Thu, 09 May 2013 19:12:52 -0700 (PDT) Received: by 10.194.119.131 with HTTP; Thu, 9 May 2013 19:12:52 -0700 (PDT) In-Reply-To: <518C51AF.5050609@gmail.com> References: <518BA237.3030700@gmail.com> <518C450B.5070809@ShaneWare.Biz> <518C51AF.5050609@gmail.com> Date: Thu, 9 May 2013 21:12:52 -0500 Message-ID: Subject: Re: recommended memory for zfs From: Adam Vande More To: Benjamin Adams Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-stable@freebsd.org" , Shane Ambler X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 02:12:53 -0000 Probably the simplest answer is that you already have sufficient memory to run ZFS. As someone already mentioned you should use AMD64, not i386. If your setup isn't fast enough with tuning, add more if it's the bottleneck. On Thu, May 9, 2013 at 8:47 PM, Benjamin Adams wrote: > On 05/09/2013 08:53 PM, Shane Ambler wrote: >> >> On 09/05/2013 22:48, Benjamin Adams wrote: >>> >>> Hello zfs question about memory. >>> I heard zfs is very ram hungry. >>> Service looking to run: >>> - nginx >>> - postgres >>> - php-fpm >>> - python >>> >>> I have a machine with two quad core cpus but only 4 G Memory >>> >>> I'm looking to buy more ram now. >>> What would be the recommend amount of memory for zfs across 6 drives on >>> this setup? >>> >> >> I believe I heard a calculation of 1GB cache per 1TB of disk. But >> basically zfs will use all free ram available if you access that much data >> from disk. You will want to set vfs.zfs.arc_max to allow enough ram for your >> apps to work in. >> >> If you consider the files for your website and the data you store you may >> find that you would never fill more than 500MB of cache. >> >> If you will be serving large media files that will easily use up the cache >> you could give them their own filesystem that only caches metadata - zfs set >> primarycache=metadata zroot/mediafiles >> >> > Thanks for all the replies Size of DB and HD's are: > > Current DB Size = 23 GB > HD sizes = (6) 500 GB drives > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Fri May 10 02:14:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B3C093E0 for ; Fri, 10 May 2013 02:14:49 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id 4F09613F for ; Fri, 10 May 2013 02:14:49 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id t59so3588482wes.10 for ; Thu, 09 May 2013 19:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8QCqoXGPtw3XIh9eq4nSlmNZE/9BMC4kgFMAvDktSik=; b=SKR7G6bQdYLRUxObnETnTDTWzgtwe6UfTIvQ5af+XiU2laOEpDjiyT2rCwlV/vkvqo CPvwkMo9QEVJrWamO5KMIVgjGK0cCGL4ZjwVnLO4kQOqxbsZdiKxOdYAcwVduq/ScxxD Ly30WlLq5DhkJlAeB4zAYfRuT1DKn5VSphKRHxPgEYBtMMOgbpNj7D7v3KKkpETWaAfj xxYRueJzvp6JEkHURmNlkVUtn1mVu65b7YqTG/dWZT64Huh07uA4MY5ZhLNf6R6JSosQ nu2uuxESnZGYbJAP5OSb8jNV+/3jyN8BXPug2mn7T2BsYt8ImWUardF6ISj/nzc95skL 2gEA== MIME-Version: 1.0 X-Received: by 10.180.210.207 with SMTP id mw15mr724125wic.10.1368152088475; Thu, 09 May 2013 19:14:48 -0700 (PDT) Received: by 10.194.119.131 with HTTP; Thu, 9 May 2013 19:14:48 -0700 (PDT) In-Reply-To: <20130510020628.GA98750@icarus.home.lan> References: <518BA237.3030700@gmail.com> <518C450B.5070809@ShaneWare.Biz> <518C51AF.5050609@gmail.com> <20130510020628.GA98750@icarus.home.lan> Date: Thu, 9 May 2013 21:14:48 -0500 Message-ID: Subject: Re: recommended memory for zfs From: Adam Vande More To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Cc: Benjamin Adams , "freebsd-stable@freebsd.org" , Shane Ambler X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 02:14:49 -0000 On Thu, May 9, 2013 at 9:06 PM, Jeremy Chadwick wrote: > The advice of "1GB of RAM per 1TB of disk space" is absolute nonsense on > numerous levels -- whoever gave this advice to Shane either has no > understanding of how filesystems/ZFS works, or does but chose to > simplify to the point where they're providing half-ass information. IIRC, that used to be the guideline for memory requirements for dedup. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Fri May 10 02:18:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E017451A for ; Fri, 10 May 2013 02:18:44 +0000 (UTC) (envelope-from benjamindadams@gmail.com) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id B28CE169 for ; Fri, 10 May 2013 02:18:44 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id 9so6638271iec.8 for ; Thu, 09 May 2013 19:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Z4n52HTkN0OOuXpebMB9tBVQDFQ3cEGzG0cr5CpdvTs=; b=zIxxqmA+AYI0LaCE8vMi3U+iKJlBvcDsUpXe34E/QJswGE0rWStzZLGwpEgKAPVXMa RarAsWtlzzNmEdOuxuG+6Ooi21NEY5tv85ndTMpKlgrFihk7Wt1d8A7A9v/BU2lxBSRy 7KIyzyabYaoqQQqMb46B2FvpHEWHGrPjxqEApPZTBmmQEWXz7OFXSAtPxtG333VqkTo2 zu/z3DuVWmaDPccF6ZxTRjpt6TZg50P69lnUDWLPm6Tc3m4y4YzXgqWQ+rwSbs28LZu9 ly+D6XkK8pxsMgy+wd9r7qTVdEvYpTRp+O4nk2fRAprqg/MxExCezivZ6y22JAllP0iN ZmhA== X-Received: by 10.50.192.165 with SMTP id hh5mr449896igc.89.1368152324461; Thu, 09 May 2013 19:18:44 -0700 (PDT) Received: from localhost.localdomain (cpe-67-249-53-57.twcny.res.rr.com. [67.249.53.57]) by mx.google.com with ESMTPSA id o10sm1484933igh.2.2013.05.09.19.18.42 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 09 May 2013 19:18:43 -0700 (PDT) Message-ID: <518C5902.5050909@gmail.com> Date: Thu, 09 May 2013 22:18:42 -0400 From: Benjamin Adams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: recommended memory for zfs References: <518BA237.3030700@gmail.com> <518C450B.5070809@ShaneWare.Biz> <518C51AF.5050609@gmail.com> <20130510020628.GA98750@icarus.home.lan> In-Reply-To: <20130510020628.GA98750@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Shane Ambler X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 02:18:44 -0000 On 05/09/2013 10:06 PM, Jeremy Chadwick wrote: > On Thu, May 09, 2013 at 09:47:27PM -0400, Benjamin Adams wrote: >> On 05/09/2013 08:53 PM, Shane Ambler wrote: >>> On 09/05/2013 22:48, Benjamin Adams wrote: >>>> Hello zfs question about memory. >>>> I heard zfs is very ram hungry. >>>> Service looking to run: >>>> - nginx >>>> - postgres >>>> - php-fpm >>>> - python >>>> >>>> I have a machine with two quad core cpus but only 4 G Memory >>>> >>>> I'm looking to buy more ram now. >>>> What would be the recommend amount of memory for zfs across 6 drives on >>>> this setup? >>>> >>> I believe I heard a calculation of 1GB cache per 1TB of disk. But >>> basically zfs will use all free ram available if you access that >>> much data from disk. You will want to set vfs.zfs.arc_max to allow >>> enough ram for your apps to work in. >>> >>> If you consider the files for your website and the data you store >>> you may find that you would never fill more than 500MB of cache. >>> >>> If you will be serving large media files that will easily use up >>> the cache you could give them their own filesystem that only >>> caches metadata - zfs set primarycache=metadata zroot/mediafiles >>> >>> >> Thanks for all the replies Size of DB and HD's are: >> >> Current DB Size = 23 GB >> HD sizes = (6) 500 GB drives > Nobody is going to be able to give you a precise/accurate recommendation > given the lack of detail provided, I'm sorry to say. What's the RES > size of nginx (all processes combined)? What's the RES size of > postgres (same)? Do you have PHP scripts that "run amok" for long > periods of time and take up lots of RAM? Same with python? How many > concurrent visitors and what sort of content are you hosting? Do you > maintain/write your own PHP/Python code or are you using some crap like > Wordpress? > > This is just a **small** list of questions -- and what may come as a > shock is that I do not expect you to provide answers to any of them. > They are questions that you should, for yourself, attempt to answer and > work out what you need from there ("teach a man to fish" and all that). > > The advice of "1GB of RAM per 1TB of disk space" is absolute nonsense on > numerous levels -- whoever gave this advice to Shane either has no > understanding of how filesystems/ZFS works, or does but chose to > simplify to the point where they're providing half-ass information. > There is no direct, or even indirect, correlation between disk capacity > and ZFS ARC size -- what matter is your "working set" (to quote Tom). > You need to have some idea of how much disk I/O you're doing, and what > type of I/O (sequential or random). > > If you want my general advice, Benjamin, it's this: get yourself a > system with *minimum* 8GB of RAM but has the physical possibility of > supporting more (and only add more RAM when/if you know you need it); do > not bother with ZFS on a system with 4GB. Run amd64, not i386 (I don't > recommend bothering with ZFS on i386 -- I am not going to get into a > discussion about this either). Run stable/9, not 9.1-RELEASE. Avoid > compression and dedup. And test disk failures as well (don't get caught > with your pants down later). > > The above advice comes from someone who did hosting (web/ssh/etc.) for > almost 20 years with KISS principle applied at all levels. YMMV though, > depending on what all you're doing/what you truly need. > > Good luck. > Jeremy, Was just see if I should just get raid controller and more ram down the road. List of priorities. Main thing is I move from BSD when 9.0 came out. Was looking to see if zfs is included in the installer. Now. Sum up: upgrade ram to 16GB (not 64 like plained) and raid controller that supports level 5. Thanks Ben From owner-freebsd-stable@FreeBSD.ORG Fri May 10 03:32:35 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B6D6356B for ; Fri, 10 May 2013 03:32:35 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 7AED7699 for ; Fri, 10 May 2013 03:32:35 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id c11so2039594qcv.18 for ; Thu, 09 May 2013 20:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ErG8oGaittZXOH/JrRN1xP3tzKASyIJyGDj6cZbPpIE=; b=0f6NGry1hHz9eDvgnCJR0mjl1RyP9TkLWh1NgBtVYtoOld0+ajmr5/6+Tp0dxUFEMg 46WA3cPltOMKKLeryQoio3PTaXeWR4dqLJANVKbBViheNl8zFuI1etOP2loA4RU/MUBp nA9pGanHmJCksMmP+zaAKnxKctcc3NEG4QnwUYnXve/QtlNyzaVBWam9M/QndpDrJ5Og Q7/bqdqluRiT2hBFbriNX+IDGo2UmQJZeECCyrKwrJycHlX/Tyg/ZixhH4lqg20Fi0Rk gIdL4PDeMcBjY7eucOnxuqcVyhqwtg4g/ge9VzuCauI3jf8w/zEhk1UXEr7dUIWNFoZs KJ+w== MIME-Version: 1.0 X-Received: by 10.229.60.203 with SMTP id q11mr4102616qch.78.1368156755059; Thu, 09 May 2013 20:32:35 -0700 (PDT) Received: by 10.49.1.44 with HTTP; Thu, 9 May 2013 20:32:34 -0700 (PDT) Received: by 10.49.1.44 with HTTP; Thu, 9 May 2013 20:32:34 -0700 (PDT) In-Reply-To: References: <518BA237.3030700@gmail.com> <518C450B.5070809@ShaneWare.Biz> <518C51AF.5050609@gmail.com> <20130510020628.GA98750@icarus.home.lan> Date: Thu, 9 May 2013 20:32:34 -0700 Message-ID: Subject: Re: recommended memory for zfs From: Freddie Cash To: Adam Vande More Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Jeremy Chadwick , Benjamin Adams , FreeBSD Stable , Shane Ambler X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 03:32:35 -0000 And the "rule of thumb" for dedupe was approx 1 GB of ARC per unique TB of data in the pool (above and beyond your normal ARC requirements). Not 1 GB of RAM per TB of disk in the pool. Very big difference between the two. :) On 2013-05-09 7:14 PM, "Adam Vande More" wrote: > On Thu, May 9, 2013 at 9:06 PM, Jeremy Chadwick wrote: > > > The advice of "1GB of RAM per 1TB of disk space" is absolute nonsense on > > numerous levels -- whoever gave this advice to Shane either has no > > understanding of how filesystems/ZFS works, or does but chose to > > simplify to the point where they're providing half-ass information. > > IIRC, that used to be the guideline for memory requirements for dedup. > > > > -- > Adam Vande More > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri May 10 04:44:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E9472DD8; Fri, 10 May 2013 04:44:21 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nschwmtas03p.mx.bigpond.com (nschwmtas03p.mx.bigpond.com [61.9.189.143]) by mx1.freebsd.org (Postfix) with ESMTP id 32A3BC31; Fri, 10 May 2013 04:44:20 +0000 (UTC) Received: from nschwcmgw05p ([61.9.190.165]) by nschwmtas03p.mx.bigpond.com with ESMTP id <20130510044412.ONBI2008.nschwmtas03p.mx.bigpond.com@nschwcmgw05p>; Fri, 10 May 2013 04:44:12 +0000 Received: from hermes.heuristicsystems.com.au ([58.172.113.247]) by nschwcmgw05p with BigPond Outbound id a4k71l00N5LKYmq014kAxi; Fri, 10 May 2013 04:44:12 +0000 X-Authority-Analysis: v=2.0 cv=QJDqt33L c=1 sm=1 a=YibVxx38Z+cwdCKSMcELyg==:17 a=WLYBxzCSKxQA:10 a=k4yzAXmc-yEA:10 a=kj9zAlcOel0A:10 a=GHIR_BbyAAAA:8 a=stnWK5-ICawA:10 a=ZHhcw2d2FhgOiZKjQUsA:9 a=CjuIK1q_8ugA:10 a=YibVxx38Z+cwdCKSMcELyg==:117 Received: from black (black.hs [10.0.5.1]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id r4A4g7HG031424 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 May 2013 14:42:08 +1000 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne Geraghty" To: "'Jamie Gritton'" , "'Miroslav Lachman'" <000.fbsd@quip.cz>, "'Harald Schmalzbauer'" , , References: <511E61F5.1000805@omnilan.de> <511EC759.4060704@FreeBSD.org> <5121EC52.5040502@omnilan.de> <20130219212430.GA92116@felucia.tataz.chchile.org> <514B9EF6.3000607@quip.cz> <514BA14F.3090609@FreeBSD.org> <514BA3D9.5010901@quip.cz> <514BAA01.20402@FreeBSD.org> <20130509091738.GC4437@caravan.chchile.org> <518BA433.6050605@FreeBSD.org> Subject: RE: new jail(8) ignoring devfs_ruleset? Date: Fri, 10 May 2013 14:42:07 +1000 Message-ID: <3AF9A67BBCE34917A8C9BC2863F7C0A5@as.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <518BA433.6050605@FreeBSD.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac5MuPzX+jFKBjoUTIqHilUaA3v2bwAfv1SQ X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 04:44:22 -0000 An ugly workaround to complete the jail closure, when relying on jail.conf, is to: jail -r $JAILNAME umount /$LOCATION_OF_JAILS/$JAILNAME/dev || true Regards, Dewayne. From owner-freebsd-stable@FreeBSD.ORG Fri May 10 05:23:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 68CE44F3 for ; Fri, 10 May 2013 05:23:02 +0000 (UTC) (envelope-from freebsd@pki2.com) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) by mx1.freebsd.org (Postfix) with ESMTP id 173F2DBD for ; Fri, 10 May 2013 05:23:02 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.6/8.14.5) with ESMTP id r4A5Mp7u051078; Thu, 9 May 2013 22:22:51 -0700 (PDT) (envelope-from freebsd@pki2.com) Subject: Re: Apparent regression in r250359 From: Dennis Glatting To: Jim Ohlstein In-Reply-To: <518BDA28.20603@ohlste.in> References: <518A880C.3090906@ohlste.in> <20130509053055.GM3047@kib.kiev.ua> <518BAEFB.5090204@ohlste.in> <20130509143038.GV3047@kib.kiev.ua> <518BC3E4.1030104@ohlste.in> <20130509160433.GW3047@kib.kiev.ua> <518BDA28.20603@ohlste.in> Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 09 May 2013 22:22:51 -0700 Message-ID: <1368163371.96389.2.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Dennis Glatting X-yoursite-MailScanner-ID: r4A5Mp7u051078 X-yoursite-MailScanner: Found to be clean X-MailScanner-From: freebsd@pki2.com Cc: Konstantin Belousov , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 05:23:02 -0000 This patch allows my AMD CURRENT to complete boot without core dumping. I was also able to recompile/reinstall lang/gcc48 without trouble. My 9.1 systems are busy but I may be able to give it a try tomorrow. On Thu, 2013-05-09 at 13:17 -0400, Jim Ohlstein wrote: > On 05/09/13 12:04, Konstantin Belousov wrote: > > On Thu, May 09, 2013 at 11:42:28AM -0400, Jim Ohlstein wrote: > >> On 05/09/13 10:30, Konstantin Belousov wrote: > >>> On Thu, May 09, 2013 at 10:13:15AM -0400, Jim Ohlstein wrote: > >>>> # sysctl hw.model > >>>> hw.model: AMD FX(tm)-8350 Eight-Core Processor > >>> Ahh, so it seems that this is a CPU with the LWP. > >>> Please try the patch at the end of message. > >> > >> Same error > >> > >>> > >>> As another workaround, which does not disable AVX support, you > >>> could try loader tunable hw.xsave_mask=0x7. > >> > >> This works > > > > Hm, I see another bug in the next line as well. Could you try this > > updated patch ? > > This does work. > > > > > diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c > > index de79baa..9bc8a2f 100644 > > --- a/sys/amd64/amd64/fpu.c > > +++ b/sys/amd64/amd64/fpu.c > > @@ -687,8 +687,8 @@ fpugetregs(struct thread *td) > > offsetof(struct xstate_hdr, xstate_bv)); > > max_ext_n = flsl(xsave_mask); > > for (i = 0; i < max_ext_n; i++) { > > - bit = 1 << i; > > - if ((*xstate_bv & bit) != 0) > > + bit = 1ULL << i; > > + if ((xsave_mask & bit) == 0 || (*xstate_bv & bit) != 0) > > continue; > > bcopy((char *)fpu_initialstate + > > xsave_area_desc[i].offset, > > > > From owner-freebsd-stable@FreeBSD.ORG Fri May 10 10:24:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6A7D75B5 for ; Fri, 10 May 2013 10:24:04 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 05715F72 for ; Fri, 10 May 2013 10:24:03 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UakFP-0004UC-FK for freebsd-stable@freebsd.org; Fri, 10 May 2013 12:08:20 +0200 Received: from dhcp-077-251-158-153.chello.nl ([77.251.158.153] helo=ronaldradial) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UakFN-0001cc-MK for freebsd-stable@freebsd.org; Fri, 10 May 2013 12:08:17 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: recommended memory for zfs References: <518BA237.3030700@gmail.com> <518C450B.5070809@ShaneWare.Biz> <518C51AF.5050609@gmail.com> <20130510020628.GA98750@icarus.home.lan> <518C5902.5050909@gmail.com> Date: Fri, 10 May 2013 12:08:17 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <518C5902.5050909@gmail.com> User-Agent: Opera Mail/12.15 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 67ca9281b58cf5c8a5b2b1d981559170 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 10:24:04 -0000 On Fri, 10 May 2013 04:18:42 +0200, Benjamin Adams wrote: > On 05/09/2013 10:06 PM, Jeremy Chadwick wrote: >> On Thu, May 09, 2013 at 09:47:27PM -0400, Benjamin Adams wrote: >>> On 05/09/2013 08:53 PM, Shane Ambler wrote: >>>> On 09/05/2013 22:48, Benjamin Adams wrote: >>>>> Hello zfs question about memory. >>>>> I heard zfs is very ram hungry. >>>>> Service looking to run: >>>>> - nginx >>>>> - postgres >>>>> - php-fpm >>>>> - python >>>>> >>>>> I have a machine with two quad core cpus but only 4 G Memory >>>>> >>>>> I'm looking to buy more ram now. >>>>> What would be the recommend amount of memory for zfs across 6 drives >>>>> on >>>>> this setup? >>>>> >>>> I believe I heard a calculation of 1GB cache per 1TB of disk. But >>>> basically zfs will use all free ram available if you access that >>>> much data from disk. You will want to set vfs.zfs.arc_max to allow >>>> enough ram for your apps to work in. >>>> >>>> If you consider the files for your website and the data you store >>>> you may find that you would never fill more than 500MB of cache. >>>> >>>> If you will be serving large media files that will easily use up >>>> the cache you could give them their own filesystem that only >>>> caches metadata - zfs set primarycache=metadata zroot/mediafiles >>>> >>>> >>> Thanks for all the replies Size of DB and HD's are: >>> >>> Current DB Size = 23 GB >>> HD sizes = (6) 500 GB drives >> Nobody is going to be able to give you a precise/accurate recommendation >> given the lack of detail provided, I'm sorry to say. What's the RES >> size of nginx (all processes combined)? What's the RES size of >> postgres (same)? Do you have PHP scripts that "run amok" for long >> periods of time and take up lots of RAM? Same with python? How many >> concurrent visitors and what sort of content are you hosting? Do you >> maintain/write your own PHP/Python code or are you using some crap like >> Wordpress? >> >> This is just a **small** list of questions -- and what may come as a >> shock is that I do not expect you to provide answers to any of them. >> They are questions that you should, for yourself, attempt to answer and >> work out what you need from there ("teach a man to fish" and all that). >> >> The advice of "1GB of RAM per 1TB of disk space" is absolute nonsense on >> numerous levels -- whoever gave this advice to Shane either has no >> understanding of how filesystems/ZFS works, or does but chose to >> simplify to the point where they're providing half-ass information. >> There is no direct, or even indirect, correlation between disk capacity >> and ZFS ARC size -- what matter is your "working set" (to quote Tom). >> You need to have some idea of how much disk I/O you're doing, and what >> type of I/O (sequential or random). >> >> If you want my general advice, Benjamin, it's this: get yourself a >> system with *minimum* 8GB of RAM but has the physical possibility of >> supporting more (and only add more RAM when/if you know you need it); do >> not bother with ZFS on a system with 4GB. Run amd64, not i386 (I don't >> recommend bothering with ZFS on i386 -- I am not going to get into a >> discussion about this either). Run stable/9, not 9.1-RELEASE. Avoid >> compression and dedup. And test disk failures as well (don't get caught >> with your pants down later). >> >> The above advice comes from someone who did hosting (web/ssh/etc.) for >> almost 20 years with KISS principle applied at all levels. YMMV though, >> depending on what all you're doing/what you truly need. >> >> Good luck. >> > Jeremy, > > Was just see if I should just get raid controller and more ram down the > road. > List of priorities. > > Main thing is I move from BSD when 9.0 came out. Was looking to see if > zfs is included in the installer. Now. > > Sum up: > upgrade ram to 16GB (not 64 like plained) > and raid controller that supports level 5. > Let ZFS do the RAID stuff. Do not use a RAID controller, but give the plain disks to ZFS. Some of the nice features come from ZFS doing the RAID stuff. Ronald. From owner-freebsd-stable@FreeBSD.ORG Fri May 10 10:48:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7E0DC901 for ; Fri, 10 May 2013 10:48:45 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) by mx1.freebsd.org (Postfix) with ESMTP id EC4F5C7 for ; Fri, 10 May 2013 10:48:44 +0000 (UTC) Received: from [193.68.6.170] ([193.68.6.170]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.6/8.14.6) with ESMTP id r4AAfbin009148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 May 2013 13:41:39 +0300 (EEST) (envelope-from daniel@digsys.bg) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: recommended memory for zfs From: Daniel Kalchev In-Reply-To: Date: Fri, 10 May 2013 13:41:37 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <60A0A396-2E56-488F-BB5A-6EDD51B8039D@digsys.bg> References: <518BA237.3030700@gmail.com> <518C450B.5070809@ShaneWare.Biz> <518C51AF.5050609@gmail.com> <20130510020628.GA98750@icarus.home.lan> <518C5902.5050909@gmail.com> To: "Ronald Klop" X-Mailer: Apple Mail (2.1503) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 10:48:45 -0000 On May 10, 2013, at 1:08 PM, "Ronald Klop" = wrote: > On Fri, 10 May 2013 04:18:42 +0200, Benjamin Adams = wrote: >=20 >> On 05/09/2013 10:06 PM, Jeremy Chadwick wrote: >>> On Thu, May 09, 2013 at 09:47:27PM -0400, Benjamin Adams wrote: >>>> On 05/09/2013 08:53 PM, Shane Ambler wrote: >>>>> On 09/05/2013 22:48, Benjamin Adams wrote: >>>>>> Hello zfs question about memory. >>>>>> I heard zfs is very ram hungry. >>>>>> Service looking to run: >>>>>> - nginx >>>>>> - postgres >>>>>> - php-fpm >>>>>> - python >>>>>>=20 >>>>>> I have a machine with two quad core cpus but only 4 G Memory >>>>>>=20 >>>>>> I'm looking to buy more ram now. >>>>>> What would be the recommend amount of memory for zfs across 6 = drives on >>>>>> this setup? >>>>>>=20 >>>>> I believe I heard a calculation of 1GB cache per 1TB of disk. But >>>>> basically zfs will use all free ram available if you access that >>>>> much data from disk. You will want to set vfs.zfs.arc_max to allow >>>>> enough ram for your apps to work in. >>>>>=20 >>>>> If you consider the files for your website and the data you store >>>>> you may find that you would never fill more than 500MB of cache. >>>>>=20 >>>>> If you will be serving large media files that will easily use up >>>>> the cache you could give them their own filesystem that only >>>>> caches metadata - zfs set primarycache=3Dmetadata zroot/mediafiles >>>>>=20 >>>>>=20 >>>> Thanks for all the replies Size of DB and HD's are: >>>>=20 >>>> Current DB Size =3D 23 GB >>>> HD sizes =3D (6) 500 GB drives >>> Nobody is going to be able to give you a precise/accurate = recommendation >>> given the lack of detail provided, I'm sorry to say. What's the RES >>> size of nginx (all processes combined)? What's the RES size of >>> postgres (same)? Do you have PHP scripts that "run amok" for long >>> periods of time and take up lots of RAM? Same with python? How = many >>> concurrent visitors and what sort of content are you hosting? Do = you >>> maintain/write your own PHP/Python code or are you using some crap = like >>> Wordpress? >>>=20 >>> This is just a **small** list of questions -- and what may come as a >>> shock is that I do not expect you to provide answers to any of them. >>> They are questions that you should, for yourself, attempt to answer = and >>> work out what you need from there ("teach a man to fish" and all = that). >>>=20 >>> The advice of "1GB of RAM per 1TB of disk space" is absolute = nonsense on >>> numerous levels -- whoever gave this advice to Shane either has no >>> understanding of how filesystems/ZFS works, or does but chose to >>> simplify to the point where they're providing half-ass information. >>> There is no direct, or even indirect, correlation between disk = capacity >>> and ZFS ARC size -- what matter is your "working set" (to quote = Tom). >>> You need to have some idea of how much disk I/O you're doing, and = what >>> type of I/O (sequential or random). >>>=20 >>> If you want my general advice, Benjamin, it's this: get yourself a >>> system with *minimum* 8GB of RAM but has the physical possibility of >>> supporting more (and only add more RAM when/if you know you need = it); do >>> not bother with ZFS on a system with 4GB. Run amd64, not i386 (I = don't >>> recommend bothering with ZFS on i386 -- I am not going to get into a >>> discussion about this either). Run stable/9, not 9.1-RELEASE. = Avoid >>> compression and dedup. And test disk failures as well (don't get = caught >>> with your pants down later). >>>=20 >>> The above advice comes from someone who did hosting (web/ssh/etc.) = for >>> almost 20 years with KISS principle applied at all levels. YMMV = though, >>> depending on what all you're doing/what you truly need. >>>=20 >>> Good luck. >>>=20 >> Jeremy, >>=20 >> Was just see if I should just get raid controller and more ram down = the road. >> List of priorities. >>=20 >> Main thing is I move from BSD when 9.0 came out. Was looking to see = if zfs is included in the installer. Now. >>=20 >> Sum up: >> upgrade ram to 16GB (not 64 like plained) >> and raid controller that supports level 5. >>=20 >=20 > Let ZFS do the RAID stuff. Do not use a RAID controller, but give the = plain disks to ZFS. Some of the nice features come from ZFS doing the = RAID stuff. To paraphrase this. Get yourself a nice HBA. non-RAID! For example, something based on = LSI2008 with IT firmware. With few enough discs you can avoid using SAS = expanders as well. RAID controllers, in addition to causing all kinds of = troubles are unlikely to have sufficient bandwidth and might turn out to = be the bottleneck (unless you are prepared to spend an unholy amount of = money -- which are better spent for RAM and CPU). If you want performance and low latency, avoid using compression and = dedup in ZFS. Set your record size appropriately for postgresql (8k) = *before* you run initdb. It is best to create an separate filesystem for = the database and set that property only there. If your database is heavy = on updates, you might be interested to use an SSD for ZIL. In general, = if you can afford it, an cheap SSD for L2ARC might do wonders -- if your = data set can fit there. If you intend to use SSDs and want the best = performance, use different SSDs for ZIL and L2ARC. The first needs to be = fast at writing and optimised for his (for example, the OCZ Vector) -- = it does not need to be large, at all. The second has to provide high = read throughput and IOPS, not so much for writing. Lately, I am building more and more servers with SSDs only and ZFS and = performance has been incomparable with spinning drives. Also, check what the sector size on your drives is. Most these days are = 4k already and you need to tell ZFS that (because the drives lie). It is = safer to plan for 4k drives, as future replacements are likely to be of = that kind. The same about SSDs.=20 Daniel= From owner-freebsd-stable@FreeBSD.ORG Fri May 10 12:45:52 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2FC60D88; Fri, 10 May 2013 12:45:52 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [199.192.164.235]) by mx1.freebsd.org (Postfix) with ESMTP id 0F3BA7C0; Fri, 10 May 2013 12:45:51 +0000 (UTC) Received: from glorfindel.gritton.org (c-24-10-224-248.hsd1.ut.comcast.net [24.10.224.248]) (authenticated bits=0) by m2.gritton.org (8.14.5/8.14.5) with ESMTP id r4ACjnTT001625; Fri, 10 May 2013 06:45:50 -0600 (MDT) (envelope-from jamie@FreeBSD.org) Message-ID: <518CEBFC.1010408@FreeBSD.org> Date: Fri, 10 May 2013 06:45:48 -0600 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20120129 Thunderbird/3.1.16 MIME-Version: 1.0 To: Dewayne Geraghty Subject: Re: new jail(8) ignoring devfs_ruleset? References: <511E61F5.1000805@omnilan.de> <511EC759.4060704@FreeBSD.org> <5121EC52.5040502@omnilan.de> <20130219212430.GA92116@felucia.tataz.chchile.org> <514B9EF6.3000607@quip.cz> <514BA14F.3090609@FreeBSD.org> <514BA3D9.5010901@quip.cz> <514BAA01.20402@FreeBSD.org> <20130509091738.GC4437@caravan.chchile.org> <518BA433.6050605@FreeBSD.org> <3AF9A67BBCE34917A8C9BC2863F7C0A5@as.lan> In-Reply-To: <3AF9A67BBCE34917A8C9BC2863F7C0A5@as.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Harald Schmalzbauer' , freebsd-jail@FreeBSD.org, freebsd-stable@FreeBSD.org, 'Miroslav Lachman' <000.fbsd@quip.cz> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 12:45:52 -0000 On 05/09/13 22:42, Dewayne Geraghty wrote: > An ugly workaround to complete the jail closure, when relying on jail.conf, is to: > > jail -r $JAILNAME > umount /$LOCATION_OF_JAILS/$JAILNAME/dev || true The only problem with devfs I'm aware of is it not catching the right ruleset when starting in the rc system. So does this mean you're having problems unmounting /dev? What happens when you add a "-v" to the "jail -r"? It should note that /dev is being umounted. - Jamie From owner-freebsd-stable@FreeBSD.ORG Fri May 10 13:55:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 83230828 for ; Fri, 10 May 2013 13:55:13 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 45C12AC8 for ; Fri, 10 May 2013 13:55:13 +0000 (UTC) Received: by mail-vb0-f42.google.com with SMTP id w16so3521161vbf.1 for ; Fri, 10 May 2013 06:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=x+l3TiLh/ln2GJ6rJbKVegZptYhUrYZEh8uxnxl2xeU=; b=vEHahClPUv/bBLfT5irDlQG8gYJPyrQz5jCVAUdF6F8Mf5nubSpU9BZo2XUyjRpc1C icRWdUDmU0or2B8sLQq4yNF8TovfqlwnP+3hdlNUd2fOeNygRPORforo63os43ha7Ftr JkLyIfLqkQzR5e/baSVwJI99+ZJ59GKOXmya2xiBv6JnnJNk5tkV8x25v/tBYBysIr1G qRjv5iBjryjkp4EizwsV/H3wZzcK3dOddKpwwnB7rF8sDzWC0/EriIqcnBU1Cxlfl78p IEFqh56LFeN+uymwf01Br+B7IJ4mjgdLe2VGbSIC/Qk8UHQQmMMfXAew4MXVZwtpfvbH oi7w== MIME-Version: 1.0 X-Received: by 10.58.229.69 with SMTP id so5mr11091573vec.6.1368194112761; Fri, 10 May 2013 06:55:12 -0700 (PDT) Received: by 10.59.4.130 with HTTP; Fri, 10 May 2013 06:55:12 -0700 (PDT) Date: Fri, 10 May 2013 09:55:12 -0400 Message-ID: Subject: Generating ISO With Pre-Installed Packages From: Shawn Webb To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 13:55:13 -0000 Hey All, I'm looking to generate a FreeBSD 9-stable (and maybe 10-current) ISO that has certain packages pre-installed. I'd like to create my own installation media that will have certain things installed, like a web management UI that I'm actively working on. It'd be like what pfSense does. I did do a little googling and found pfSense's build documentation for spinning a custom build of pfSense. I'll be spending the weekend looking over their work. But in the meantime, does anyone know of the steps involved in such a process? Is the process documented somewhere? Thanks, Shawn From owner-freebsd-stable@FreeBSD.ORG Fri May 10 14:14:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6D0766C9 for ; Fri, 10 May 2013 14:14:12 +0000 (UTC) (envelope-from vrwmiller@gmail.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 4255AC2E for ; Fri, 10 May 2013 14:14:12 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id u16so8058842iet.14 for ; Fri, 10 May 2013 07:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hD5uA4O2LSGitrXnKCU50WQkjWX7iydAfKtl7Qcu/XQ=; b=dTv0ty0olc13z3dvXMgpJmVKsjS429LKz3+vFyeLNXSsCKwxdZijq0y/XMVuWxThJ+ S1Q78TusBMcrrnKKmJbUtf/QGh3evV2H7834GDYHq0Rgmvy8COQFTKWyLnVm9G44ZEdY xZr9wJUkoSNsK80QPARXsa/opDKrz4kIAYtYwF4jiOgsdlW78Ml5Ou6HKTziBt4QGVWY 6aa2Ea00iZO1HCbggfyFGg3DwqFkvU6xdjNdQYSJF/6MEbO4dyjALDJs/B3VRLDbhjO7 A/usbWF0GMpHb7KKM4CI+vjKuTzX4im2G3uPRtOzy59/Uh75mTa/53+dLOU/60/CjZRc 4c0g== MIME-Version: 1.0 X-Received: by 10.50.147.71 with SMTP id ti7mr2158717igb.49.1368195251950; Fri, 10 May 2013 07:14:11 -0700 (PDT) Sender: vrwmiller@gmail.com Received: by 10.64.25.66 with HTTP; Fri, 10 May 2013 07:14:11 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 May 2013 10:14:11 -0400 X-Google-Sender-Auth: 1goH99YnRCmI7pKgDW_L5McfUxI Message-ID: Subject: Re: Generating ISO With Pre-Installed Packages From: Rick Miller To: Shawn Webb Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 14:14:12 -0000 On Fri, May 10, 2013 at 9:55 AM, Shawn Webb wrote: > Hey All, > > I'm looking to generate a FreeBSD 9-stable (and maybe 10-current) ISO that > has certain packages pre-installed. I'd like to create my own installation > media that will have certain things installed, like a web management UI > that I'm actively working on. It'd be like what pfSense does. > > I did do a little googling and found pfSense's build documentation for > spinning a custom build of pfSense. I'll be spending the weekend looking > over their work. But in the meantime, does anyone know of the steps > involved in such a process? Is the process documented somewhere? You're looking for package-split.py, a python script that generates packages. The blog post below may be of some use. It explains modifying the script and generating a release. http://blog.hostileadmin.com/2012/10/08/building-freebsd-media-with-custom-packages/ -- Take care Rick Miller From owner-freebsd-stable@FreeBSD.ORG Fri May 10 14:44:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C07E5119 for ; Fri, 10 May 2013 14:44:43 +0000 (UTC) (envelope-from luke@foolishgames.com) Received: from stargazer.midnightbsd.org (cl-218.chi-02.us.sixxs.net [IPv6:2001:4978:f:d9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6DDE0F60 for ; Fri, 10 May 2013 14:44:43 +0000 (UTC) Received: from [67.194.84.210] (67-194-84-210.wireless.umnet.umich.edu [67.194.84.210]) (authenticated bits=0) by stargazer.midnightbsd.org (8.14.6/8.14.6) with ESMTP id r4AEift3071778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 10 May 2013 10:44:42 -0400 (EDT) (envelope-from luke@foolishgames.com) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at stargazer.midnightbsd.org X-Authentication-Warning: stargazer.midnightbsd.org: Host 67-194-84-210.wireless.umnet.umich.edu [67.194.84.210] claimed to be [67.194.84.210] References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4777E248-4EAD-4FF9-8E9A-995B4486CF8A@foolishgames.com> X-Mailer: iPhone Mail (10B350) From: Lucas Holt Subject: Re: Generating ISO With Pre-Installed Packages Date: Fri, 10 May 2013 10:44:40 -0400 To: Shawn Webb Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 14:44:43 -0000 As Rick pointed out, the package split script will get the packages on the m= edia. You also need to modify the install process to actually install the de= fault packages. You might want to look at the bsdinstall setup and add a scr= ipt there to load the packages. Another approach is to create a script that r= uns on first boot that can install the packages via network or possibly off t= he media. For MidnightBSD, I created a firstboot script that prompts the use= r to install a graphical desktop environment and the fetched meta packages f= rom our ports tree that would pull down everything required for kde or GNUst= ep + window maker. It was easier as we had sysinstall still.=20 Lucas Holt On May 10, 2013, at 9:55 AM, Shawn Webb wrote: > Hey All, >=20 > I'm looking to generate a FreeBSD 9-stable (and maybe 10-current) ISO that= > has certain packages pre-installed. I'd like to create my own installation= > media that will have certain things installed, like a web management UI > that I'm actively working on. It'd be like what pfSense does. >=20 > I did do a little googling and found pfSense's build documentation for > spinning a custom build of pfSense. I'll be spending the weekend looking > over their work. But in the meantime, does anyone know of the steps > involved in such a process? Is the process documented somewhere? >=20 > Thanks, >=20 > Shawn > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Fri May 10 19:26:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 733275D9 for ; Fri, 10 May 2013 19:26:24 +0000 (UTC) (envelope-from dg@pki2.com) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1EFF729C for ; Fri, 10 May 2013 19:26:24 +0000 (UTC) Received: from btw.pki2.com (btw.pki2.com [192.168.23.1]) by btw.pki2.com (8.14.6/8.14.5) with ESMTP id r4AJQGgx059755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 May 2013 12:26:18 -0700 (PDT) (envelope-from dg@pki2.com) Date: Fri, 10 May 2013 12:26:16 -0700 (PDT) From: Dennis Glatting X-X-Sender: dennisg@btw.pki2.com To: Jim Ohlstein Subject: Re: Apparent regression in r250359 In-Reply-To: <518BDA28.20603@ohlste.in> Message-ID: References: <518A880C.3090906@ohlste.in> <20130509053055.GM3047@kib.kiev.ua> <518BAEFB.5090204@ohlste.in> <20130509143038.GV3047@kib.kiev.ua> <518BC3E4.1030104@ohlste.in> <20130509160433.GW3047@kib.kiev.ua> <518BDA28.20603@ohlste.in> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-yoursite-MailScanner-Information: Dennis Glatting X-yoursite-MailScanner-ID: r4AJQGgx059755 X-yoursite-MailScanner: Found to be clean X-MailScanner-From: dg@pki2.com Cc: Konstantin Belousov , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 19:26:24 -0000 This patch works on one of my 9.1 systems in addition to my CURRENT system. On Thu, 9 May 2013, Jim Ohlstein wrote: > On 05/09/13 12:04, Konstantin Belousov wrote: >> On Thu, May 09, 2013 at 11:42:28AM -0400, Jim Ohlstein wrote: >>> On 05/09/13 10:30, Konstantin Belousov wrote: >>>> On Thu, May 09, 2013 at 10:13:15AM -0400, Jim Ohlstein wrote: >>>>> # sysctl hw.model >>>>> hw.model: AMD FX(tm)-8350 Eight-Core Processor >>>> Ahh, so it seems that this is a CPU with the LWP. >>>> Please try the patch at the end of message. >>> >>> Same error >>> >>>> >>>> As another workaround, which does not disable AVX support, you >>>> could try loader tunable hw.xsave_mask=0x7. >>> >>> This works >> >> Hm, I see another bug in the next line as well. Could you try this >> updated patch ? > > This does work. > >> >> diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c >> index de79baa..9bc8a2f 100644 >> --- a/sys/amd64/amd64/fpu.c >> +++ b/sys/amd64/amd64/fpu.c >> @@ -687,8 +687,8 @@ fpugetregs(struct thread *td) >> offsetof(struct xstate_hdr, xstate_bv)); >> max_ext_n = flsl(xsave_mask); >> for (i = 0; i < max_ext_n; i++) { >> - bit = 1 << i; >> - if ((*xstate_bv & bit) != 0) >> + bit = 1ULL << i; >> + if ((xsave_mask & bit) == 0 || (*xstate_bv & bit) != >> 0) >> continue; >> bcopy((char *)fpu_initialstate + >> xsave_area_desc[i].offset, >> > > > -- > Jim Ohlstein > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri May 10 20:59:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 98A1DAAD; Fri, 10 May 2013 20:59:50 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 7C48B876; Fri, 10 May 2013 20:59:50 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id DFD263AF57; Fri, 10 May 2013 13:59:49 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: bin/152154: script(1) -k malfunctions with certain shells (e.g. tcsh, bash, zsh) Date: Fri, 10 May 2013 13:59:49 -0700 Message-ID: <87178.1368219589@server1.tristatelogic.com> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 20:59:50 -0000 http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/152154 It has been suggested to me (by a committer) that I should raise the issue of this PR here on these lists, because the problem described within the PR remains a real problem, and despite my having proposed something that seems to be a perfectly workable fix, no action has been taken on this PR for some years now. Regards, rfg P.S. The following additional PRs, also filed by me and also relating to the script(1) command, supply some additional improvements to efficiency and code clarity. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/152131 http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/152132 From owner-freebsd-stable@FreeBSD.ORG Fri May 10 21:36:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C8BCC569; Fri, 10 May 2013 21:36:12 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 88F8698D; Fri, 10 May 2013 21:36:12 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Uauz4-000Ipy-Dz; Fri, 10 May 2013 23:36:10 +0200 Date: Fri, 10 May 2013 23:36:10 +0200 From: Kurt Jaeger To: "Ronald F. Guilmette" Subject: Re: bin/152154: script(1) -k malfunctions with certain shells (e.g. tcsh, bash, zsh) Message-ID: <20130510213610.GG8239@home.opsec.eu> References: <87178.1368219589@server1.tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87178.1368219589@server1.tristatelogic.com> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 21:36:12 -0000 Hi! > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/152154 > > It has been suggested to me (by a committer) that I should raise the > issue of this PR here on these lists, because the problem described > within the PR remains a real problem, and despite my having proposed > something that seems to be a perfectly workable fix, no action has > been taken on this PR for some years now. Having looked at the PR, may I suggest that you look at sysutils/screen and screen -L especially instead of script -k -- and add some input logging to screen ? Or, for the tmux fraction, at sysutils/tmux ? I'm not sure why you absolutly *need* the input logging -- can you describe the use case ? Is it some security-audit-issue ? -- pi@opsec.eu +49 171 3101372 7 years to go ! From owner-freebsd-stable@FreeBSD.ORG Fri May 10 22:10:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EBA2C78; Fri, 10 May 2013 22:10:38 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id CAB12AEC; Fri, 10 May 2013 22:10:38 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id D6AA63AF45; Fri, 10 May 2013 15:10:32 -0700 (PDT) From: "Ronald F. Guilmette" To: Kurt Jaeger Subject: Re: bin/152154: script(1) -k malfunctions with certain shells (e.g. tcsh, bash, zsh) In-Reply-To: <20130510213610.GG8239@home.opsec.eu> Date: Fri, 10 May 2013 15:10:32 -0700 Message-ID: <88719.1368223832@server1.tristatelogic.com> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 22:10:39 -0000 In message <20130510213610.GG8239@home.opsec.eu>, you wrote: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/152154 >> >> It has been suggested to me (by a committer) that I should raise the >> issue of this PR here on these lists, because the problem described >> within the PR remains a real problem, and despite my having proposed >> something that seems to be a perfectly workable fix, no action has >> been taken on this PR for some years now. > >Having looked at the PR, may I suggest that you look at sysutils/screen >and screen -L especially instead of script -k -- and add some >input logging to screen ? Or, for the tmux fraction, at sysutils/tmux ? Where I come from, we have a very common saying "It's a free country!" Thus, you may indeed make that suggestion. In fact you are free to suggest anything you like. Unfortunately, I currently already have an overflowing TO-DO list and I am not taking anything more onto my own personal plate at this time. >I'm not sure why you absolutly *need* the input logging -- can you >describe the use case ? Is it some security-audit-issue ? I really do not intend to be at all rude, but... I'm not sure why you are asking _me_ to defend the existance of the script -k option. I probably could do so, but that is rather besides the point, I think. The option exists, and has existed, for quite a long time. At some time in the ancient past, presumably when dinosaurs (and perhaps even Richie, Thompson, & Kernighan) roamed the earth, someone somewhere thought that being able to have script(1) log both input and output was a Good Idea[tm] and the -k option was born. Unfortunately, in FreeBSD, that option is buggy. It doesn't work right. It doesn't work according to specification. I proposed a way (code) to fix that. That's all. If you want to debate the merits of the very existance of the script program, or any option thereof, I'll be more than happy to do so anytime over a beer... as long as you are buying. In the meantime may I suggest that the easily verifiable bug that I originally filed a PR on should be fixed? Regards, rfg From owner-freebsd-stable@FreeBSD.ORG Fri May 10 23:38:24 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8648ED4F; Fri, 10 May 2013 23:38:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 3A6B8E16; Fri, 10 May 2013 23:38:24 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r4ANcN2d052659; Fri, 10 May 2013 23:38:23 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r4ANcMLA052494; Fri, 10 May 2013 23:38:22 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 10 May 2013 23:38:22 GMT Message-Id: <201305102338.r4ANcMLA052494@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 23:38:24 -0000 TB --- 2013-05-10 23:05:12 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-05-10 23:05:12 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-10 23:05:12 - starting RELENG_8 tinderbox run for mips/mips TB --- 2013-05-10 23:05:12 - cleaning the object tree TB --- 2013-05-10 23:05:12 - /usr/local/bin/svn stat /src TB --- 2013-05-10 23:05:15 - At svn revision 250487 TB --- 2013-05-10 23:05:16 - building world TB --- 2013-05-10 23:05:16 - CROSS_BUILD_TESTING=YES TB --- 2013-05-10 23:05:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-10 23:05:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-10 23:05:16 - SRCCONF=/dev/null TB --- 2013-05-10 23:05:16 - TARGET=mips TB --- 2013-05-10 23:05:16 - TARGET_ARCH=mips TB --- 2013-05-10 23:05:16 - TZ=UTC TB --- 2013-05-10 23:05:16 - __MAKE_CONF=/dev/null TB --- 2013-05-10 23:05:16 - cd /src TB --- 2013-05-10 23:05:16 - /usr/bin/make -B buildworld >>> World build started on Fri May 10 23:05:17 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -c /src/usr.sbin/ndp/../../contrib/tcpdump/gmt2local.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -EL -o ndp ndp.o gmt2local.o gzip -cn /src/usr.sbin/ndp/ndp.8 > ndp.8.gz ===> usr.sbin/newsyslog (all) cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/newsyslog.c cc1: warnings being treated as errors /src/usr.sbin/newsyslog/newsyslog.c: In function 'delete_oldest_timelog': /src/usr.sbin/newsyslog/newsyslog.c:1511: warning: unused variable 'valid' *** [newsyslog.o] Error code 1 Stop in /src/usr.sbin/newsyslog. *** [all] Error code 1 Stop in /src/usr.sbin. *** [usr.sbin.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** [buildworld] Error code 1 Stop in /src. TB --- 2013-05-10 23:38:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-10 23:38:22 - ERROR: failed to build world TB --- 2013-05-10 23:38:22 - 1619.40 user 348.73 system 1990.52 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Fri May 10 23:38:53 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9C7E9E74; Fri, 10 May 2013 23:38:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 51A9FE24; Fri, 10 May 2013 23:38:53 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r4ANcqeR062171; Fri, 10 May 2013 23:38:52 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r4ANcqSN062168; Fri, 10 May 2013 23:38:52 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 10 May 2013 23:38:52 GMT Message-Id: <201305102338.r4ANcqSN062168@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 23:38:53 -0000 TB --- 2013-05-10 23:05:12 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-05-10 23:05:12 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-10 23:05:12 - starting RELENG_8 tinderbox run for arm/arm TB --- 2013-05-10 23:05:12 - cleaning the object tree TB --- 2013-05-10 23:05:12 - /usr/local/bin/svn stat /src TB --- 2013-05-10 23:05:15 - At svn revision 250487 TB --- 2013-05-10 23:05:16 - building world TB --- 2013-05-10 23:05:16 - CROSS_BUILD_TESTING=YES TB --- 2013-05-10 23:05:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-10 23:05:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-10 23:05:16 - SRCCONF=/dev/null TB --- 2013-05-10 23:05:16 - TARGET=arm TB --- 2013-05-10 23:05:16 - TARGET_ARCH=arm TB --- 2013-05-10 23:05:16 - TZ=UTC TB --- 2013-05-10 23:05:16 - __MAKE_CONF=/dev/null TB --- 2013-05-10 23:05:16 - cd /src TB --- 2013-05-10 23:05:16 - /usr/bin/make -B buildworld >>> World build started on Fri May 10 23:05:17 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -c /src/usr.sbin/ndp/../../contrib/tcpdump/gmt2local.c cc -O -pipe -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -o ndp ndp.o gmt2local.o gzip -cn /src/usr.sbin/ndp/ndp.8 > ndp.8.gz ===> usr.sbin/newsyslog (all) cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/newsyslog.c cc1: warnings being treated as errors /src/usr.sbin/newsyslog/newsyslog.c: In function 'delete_oldest_timelog': /src/usr.sbin/newsyslog/newsyslog.c:1511: warning: unused variable 'valid' *** [newsyslog.o] Error code 1 Stop in /src/usr.sbin/newsyslog. *** [all] Error code 1 Stop in /src/usr.sbin. *** [usr.sbin.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** [buildworld] Error code 1 Stop in /src. TB --- 2013-05-10 23:38:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-10 23:38:52 - ERROR: failed to build world TB --- 2013-05-10 23:38:52 - 1672.59 user 375.45 system 2020.77 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Fri May 10 23:47:26 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 07AAD20C; Fri, 10 May 2013 23:47:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id AD65DE77; Fri, 10 May 2013 23:47:25 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r4ANlPws025090; Fri, 10 May 2013 23:47:25 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r4ANlPef025088; Fri, 10 May 2013 23:47:25 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 10 May 2013 23:47:25 GMT Message-Id: <201305102347.r4ANlPef025088@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 23:47:26 -0000 TB --- 2013-05-10 23:05:12 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-05-10 23:05:12 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-10 23:05:12 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2013-05-10 23:05:12 - cleaning the object tree TB --- 2013-05-10 23:05:12 - /usr/local/bin/svn stat /src TB --- 2013-05-10 23:05:15 - At svn revision 250487 TB --- 2013-05-10 23:05:16 - building world TB --- 2013-05-10 23:05:16 - CROSS_BUILD_TESTING=YES TB --- 2013-05-10 23:05:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-10 23:05:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-10 23:05:16 - SRCCONF=/dev/null TB --- 2013-05-10 23:05:16 - TARGET=pc98 TB --- 2013-05-10 23:05:16 - TARGET_ARCH=i386 TB --- 2013-05-10 23:05:16 - TZ=UTC TB --- 2013-05-10 23:05:16 - __MAKE_CONF=/dev/null TB --- 2013-05-10 23:05:16 - cd /src TB --- 2013-05-10 23:05:16 - /usr/bin/make -B buildworld >>> World build started on Fri May 10 23:05:17 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -fstack-protector -c /src/usr.sbin/ndp/../../contrib/tcpdump/gmt2local.c cc -O2 -pipe -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -fstack-protector -o ndp ndp.o gmt2local.o gzip -cn /src/usr.sbin/ndp/ndp.8 > ndp.8.gz ===> usr.sbin/newsyslog (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/newsyslog.c cc1: warnings being treated as errors /src/usr.sbin/newsyslog/newsyslog.c: In function 'delete_oldest_timelog': /src/usr.sbin/newsyslog/newsyslog.c:1511: warning: unused variable 'valid' *** [newsyslog.o] Error code 1 Stop in /src/usr.sbin/newsyslog. *** [all] Error code 1 Stop in /src/usr.sbin. *** [usr.sbin.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** [buildworld] Error code 1 Stop in /src. TB --- 2013-05-10 23:47:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-10 23:47:25 - ERROR: failed to build world TB --- 2013-05-10 23:47:25 - 2121.22 user 388.45 system 2533.12 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Fri May 10 23:47:58 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0181B340; Fri, 10 May 2013 23:47:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id A866BE99; Fri, 10 May 2013 23:47:57 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r4ANlvel031701; Fri, 10 May 2013 23:47:57 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r4ANlvc7031699; Fri, 10 May 2013 23:47:57 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 10 May 2013 23:47:57 GMT Message-Id: <201305102347.r4ANlvc7031699@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 23:47:58 -0000 TB --- 2013-05-10 23:05:12 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-05-10 23:05:12 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-10 23:05:12 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2013-05-10 23:05:12 - cleaning the object tree TB --- 2013-05-10 23:05:12 - /usr/local/bin/svn stat /src TB --- 2013-05-10 23:05:15 - At svn revision 250487 TB --- 2013-05-10 23:05:16 - building world TB --- 2013-05-10 23:05:16 - CROSS_BUILD_TESTING=YES TB --- 2013-05-10 23:05:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-10 23:05:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-10 23:05:16 - SRCCONF=/dev/null TB --- 2013-05-10 23:05:16 - TARGET=i386 TB --- 2013-05-10 23:05:16 - TARGET_ARCH=i386 TB --- 2013-05-10 23:05:16 - TZ=UTC TB --- 2013-05-10 23:05:16 - __MAKE_CONF=/dev/null TB --- 2013-05-10 23:05:16 - cd /src TB --- 2013-05-10 23:05:16 - /usr/bin/make -B buildworld >>> World build started on Fri May 10 23:05:17 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -fstack-protector -c /src/usr.sbin/ndp/../../contrib/tcpdump/gmt2local.c cc -O2 -pipe -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -fstack-protector -o ndp ndp.o gmt2local.o gzip -cn /src/usr.sbin/ndp/ndp.8 > ndp.8.gz ===> usr.sbin/newsyslog (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/newsyslog.c cc1: warnings being treated as errors /src/usr.sbin/newsyslog/newsyslog.c: In function 'delete_oldest_timelog': /src/usr.sbin/newsyslog/newsyslog.c:1511: warning: unused variable 'valid' *** [newsyslog.o] Error code 1 Stop in /src/usr.sbin/newsyslog. *** [all] Error code 1 Stop in /src/usr.sbin. *** [usr.sbin.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** [buildworld] Error code 1 Stop in /src. TB --- 2013-05-10 23:47:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-10 23:47:57 - ERROR: failed to build world TB --- 2013-05-10 23:47:57 - 2147.98 user 386.24 system 2565.10 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Fri May 10 23:48:22 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E73E0458; Fri, 10 May 2013 23:48:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 9C211EA4; Fri, 10 May 2013 23:48:22 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r4ANmMVZ043292; Fri, 10 May 2013 23:48:22 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r4ANmMCJ043281; Fri, 10 May 2013 23:48:22 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 10 May 2013 23:48:22 GMT Message-Id: <201305102348.r4ANmMCJ043281@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 23:48:23 -0000 TB --- 2013-05-10 23:05:12 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-05-10 23:05:12 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-10 23:05:12 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2013-05-10 23:05:12 - cleaning the object tree TB --- 2013-05-10 23:05:12 - /usr/local/bin/svn stat /src TB --- 2013-05-10 23:05:15 - At svn revision 250487 TB --- 2013-05-10 23:05:16 - building world TB --- 2013-05-10 23:05:16 - CROSS_BUILD_TESTING=YES TB --- 2013-05-10 23:05:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-10 23:05:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-10 23:05:16 - SRCCONF=/dev/null TB --- 2013-05-10 23:05:16 - TARGET=amd64 TB --- 2013-05-10 23:05:16 - TARGET_ARCH=amd64 TB --- 2013-05-10 23:05:16 - TZ=UTC TB --- 2013-05-10 23:05:16 - __MAKE_CONF=/dev/null TB --- 2013-05-10 23:05:16 - cd /src TB --- 2013-05-10 23:05:16 - /usr/bin/make -B buildworld >>> World build started on Fri May 10 23:05:17 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -fstack-protector -c /src/usr.sbin/ndp/../../contrib/tcpdump/gmt2local.c cc -O2 -pipe -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -fstack-protector -o ndp ndp.o gmt2local.o gzip -cn /src/usr.sbin/ndp/ndp.8 > ndp.8.gz ===> usr.sbin/newsyslog (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/newsyslog.c cc1: warnings being treated as errors /src/usr.sbin/newsyslog/newsyslog.c: In function 'delete_oldest_timelog': /src/usr.sbin/newsyslog/newsyslog.c:1511: warning: unused variable 'valid' *** [newsyslog.o] Error code 1 Stop in /src/usr.sbin/newsyslog. *** [all] Error code 1 Stop in /src/usr.sbin. *** [usr.sbin.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** [buildworld] Error code 1 Stop in /src. TB --- 2013-05-10 23:48:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-10 23:48:22 - ERROR: failed to build world TB --- 2013-05-10 23:48:22 - 2162.48 user 393.04 system 2590.05 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sat May 11 00:00:00 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7C9A974C; Sat, 11 May 2013 00:00:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 31772F0B; Sat, 11 May 2013 00:00:00 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r4ANxxDL078991; Fri, 10 May 2013 23:59:59 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r4ANxxrS078970; Fri, 10 May 2013 23:59:59 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 10 May 2013 23:59:59 GMT Message-Id: <201305102359.r4ANxxrS078970@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 00:00:00 -0000 TB --- 2013-05-10 23:05:12 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-05-10 23:05:12 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-10 23:05:12 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2013-05-10 23:05:12 - cleaning the object tree TB --- 2013-05-10 23:05:12 - /usr/local/bin/svn stat /src TB --- 2013-05-10 23:05:15 - At svn revision 250487 TB --- 2013-05-10 23:05:16 - building world TB --- 2013-05-10 23:05:16 - CROSS_BUILD_TESTING=YES TB --- 2013-05-10 23:05:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-10 23:05:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-10 23:05:16 - SRCCONF=/dev/null TB --- 2013-05-10 23:05:16 - TARGET=ia64 TB --- 2013-05-10 23:05:16 - TARGET_ARCH=ia64 TB --- 2013-05-10 23:05:16 - TZ=UTC TB --- 2013-05-10 23:05:16 - __MAKE_CONF=/dev/null TB --- 2013-05-10 23:05:16 - cd /src TB --- 2013-05-10 23:05:16 - /usr/bin/make -B buildworld >>> World build started on Fri May 10 23:05:17 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -c /src/usr.sbin/ndp/../../contrib/tcpdump/gmt2local.c cc -O2 -pipe -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -o ndp ndp.o gmt2local.o gzip -cn /src/usr.sbin/ndp/ndp.8 > ndp.8.gz ===> usr.sbin/newsyslog (all) cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/newsyslog.c cc1: warnings being treated as errors /src/usr.sbin/newsyslog/newsyslog.c: In function 'delete_oldest_timelog': /src/usr.sbin/newsyslog/newsyslog.c:1511: warning: unused variable 'valid' *** [newsyslog.o] Error code 1 Stop in /src/usr.sbin/newsyslog. *** [all] Error code 1 Stop in /src/usr.sbin. *** [usr.sbin.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** [buildworld] Error code 1 Stop in /src. TB --- 2013-05-10 23:59:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-10 23:59:59 - ERROR: failed to build world TB --- 2013-05-10 23:59:59 - 2852.12 user 412.70 system 3287.60 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Sat May 11 00:19:37 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 66677DEC; Sat, 11 May 2013 00:19:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 182FFFA7; Sat, 11 May 2013 00:19:37 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r4B0Ja1m050193; Sat, 11 May 2013 00:19:36 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r4B0JaCv050188; Sat, 11 May 2013 00:19:36 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 11 May 2013 00:19:36 GMT Message-Id: <201305110019.r4B0JaCv050188@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 00:19:37 -0000 TB --- 2013-05-10 23:38:53 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-05-10 23:38:53 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-10 23:38:53 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2013-05-10 23:38:53 - cleaning the object tree TB --- 2013-05-10 23:38:53 - /usr/local/bin/svn stat /src TB --- 2013-05-10 23:38:55 - At svn revision 250487 TB --- 2013-05-10 23:38:56 - building world TB --- 2013-05-10 23:38:56 - CROSS_BUILD_TESTING=YES TB --- 2013-05-10 23:38:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-10 23:38:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-10 23:38:56 - SRCCONF=/dev/null TB --- 2013-05-10 23:38:56 - TARGET=sparc64 TB --- 2013-05-10 23:38:56 - TARGET_ARCH=sparc64 TB --- 2013-05-10 23:38:56 - TZ=UTC TB --- 2013-05-10 23:38:56 - __MAKE_CONF=/dev/null TB --- 2013-05-10 23:38:56 - cd /src TB --- 2013-05-10 23:38:56 - /usr/bin/make -B buildworld >>> World build started on Fri May 10 23:38:56 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -fstack-protector -c /src/usr.sbin/ndp/../../contrib/tcpdump/gmt2local.c cc -O2 -pipe -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -fstack-protector -o ndp ndp.o gmt2local.o gzip -cn /src/usr.sbin/ndp/ndp.8 > ndp.8.gz ===> usr.sbin/newsyslog (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/newsyslog.c cc1: warnings being treated as errors /src/usr.sbin/newsyslog/newsyslog.c: In function 'delete_oldest_timelog': /src/usr.sbin/newsyslog/newsyslog.c:1511: warning: unused variable 'valid' *** [newsyslog.o] Error code 1 Stop in /src/usr.sbin/newsyslog. *** [all] Error code 1 Stop in /src/usr.sbin. *** [usr.sbin.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** [buildworld] Error code 1 Stop in /src. TB --- 2013-05-11 00:19:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-11 00:19:36 - ERROR: failed to build world TB --- 2013-05-11 00:19:36 - 2036.98 user 363.34 system 2443.49 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sat May 11 00:21:03 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8F7C3F29; Sat, 11 May 2013 00:21:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 44AEDFC0; Sat, 11 May 2013 00:21:03 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r4B0L2Ow078743; Sat, 11 May 2013 00:21:02 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r4B0L22T078742; Sat, 11 May 2013 00:21:02 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 11 May 2013 00:21:02 GMT Message-Id: <201305110021.r4B0L22T078742@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 00:21:03 -0000 TB --- 2013-05-10 23:38:23 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-05-10 23:38:23 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-10 23:38:23 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2013-05-10 23:38:23 - cleaning the object tree TB --- 2013-05-10 23:38:23 - /usr/local/bin/svn stat /src TB --- 2013-05-10 23:38:25 - At svn revision 250487 TB --- 2013-05-10 23:38:26 - building world TB --- 2013-05-10 23:38:26 - CROSS_BUILD_TESTING=YES TB --- 2013-05-10 23:38:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-10 23:38:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-10 23:38:26 - SRCCONF=/dev/null TB --- 2013-05-10 23:38:26 - TARGET=powerpc TB --- 2013-05-10 23:38:26 - TARGET_ARCH=powerpc TB --- 2013-05-10 23:38:26 - TZ=UTC TB --- 2013-05-10 23:38:26 - __MAKE_CONF=/dev/null TB --- 2013-05-10 23:38:26 - cd /src TB --- 2013-05-10 23:38:26 - /usr/bin/make -B buildworld >>> World build started on Fri May 10 23:38:27 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -fstack-protector -c /src/usr.sbin/ndp/../../contrib/tcpdump/gmt2local.c cc -O2 -pipe -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -fstack-protector -o ndp ndp.o gmt2local.o gzip -cn /src/usr.sbin/ndp/ndp.8 > ndp.8.gz ===> usr.sbin/newsyslog (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/newsyslog.c cc1: warnings being treated as errors /src/usr.sbin/newsyslog/newsyslog.c: In function 'delete_oldest_timelog': /src/usr.sbin/newsyslog/newsyslog.c:1511: warning: unused variable 'valid' *** [newsyslog.o] Error code 1 Stop in /src/usr.sbin/newsyslog. *** [all] Error code 1 Stop in /src/usr.sbin. *** [usr.sbin.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** [buildworld] Error code 1 Stop in /src. TB --- 2013-05-11 00:21:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-11 00:21:02 - ERROR: failed to build world TB --- 2013-05-11 00:21:02 - 2160.27 user 369.84 system 2559.17 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sat May 11 00:30:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8F8E3148 for ; Sat, 11 May 2013 00:30:25 +0000 (UTC) (envelope-from kiri@pis.elm.toba-cmt.ac.jp) Received: from pis.elm.toba-cmt.ac.jp (pis.elm.toba-cmt.ac.jp [202.26.248.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0AA346F for ; Sat, 11 May 2013 00:30:24 +0000 (UTC) Received: from kiri.pis.pis.elm.toba-cmt.ac.jp (kiri.pis [192.168.1.1] (may be forged)) by pis.elm.toba-cmt.ac.jp (8.14.5/8.14.5) with ESMTP id r4B0UFlX084168; Sat, 11 May 2013 09:30:15 +0900 (JST) (envelope-from kiri@pis.elm.toba-cmt.ac.jp) Message-Id: <201305110030.r4B0UFlX084168@pis.elm.toba-cmt.ac.jp> Date: Sat, 11 May 2013 09:30:15 +0900 From: KIRIYAMA Kazuhiko To: freebsd-stable@freebsd.org Subject: How abuot firewall_nat_rules? User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.6 MULE XEmacs/21.4 (patch 22) (Instant Classic) (amd64--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: kiri@pis.elm.toba-cmt.ac.jp X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 00:30:25 -0000 Hi stable list, Now ipfw_nat's rules must be write directly in firewall_nat_flags. This is messy to describe many rules. firewall_nat_rules will be treat smartly. To enable firewall_nat_rules,apply following patch to /etc/rc.firewall --- /etc/rc.firewall.org 2013-05-11 08:23:13.000000000 +0900 +++ /etc/rc.firewall 2013-05-11 08:29:11.000000000 +0900 @@ -162,6 +162,9 @@ case ${firewall_nat_enable} in [Yy][Ee][Ss]) if [ -n "${firewall_nat_interface}" ]; then + if [ -r "${firewall_nat_rules}" ]; then + firewall_nat_flags="${firewall_nat_flags} `cat ${firewall_nat_rules}`" + fi if echo "${firewall_nat_interface}" | \ grep -q -E '^[0-9]+(\.[0-9]+){0,3}$'; then firewall_nat_flags="ip ${firewall_nat_interface} ${firewall_nat_flags}" and then put in /etc/rc.conf firewall_enable="YES" firewall_type="OPEN" firewall_nat_enable="YES" firewall_nat_interface="X.X.X.X" firewall_nat_flags="deny_in reset same_ports unreg_only" firewall_nat_rules="/etc/ipfw_nat.rules" where X.X.X.X is the outgoing global address and firewall_nat_rules specfies the file in which describe ipfw_nat's rules, actually ipfw arguments following to "${fwcmd} nat 123 config log" for example redirect_port tcp 192.168.1.7:2401 2401 redirect_port tcp 192.168.1.5:80 80 redirect_port tcp 192.168.1.1:22 22069 redirect_port tcp 192.168.1.2:22 22053 redirect_port tcp 192.168.1.3:22 22025 redirect_port tcp 192.168.1.4:22 22080 redirect_port tcp 192.168.1.5:22 22021 redirect_port tcp 192.168.1.6:22 22067 redirect_port tcp 192.168.1.7:22 22401 redirect_port tcp 192.168.1.8:22 22081 redirect_port tcp 192.168.1.32:9100 63189 redirect_port tcp 192.168.1.252:9100 23089 redirect_port tcp 192.168.1.254:22 22 Regards --- kiri@openedu.org From owner-freebsd-stable@FreeBSD.ORG Sat May 11 22:55:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8F58DC70 for ; Sat, 11 May 2013 22:55:02 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) by mx1.freebsd.org (Postfix) with ESMTP id 6AF47DB8 for ; Sat, 11 May 2013 22:55:02 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id g10so3502997pdj.8 for ; Sat, 11 May 2013 15:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=F7PQ69qokh6aELKFL7xOZwsyX+emmAS2ubA1OOcYoaw=; b=XqkKP/TEqlOmSNxHRe+DquBLdou+kC2fuguw9mwJqtMyN979xxpX7PAn1skZyWLk7p yt9xS+t9rs2sxQtG1wcjraBlOCXYna8//diK/BGgcbDHdxbGSnAEf7F5igQSRK0J5fKL 1jnJ4mp/GhvJ966070GWAd0wpib8y5tZn/afQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=F7PQ69qokh6aELKFL7xOZwsyX+emmAS2ubA1OOcYoaw=; b=pCEJ4p+C0/ws+zOg385aAHOzHFByWxXjwKCpqTuJvne8zGihe7pBiwvEbsUWbc5n7y 0P17JMxQFZb1cy5tRlcQYuZTTO9/i9PIxCVSbONDVDdj6hUM0uQoaAk8R3q9HRhP8ggo c4QFcc4WFgJUg2I+bjuMy+Zox8yFmTMC1diQZKypu74xJXEusIh7/kb3rOCAbh5bdBov Eyx+J9QteWpg0Go3nL30aZqmTXggYbtRzdInmpkrs2UU2ffljeoeH7vfw6sRXapxckBD TI6AbF3zO0UHPznngoE+lFGR2Pds108xtJqQf9fdoeWr63BM7sJuSxJSdIHrfNOuSs3R VhBg== X-Received: by 10.69.0.226 with SMTP id bb2mr23156593pbd.34.1368312896847; Sat, 11 May 2013 15:54:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.192.42 with HTTP; Sat, 11 May 2013 15:54:26 -0700 (PDT) In-Reply-To: <87178.1368219589@server1.tristatelogic.com> References: <87178.1368219589@server1.tristatelogic.com> From: Eitan Adler Date: Sat, 11 May 2013 18:54:26 -0400 Message-ID: Subject: Re: bin/152154: script(1) -k malfunctions with certain shells (e.g. tcsh, bash, zsh) To: "Ronald F. Guilmette" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmw/Xqnp8kuUFO3aeYj8AKNLpA7W4XilpBko7e/KnqwC/7m60RJBn/leNyi9V8M8fKGSzF+ Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 22:55:02 -0000 On 10 May 2013 16:59, Ronald F. Guilmette wrote: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/152154 > > It has been suggested to me (by a committer) that I should raise the > issue of this PR here on these lists, because the problem described > within the PR remains a real problem, and despite my having proposed > something that seems to be a perfectly workable fix, no action has > been taken on this PR for some years now. By the way, it will go a long way to helping get some site on these PRs, if you provide diffs in 'unified diff' form (diff -u) instead of context diff form. I have been recently looking for old PRs with patches attached. :) -- Eitan Adler From owner-freebsd-stable@FreeBSD.ORG Sat May 11 23:14:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 44850143 for ; Sat, 11 May 2013 23:14:22 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) by mx1.freebsd.org (Postfix) with ESMTP id C68ACE72 for ; Sat, 11 May 2013 23:14:21 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 25616 invoked from network); 12 May 2013 01:14:20 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1368314060; bh=MMK4v3w4OTYaS0JSxRBUsnPBwmR2KYiSn1lTNXrmwFE=; h=From:To:Subject; b=pZAdioNKpKlah604eresa3UY9oWcOv0gYoIGYz9jhX0Dxiia21Dz2ZVas9GRYEkjC /UFCZg3x26x+jj2HDw3KDcQVjVyo4MQwpAQdX41jyTPNMdy+RnourVR93qsi1TShng 9z4nxlzybCoEdtjaF/XBcq5TA4hs7gxZCY5aQsw4= Received: from nat.misal.pl (HELO [127.0.0.1]) (marek_sal@[83.19.131.171]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP for ; 12 May 2013 01:14:20 +0200 Message-ID: <518ED0CA.4030007@wp.pl> Date: Sun, 12 May 2013 01:14:18 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "freebsd-stable@freebsd.org" Subject: Build GENERIC with IPX support Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130511-1, 2013-05-11), Outbound message X-Antivirus-Status: Clean X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [IRNU] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 23:14:22 -0000 Hi list, I am using 9.1-RELEASE amd64 FreeBSD I order to connect my FreeBSD box to NetWare servers, I am trying to recompile the kernel. To GENERIC config I've added following options: options IPX options NCP options NWFS unfortunately, during buildkernel process I got an error: nwfs_subr.o: In function `ncp_lookup_volume': /usr/src/sys/fs/nwfs/nwfs_subr.c:499: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:500: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:501: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:502: undefined reference to `mb_put_uint16le' /usr/src/sys/fs/nwfs/nwfs_subr.c:504: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:505: undefined reference to `mb_put_uint32be' /usr/src/sys/fs/nwfs/nwfs_subr.c:506: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:507: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:512: undefined reference to `md_get_uint32le' /usr/src/sys/fs/nwfs/nwfs_subr.c:513: undefined reference to `md_get_uint32le' /usr/src/sys/fs/nwfs/nwfs_subr.c:514: undefined reference to `md_get_uint8' nwfs_subr.o: In function `ncp_get_namespaces': /usr/src/sys/fs/nwfs/nwfs_subr.c:237: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:238: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:239: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:240: undefined reference to `mb_put_uint16le' /usr/src/sys/fs/nwfs/nwfs_subr.c:241: undefined reference to `mb_put_uint32le' /usr/src/sys/fs/nwfs/nwfs_subr.c:242: undefined reference to `mb_put_uint32le' /usr/src/sys/fs/nwfs/nwfs_subr.c:247: undefined reference to `mb_put_uint16le' /usr/src/sys/fs/nwfs/nwfs_subr.c:255: undefined reference to `md_get_uint32le' /usr/src/sys/fs/nwfs/nwfs_subr.c:256: undefined reference to `md_get_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:257: undefined reference to `md_get_uint8' nwfs_subr.o: In function `ncp_setattr': /usr/src/sys/fs/nwfs/nwfs_subr.c:393: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:394: undefined reference to `mb_put_mem' /usr/src/sys/fs/nwfs/nwfs_subr.c:395: undefined reference to `mb_put_uint32be' /usr/src/sys/fs/nwfs/nwfs_subr.c:396: undefined reference to `mb_put_uint16be' nwfs_subr.o: In function `ncp_search_for_file_or_subdir': /usr/src/sys/fs/nwfs/nwfs_subr.c:110: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:111: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:112: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:113: undefined reference to `mb_put_uint16le' /usr/src/sys/fs/nwfs/nwfs_subr.c:114: undefined reference to `mb_put_uint32le' /usr/src/sys/fs/nwfs/nwfs_subr.c:115: undefined reference to `mb_put_mem' /usr/src/sys/fs/nwfs/nwfs_subr.c:116: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:117: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:118: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:123: undefined reference to `md_get_mem' /usr/src/sys/fs/nwfs/nwfs_subr.c:124: undefined reference to `md_get_uint8' nwfs_subr.o: In function `ncp_obtain_info': /usr/src/sys/fs/nwfs/nwfs_subr.c:152: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:153: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:154: undefined reference to `mb_put_uint8' /usr/src/sys/fs/nwfs/nwfs_subr.c:155: undefined reference to `mb_put_uint16le' /usr/src/sys/fs/nwfs/nwfs_subr.c:156: undefined reference to `mb_put_uint32le' ncp_mod.o: In function `sncp_request': /usr/src/sys/netncp/ncp_mod.c:157: undefined reference to `mb_put_mem' /usr/src/sys/netncp/ncp_mod.c:165: undefined reference to `md_get_mem' ncp_mod.o: In function `ncp_conn_frag_rq': /usr/src/sys/netncp/ncp_mod.c:450: undefined reference to `mb_put_mem' /usr/src/sys/netncp/ncp_mod.c:465: undefined reference to `md_get_mem' ncp_ncp.o: In function `ncp_negotiate_buffersize': /usr/src/sys/netncp/ncp_ncp.c:164: undefined reference to `mb_put_uint16be' /usr/src/sys/netncp/ncp_ncp.c:168: undefined reference to `md_get_uint16be' ncp_ncp.o: In function `ncp_get_encryption_key': /usr/src/sys/netncp/ncp_ncp.c:312: undefined reference to `md_get_mem' ncp_ncp.o: In function `ncp_login_unencrypted': /usr/src/sys/netncp/ncp_ncp.c:388: undefined reference to `mb_put_uint16be' ncp_ncp.o: In function `ncp_login_encrypted': /usr/src/sys/netncp/ncp_ncp.c:363: undefined reference to `mb_put_mem' /usr/src/sys/netncp/ncp_ncp.c:364: undefined reference to `mb_put_uint16be' ncp_ncp.o: In function `ncp_get_bindery_object_id': /usr/src/sys/netncp/ncp_ncp.c:283: undefined reference to `mb_put_uint16be' /usr/src/sys/netncp/ncp_ncp.c:289: undefined reference to `md_get_uint32be' /usr/src/sys/netncp/ncp_ncp.c:290: undefined reference to `md_get_uint16be' /usr/src/sys/netncp/ncp_ncp.c:291: undefined reference to `md_get_mem' ncp_ncp.o: In function `ncp_negotiate_size_and_options': /usr/src/sys/netncp/ncp_ncp.c:185: undefined reference to `mb_put_uint16be' /usr/src/sys/netncp/ncp_ncp.c:186: undefined reference to `mb_put_uint8' /usr/src/sys/netncp/ncp_ncp.c:191: undefined reference to `md_get_uint16be' /usr/src/sys/netncp/ncp_ncp.c:193: undefined reference to `md_get_uint16be' /usr/src/sys/netncp/ncp_ncp.c:194: undefined reference to `md_get_uint8' ncp_ncp.o: In function `ncp_write': /usr/src/sys/netncp/ncp_ncp.c:470: undefined reference to `mb_put_uint8' /usr/src/sys/netncp/ncp_ncp.c:471: undefined reference to `mb_put_mem' /usr/src/sys/netncp/ncp_ncp.c:472: undefined reference to `mb_put_uint32be' /usr/src/sys/netncp/ncp_ncp.c:473: undefined reference to `mb_put_uint16be' /usr/src/sys/netncp/ncp_ncp.c:474: undefined reference to `mb_put_uio' ncp_ncp.o: In function `ncp_read': /usr/src/sys/netncp/ncp_ncp.c:431: undefined reference to `md_get_uio' /usr/src/sys/netncp/ncp_ncp.c:420: undefined reference to `mb_put_uint8' /usr/src/sys/netncp/ncp_ncp.c:421: undefined reference to `mb_put_mem' /usr/src/sys/netncp/ncp_ncp.c:422: undefined reference to `mb_put_uint32be' /usr/src/sys/netncp/ncp_ncp.c:423: undefined reference to `mb_put_uint16be' /usr/src/sys/netncp/ncp_ncp.c:428: undefined reference to `md_get_uint16be' /usr/src/sys/netncp/ncp_ncp.c:430: undefined reference to `md_get_mem' ncp_rq.o: In function `ncp_request_int': /usr/src/sys/netncp/ncp_rq.c:281: undefined reference to `mb_fixhdr' /usr/src/sys/netncp/ncp_rq.c:409: undefined reference to `md_initm' /usr/src/sys/netncp/ncp_rq.c:420: undefined reference to `md_get_mem' ncp_rq.o: In function `ncp_sign_packet': /usr/src/sys/netncp/ncp_rq.c:239: undefined reference to `mb_put_mem' ncp_rq.o: In function `ncp_rq_pathstring': /usr/src/sys/netncp/ncp_rq.c:172: undefined reference to `mb_put_uint8' ncp_rq.o: In function `ncp_rq_dbase_path': /usr/src/sys/netncp/ncp_rq.c:199: undefined reference to `mb_put_uint8' /usr/src/sys/netncp/ncp_rq.c:200: undefined reference to `mb_put_mem' /usr/src/sys/netncp/ncp_rq.c:201: undefined reference to `mb_put_uint8' /usr/src/sys/netncp/ncp_rq.c:217: undefined reference to `mb_put_uint8' /usr/src/sys/netncp/ncp_rq.c:218: undefined reference to `mb_put_uint8' /usr/src/sys/netncp/ncp_rq.c:213: undefined reference to `mb_put_uint8' /usr/src/sys/netncp/ncp_rq.c:205: undefined reference to `mb_put_uint8' ncp_rq.o:/usr/src/sys/netncp/ncp_rq.c:208: more undefined references to `mb_put_uint8' follow ncp_rq.o: In function `ncp_rq_dbase_path': /usr/src/sys/netncp/ncp_rq.c:209: undefined reference to `mb_put_mem' ncp_rq.o: In function `ncp_rq_pstring': /usr/src/sys/netncp/ncp_rq.c:186: undefined reference to `mb_put_uint8' ncp_rq.o: In function `ncp_rq_done': /usr/src/sys/netncp/ncp_rq.c:138: undefined reference to `mb_done' /usr/src/sys/netncp/ncp_rq.c:139: undefined reference to `md_done' ncp_rq.o: In function `ncp_rq_init_any': /usr/src/sys/netncp/ncp_rq.c:116: undefined reference to `mb_init' /usr/src/sys/netncp/ncp_rq.c:125: undefined reference to `mb_reserve' /usr/src/sys/netncp/ncp_rq.c:120: undefined reference to `mb_reserve' ncp_rq.o: In function `ncp_rq_alloc_subfn': /usr/src/sys/netncp/ncp_rq.c:92: undefined reference to `mb_reserve' /usr/src/sys/netncp/ncp_rq.c:93: undefined reference to `mb_put_uint8' ncp_rq.o: In function `ncp_rq_pathstring': /usr/src/sys/netncp/ncp_rq.c:175: undefined reference to `mb_put_mem' ncp_rq.o: In function `ncp_rq_pstring': /usr/src/sys/netncp/ncp_rq.c:189: undefined reference to `mb_put_mem' *** [kernel.debug] Error code 1 Stop in /tmp/obj/usr/src/sys/GENERICIPX. *** [buildkernel] Error code 1 Stop in /usr/src. *** [buildkernel] Error code 1 Stop in /usr/src. 641.92s user 284.90s system 102% cpu 15:03.37s total marek@bsd-gen:/usr/src% Does anyone still uses IPX and could help me compiling the kernel ? Regards, -- Marek Salwerowicz