From owner-freebsd-fs@FreeBSD.ORG Sun Aug 17 00:34:14 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28E19162 for ; Sun, 17 Aug 2014 00:34:14 +0000 (UTC) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A22832E74 for ; Sun, 17 Aug 2014 00:34:13 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id s18so3460625lam.28 for ; Sat, 16 Aug 2014 17:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FHayqX3xM1XASYG2NawYhnoKpPUKKHwh9jQTrb2gARM=; b=oHGgi1o6Nt7GTCVP+NiqY2TqjS1mpq2tmGpvMdWX8kZv6yyj8VH4wI9KBAD0R7pjBw 2pv2K1g+fTHjq2lFhCXjcMkDINe9rIxT96qeHUIljCXi77hI5S62TlbCyLx4SV2dGV7H toxzxk3zhAA4UwqdmVIhk1KPhQvxy2cG1WaOMzghWv7yyJJVbVMCOh8OGJQ+l+C9KFqU 8nJbcWBFDoCGMhK4Cr+ll0XPcEBu//dDMcHCxgPtT9RDtywDRuJbF4ZrJXOnZ8H11VJn mGl2wjEiSG5oELiId8qc9/Cu5DpLlo4PTsX8hQyxZV1tVSNgbzVK8Bba9XmBptMAa6nY N2oA== X-Received: by 10.112.118.68 with SMTP id kk4mr8568481lbb.4.1408235651132; Sat, 16 Aug 2014 17:34:11 -0700 (PDT) Received: from [192.168.6.21] (ppp-62-216-218-181.dynamic.mnet-online.de. [62.216.218.181]) by mx.google.com with ESMTPSA id kh9sm19767150lbc.5.2014.08.16.17.34.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Aug 2014 17:34:10 -0700 (PDT) Message-ID: <53EFF87F.7080507@gmail.com> Date: Sun, 17 Aug 2014 02:34:07 +0200 From: Thomas Schweikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Thunderbird/34.0a1 MIME-Version: 1.0 To: Anton Sayetsky Subject: Re: zfs only mounting "root" after reboot References: <53EF3036.8050203@gmail.com> In-Reply-To: <53EF3036.8050203@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 00:34:14 -0000 On 16.08.2014 12:19, Thomas Schweikle wrote: > On 16.08.2014 11:12, Anton Sayetsky wrote: >> man rc.conf >> /zfs_enable > > This is allso set -- just forgot to mention it: > # cat /etc/rc.conf > [...] > zfs_enable="YES" > After digging deep into how FreeBSD boots if zfs is used as root I found the solution to this problem. It is with any special filesystem like "linproc", "fdesc", or others you might use, as long as these are mounted to someting *not* in zfs:zroot. FreeBSD mount only zfs:zroot, then, after doing some work not requiring any of /tmp, /usr or /var. Then mounts everything given in fstab with "mount -a" except those marked with option "late". After having done that all further zfs:zroot mountpoints are processed by executing "zfs mount -a". Last thing done is mounting everything marked with "late" in fstab by "mount -al". Since some of these special filesystems require /tmp, /usr or /var being mounted this fails and FreeBSD bails out into a single user shell. The solution is to move mounting these later in the boot process, after /tmp, /usr or /var are mounted. This is done by adding option "late" to these file systems, as given below # cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/acd0 /cdrom cd9660 ro,noauto 0 0 # linproc /compat/linux/proc linprocfs rw,auto,late 0 0 fdesc /dev/fd fdescfs rw,auto,late 0 0 # /dev/gpt/swap0 none swap sw 0 0 I think this shall be mentioned in the FreeBSD handbook, but couldn't find any hint to it. Is it a bug with zfs mounting? Is it intended to have zfs mounts happen before working on fstab mounts? If not, it could be useful to make more clear what happens and that you *must* mark filesystems depending on /tmp, /usr or /var to mount "late"! -- Thomas From owner-freebsd-fs@FreeBSD.ORG Sun Aug 17 00:42:49 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60ABE31E for ; Sun, 17 Aug 2014 00:42:49 +0000 (UTC) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F22D52FFF for ; Sun, 17 Aug 2014 00:42:48 +0000 (UTC) X-AuditID: 1209190d-f79c06d000002f07-80-53eff953f3f5 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 34.21.12039.359FFE35; Sat, 16 Aug 2014 20:37:39 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s7H0bcom026144; Sat, 16 Aug 2014 20:37:39 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7H0bbmo026137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 16 Aug 2014 20:37:38 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7H0batC007547; Sat, 16 Aug 2014 20:37:36 -0400 (EDT) Date: Sat, 16 Aug 2014 20:37:36 -0400 (EDT) From: Benjamin Kaduk To: Thomas Schweikle Subject: Re: zfs only mounting "root" after reboot In-Reply-To: <53EFF87F.7080507@gmail.com> Message-ID: References: <53EF3036.8050203@gmail.com> <53EFF87F.7080507@gmail.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixCmqrRv8832wwZt7ShbHHv9ks7hw+C27 A5PHjE/zWTx2zrrLHsAUxWWTkpqTWZZapG+XwJXx5d4i9oIXrBVTHn1nbmC8wNLFyMkhIWAi cf3LUkYIW0ziwr31bCC2kMBsJomTrzO6GLmA7I2MEuf3trFCOIeYJH687WKDcBoYJY4uuwg2 ikVAW+Lv5PWsIDabgIrEzDcbwUaJAMXfPjzMDmIzC6hLNDRNAbOFBYwkWu5vArM5BTQljhx+ wARi8wo4SrxcsR9qwXlGiRN3G8HuExXQkVi9fwoLRJGgxMmZT1gghmpJLJ++jWUCo+AsJKlZ SFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrp5WaW6KWmlG5iBAerJO8OxncHlQ4xCnAw KvHwCvS9DxZiTSwrrsw9xCjJwaQkysv7AyjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhPfPPqAc b0piZVVqUT5MSpqDRUmc9621VbCQQHpiSWp2ampBahFMVoaDQ0mC9/l3oEbBotT01Iq0zJwS hDQTByfIcB6g4Q4gi3mLCxJzizPTIfKnGHU5Wpre9jIJseTl56VKifN+BxkkAFKUUZoHNweW ZF4xigO9JcwrBzKKB5ig4Ca9AlrCBLSkZvNbkCUliQgpqQZGVTO2rZITLpbc6Y8yfsTfP+3q VoVnL547Tii/w/Y0RqLQ4mJejnuNtY+Eq3NIxZrNT5Z/0BFiuqMbeXDO9T7DEnldocOd9202 9LIvrzZKZDwaush4ka/6AVmDvd8uPt/XddN6nvHPnuC3S1rK/t2zlqi6skf78ATzBQ5lj4Va j09OdI1XueSmxFKckWioxVxUnAgAvDjnxA0DAAA= Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 00:42:49 -0000 On Sat, 16 Aug 2014, Thomas Schweikle wrote: > I think this shall be mentioned in the FreeBSD handbook, but > couldn't find any hint to it. Is it a bug with zfs mounting? Is it > intended to have zfs mounts happen before working on fstab mounts? > If not, it could be useful to make more clear what happens and that > you *must* mark filesystems depending on /tmp, /usr or /var to mount > "late"! Traditionally, filesystem implementations have not had dependencies on the presence of other filesystems in the mount hierarchy. It is completely unsurprising that the documentation does not cover such behavior. Do you have notes handy for why fdesc and linproc have such dependencies and what they are? Thanks, Ben Kaduk From owner-freebsd-fs@FreeBSD.ORG Sun Aug 17 01:27:47 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0142CC8F for ; Sun, 17 Aug 2014 01:27:46 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79B7F23E5 for ; Sun, 17 Aug 2014 01:27:46 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id u10so3009940lbd.21 for ; Sat, 16 Aug 2014 18:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=AaLBaIBO4y5HvnlDLROcei108sCrTm9lUdfWuUHKZOI=; b=vI2grBrTP9izSeiHypVoHxVKyhv4ku29vGncQ2k0KmyGMhtaoiIu7L/GNdeSa7BRFN SJml0p2FfjNdVg0RHBjVZI8Cc7ECR0CPhyPX2H/Rr/Kpg6F4C/ddwNfe3/V1+1Yxix4U dnRtXUV5k6gmLTUjO3S8dzv+eUVadVbV8K1VNGvIy59EktYBJENz3eHJjZPhbRpOAm/x b3JesrUgzUKgCgM0zg89+qNyw5tYyc38OaIblk+2bMuCU1NIdsblazuWXXvKYV8YHUPP gRfYn5E6fnAbSfgrzzuZMNKl8bmeJ6tl/kUA5X1svKSnZv/9tMPoHdo1xTUks/cAYJbu iDkw== X-Received: by 10.112.35.97 with SMTP id g1mr19878464lbj.20.1408238864307; Sat, 16 Aug 2014 18:27:44 -0700 (PDT) Received: from [192.168.6.21] (ppp-62-216-218-181.dynamic.mnet-online.de. [62.216.218.181]) by mx.google.com with ESMTPSA id um4sm10154681lbb.40.2014.08.16.18.27.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Aug 2014 18:27:43 -0700 (PDT) Message-ID: <53F0050D.6060700@gmail.com> Date: Sun, 17 Aug 2014 03:27:41 +0200 From: Thomas Schweikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Thunderbird/34.0a1 MIME-Version: 1.0 To: Benjamin Kaduk Subject: Re: zfs only mounting "root" after reboot References: <53EF3036.8050203@gmail.com> <53EFF87F.7080507@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 01:27:47 -0000 On 17.08.2014 02:37, Benjamin Kaduk wrote: > On Sat, 16 Aug 2014, Thomas Schweikle wrote: > >> I think this shall be mentioned in the FreeBSD handbook, but >> couldn't find any hint to it. Is it a bug with zfs mounting? Is it >> intended to have zfs mounts happen before working on fstab mounts? >> If not, it could be useful to make more clear what happens and that >> you *must* mark filesystems depending on /tmp, /usr or /var to mount >> "late"! > > Traditionally, filesystem implementations have not had dependencies on the > presence of other filesystems in the mount hierarchy. It is completely > unsurprising that the documentation does not cover such behavior. > > Do you have notes handy for why fdesc and linproc have such dependencies > and what they are? linprocfs -- linux compatible /proc filesystem. It is necessary for some tools from the linux world you'd like to have running under FreeBSD. It is merely the same as what FreeBSD has at /proc and is mounted at /usr/compat/linux/proc (which is linked to /compat/linux/proc traditionaly). Both deliver the same information, but with different hierarchy. fdescfs -- file descriptor filesystem. This provides access to the per process file descriptors in the global file system namespace. It is normally mounted at /dev/fd. There are some other pseudo filesystems you may or may not need to mount them -- it depends on what programs you run ...! Some of them mount to /usr/compat, some to /dev (some of them then link to /usr/compat/ -- these need /usr to be mounted). -- Thomas From owner-freebsd-fs@FreeBSD.ORG Sun Aug 17 02:57:14 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09C52C66; Sun, 17 Aug 2014 02:57:14 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3EC872A14; Sun, 17 Aug 2014 02:57:13 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id B26287D4A1; Sat, 16 Aug 2014 19:57:05 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 99196-09; Sat, 16 Aug 2014 19:57:05 -0700 (PDT) Received: from [10.8.0.34] (unknown [10.8.0.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 747667D48D; Sat, 16 Aug 2014 19:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1408244225; bh=qt4gUOfUqtuNKEddHZGqg49HA2lTMN7fAFYvXCrhcjE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=bYMYWzItDDCZSzxhoCeSwza4ERPUtedy/O3I2vFmzHyviWQldA8yxUkh2FT7/prEM HLHuDSS7zuAl34fbAMHUeX8CyYU1R2d3FolO8eIKVcPMWs4AjzEs/7AjuvHe0IEkwY /zs4OC36Q9wDZLRLIs99wAVio51dkAUY/2optjSM= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: FreeBSD support being added to GlusterFS From: Jordan Hubbard In-Reply-To: Date: Sat, 16 Aug 2014 19:57:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2F416D06-0A98-4E66-902C-ED0690A4B1C0@ixsystems.com> References: <6ADBB2BF-C7E8-4050-9278-2565A63D2EA8@gluster.org> <20140627070411.GI24440@ivaldir.etoilebsd.net> <0F20AEEC-6244-42BC-815C-1440BBBDE664@mail.turbofuzz.com> <20140629203746.GI34108@ivaldir.etoilebsd.net> <1A58F492-946F-46D4-A19E-2734F368CDAC@mail.turbofuzz.com> <0ABAE2AC-BF1B-4125-ACA9-C6177D013E25@mail.turbofuzz.com> <20140706230910.GA8523@ivaldir.etoilebsd.net> To: Harshavardhana X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 02:57:14 -0000 Thanks! Just to make sure I understand for our own ports repo in = FreeNAS-land: 1. You have updated the tarball but Baptiste is still maintaining the = port, correct? If Baptiste would like someone else to take it over, I can probably coax = one of our resident committers to do it as well. We frankly have not = been able to do any testing of glusterfs in FreeNAS yet since glusterd = just catches a signal 10 whenever any glusterfs operation is performed. = Since this is also really early BETA software, I figured the FreeBSD = port was still a bit green and I'd simply wait for it to get a bit more = mature. Now that you say you=92ve gotten a regression suite up and = running, I=92m guessing the time to really push on it in FreeNAS = 9.3-ALPHA is probably soon? 2. That said, it also sounds like updating the glusterfs port is going = to have to wait for your cmockery2 port to get accepted and committed to = the tree, since otherwise it won=92t build - is that a correct = assessment? Cheers, - Jordan On Aug 11, 2014, at 1:25 AM, Harshavardhana = wrote: > = http://download.gluster.org/pub/gluster/experimental/glusterfs-freebsd_201= 40811.tar.bz2 > - updated tar with >=20 > - libexecinfo part of glusterfs 'contrib' > - Gluster configuration changed from "/var/lib" to "/var/db" by > default for non-linux platforms. > - First attempt to get regression tests ported to FreeBSD > - Currently the build is dependent on 'cmockery2' for which i > submitted a new port request here - > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192420 (not merged > yet) >=20 > Let me know how the testing goes. >=20 > BTW as an off topic but related to GlusterFS regression tests - i have > been trying to get 'pidof' command really working on FreeBSD but seems > like its really un-usable and doesn't behave the same way as the > sysvinit `pidof` does. >=20 >=20 > On Sun, Jul 6, 2014 at 4:09 PM, Baptiste Daroussin = wrote: >> On Sun, Jul 06, 2014 at 12:13:15PM -0700, Harshavardhana wrote: >>>>=20 >>>> I can make the /usr/local/var/log/glusterfs directory and it gets = much further. That said, is there some special configure flags we = should be passing in our version of the port to properly stuff glusterfs = into /var instead? Your email tends to imply that we should be passing = =97localstatedir, which we can certainly do no problem, I=92m just = wondering if that=92s your long-term plan. Again, this is our port: = https://github.com/freenas/ports/tree/freenas/9-stable/sysutils/glusterfs >>>>=20 >>>> The fundamental issue with /usr/local is, again, that /usr/local is = read-only on FreeNAS. If there are configuration files that glusterfs = expects to be modifiable, they can=92t live anywhere in /usr/local, nor = of course can any temporary files or log files. We have made special = provisions for /etc and /var such that those can be modified, so we = basically just need to compile gluster as a =93system service=94 and put = it in the system directories (e.g. prefix is /, not /usr/local). >>>>=20 >>>=20 >>> Ah now i get it - "/usr/local" is not a requirement for "GlusterFS" = it >>> is a baggage of using "autotools" when during ./configure if you do >>> not specify --prefix - so for a standard installation under RPM it = is >>> usually the following flags are used >>>=20 >>> # ./configure --prefix=3D/usr --sysconfdir=3D/etc = --localstatedir=3D/var >>> --libdir=3D/usr/lib64 >>>=20 >>> Since FreeBSD doesn't need "/usr/lib64" you could just use for = packages >>>=20 >>> # ./configure --prefix=3D/usr --sysconfdir=3D/etc = --localstatedir=3D/var >>>=20 >>=20 >> Here is an updated version of my port >> http://people.freebsd.org/~bapt/glusterfs.diff >>=20 >> This time it passes poudriere (for those not aware of poudriere it is = for >> FreeBSD a bit like what mock is for fedora but on steroid :)) >>=20 >> What is new in there: dependency on bison that I missed the first = time, a >> dependency on libexecinfo (on non FreeBSD 10) and a build dependency = on git >> other build-aux/pkg-version is not happily catching the version >>=20 >> Tested on FreeBSD 10 >>=20 >> regards, >> Bapt >=20 >=20 >=20 > --=20 > Religious confuse piety with mere ritual, the virtuous confuse > regulation with outcomes From owner-freebsd-fs@FreeBSD.ORG Sun Aug 17 04:09:27 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D852581F for ; Sun, 17 Aug 2014 04:09:27 +0000 (UTC) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90E202192 for ; Sun, 17 Aug 2014 04:09:26 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id i8so3590447qcq.41 for ; Sat, 16 Aug 2014 21:09:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EAC9MiuQuA78EkG8BqOkn7zpgfSsA6OBHQY6x7vdEG8=; b=GoBB2dNxwUBRtRMcEFQ9NCCgmdv752c4sx838hW1OZGKt4nP2+hI6vGcIVBEMluR4Z 0QVUhG7JtRU2gDEifwIlT8PQDqSLV1C8S6BV6tnK2heWZeqEppt6vBuF5N0+MlWvVAJJ gkE51pFjxljTSNJCu5imszADVLn2MNinQOK18ZzWeD+dZs5dkYsP1pB21FODOnlCgH81 sKW2TNFG3syGPbsnzA+8iBYEoqYo0uHm+xftub59EfomLoQCdoHqFNSrDmC2SHtvYPto UBIWUf8XpJ4/OtYODQN1HvGqAVBMm+arNoAtCHcrl2Dn0XBNVCt3hondVLM5wKwx5JHG gbjQ== X-Gm-Message-State: ALoCoQmztaMW8oHrX4SuGy49QIQx7B//rPXy6Ti7g8Mu+cGlgfExObOy5Kb9CTV0knfoC3viXCNS MIME-Version: 1.0 X-Received: by 10.140.48.234 with SMTP id o97mr41429843qga.10.1408248112069; Sat, 16 Aug 2014 21:01:52 -0700 (PDT) Received: by 10.229.213.129 with HTTP; Sat, 16 Aug 2014 21:01:51 -0700 (PDT) X-Originating-IP: [73.189.167.30] In-Reply-To: <2F416D06-0A98-4E66-902C-ED0690A4B1C0@ixsystems.com> References: <6ADBB2BF-C7E8-4050-9278-2565A63D2EA8@gluster.org> <20140627070411.GI24440@ivaldir.etoilebsd.net> <0F20AEEC-6244-42BC-815C-1440BBBDE664@mail.turbofuzz.com> <20140629203746.GI34108@ivaldir.etoilebsd.net> <1A58F492-946F-46D4-A19E-2734F368CDAC@mail.turbofuzz.com> <0ABAE2AC-BF1B-4125-ACA9-C6177D013E25@mail.turbofuzz.com> <20140706230910.GA8523@ivaldir.etoilebsd.net> <2F416D06-0A98-4E66-902C-ED0690A4B1C0@ixsystems.com> Date: Sat, 16 Aug 2014 21:01:51 -0700 Message-ID: Subject: Re: FreeBSD support being added to GlusterFS From: Harshavardhana To: Jordan Hubbard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 04:09:27 -0000 On Sat, Aug 16, 2014 at 7:57 PM, Jordan Hubbard wrote: > Thanks! Just to make sure I understand for our own ports repo in FreeNAS= -land: > > 1. You have updated the tarball but Baptiste is still maintaining the por= t, correct? > This i have no idea, i saw two people providing the 'shar' file so i guessed both of them were working on it. > If Baptiste would like someone else to take it over, I can probably coax = one of our resident committers to do it as well. We frankly have not been = able to do any testing of glusterfs in FreeNAS yet since glusterd just catc= hes a signal 10 whenever any glusterfs operation is performed. Since this = is also really early BETA software, I figured the FreeBSD port was still a = bit green and I'd simply wait for it to get a bit more mature. Now that yo= u say you=E2=80=99ve gotten a regression suite up and running, I=E2=80=99m = guessing the time to really push on it in FreeNAS 9.3-ALPHA is probably soo= n? > Do you know the issue of Signal 10? - can see the logs and verify them, I have been able to run lot of tests myself - but most of it is in FreeBSD 10.0. Currently every patch submitted for GlusterFS are being smoke tested on FreeBSD and NetBSD through Jenkins CI (for compile consistency), gearing up for final regression suite compatibility. This tarball was from the master branch which has all the necessary fixes, adding to that recently we made a 'release-3.6' branch gearing up for GlusterFS 3.6.0 which would have FreeBSD support - there is one patch which is still missing from release-3.6 i.e moving off /var/lib/glusterd ---> /var/db/glusterd on non Linux platforms, which is was ported from master recently and currently under review. I have gotten bits and pieces of regression tests running, the real hurdle has been to get the pidof, pgrep functionalities right and the pidof provided in 'sysutils' seems to be not working properly. Using pgrep works for some cases and miserably fails on others. NetBSD maintainer for GlusterFS made - http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/sysutils/pidof/ - out of sysvinit Linux package, after battling the same issues - which i think should resolve those problems on FreeBSD as well, but i haven't gotten around getting it ported/tested. If some one is interested we can get the existing FreeBSD port of pidof deprecated. Another issue i saw was FUSE related which lacked FOPEN_DIRECT_IO support for which i submitted a patch yesterday to get GlusterFS internal "meta" module working, here is the relevant PR - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192701 > 2. That said, it also sounds like updating the glusterfs port is going to= have to wait for your cmockery2 port to get accepted and committed to the = tree, since otherwise it won=E2=80=99t build - is that a correct assessment= ? > That is a correct assesment, but Cmockery2 is "patch ready" here - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192420 - just needs to be pushed in if there are no other issues. Let me know if you have further questions. Thanks --=20 Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes From owner-freebsd-fs@FreeBSD.ORG Mon Aug 18 04:11:56 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B79B3F0F for ; Mon, 18 Aug 2014 04:11:56 +0000 (UTC) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 53325362A for ; Mon, 18 Aug 2014 04:11:55 +0000 (UTC) X-AuditID: 1209190f-f79f86d0000061c8-b9-53f17d04ff8b Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id EC.A2.25032.40D71F35; Mon, 18 Aug 2014 00:11:48 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s7I4Bl6j032349; Mon, 18 Aug 2014 00:11:48 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7I4Bj0M017124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Aug 2014 00:11:47 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7I4Bjms003787; Mon, 18 Aug 2014 00:11:45 -0400 (EDT) Date: Mon, 18 Aug 2014 00:11:45 -0400 (EDT) From: Benjamin Kaduk To: Thomas Schweikle Subject: Re: zfs only mounting "root" after reboot In-Reply-To: <53F0050D.6060700@gmail.com> Message-ID: References: <53EF3036.8050203@gmail.com> <53EFF87F.7080507@gmail.com> <53F0050D.6060700@gmail.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixCmqrMtS+zHYoPubhMWxxz/ZLC4cfsvu wOQx49N8Fo+ds+6yBzBFcdmkpOZklqUW6dslcGUsuXafveAwa8XhKfvYGxhXs3QxcnJICJhI HP/Vxwphi0lcuLeerYuRi0NIYDaTxJoJP6CcjYwSO/5OZoVwDjFJHLvfAuU0MEpcf/gFrJ9F QFvi/YvJYDabgIrEzDcb2UBsEaD424eH2UFsZgF1iYamKWC2sICRRMv9TWA2p4CmxPXjPUA2 BwevgKPE7H9WEPOXMEnce7kbrEZUQEdi9f4pYHfzCghKnJz5hAVippbE8unbWCYwCs5CkpqF JLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrolebmaJXmpK6SZGcLBK8u9g/HZQ6RCjAAej Eg/vgrcfgoVYE8uKK3MPMUpyMCmJ8nKWfgwW4kvKT6nMSCzOiC8qzUktPsQowcGsJML7qgIo x5uSWFmVWpQPk5LmYFES531rbRUsJJCeWJKanZpakFoEk5Xh4FCS4N1TDdQoWJSanlqRlplT gpBm4uAEGc4DNDwDpIa3uCAxtzgzHSJ/ilGXo6XpbS+TEEtefl6qlDjvOZAiAZCijNI8uDmw JPOKURzoLWHeLSBVPMAEBTfpFdASJqAlNZvfgiwpSURISTUwxoovi31wwGXH/p2bOVRLpu+d PuliVsPveXrrjKLD66Y/ENvYvpHnQLW9z8fDq/KlGSqZZTVry+Y+c+zVtJPN9DaYwXw94eyS 8jOSUyxP/Zpnrh05LeR/nZj0jk3phyUNO0uDFhz14Po/UU6Zd6n6Rq7m2a/ef3/Au8u0RaRo 82U+FmfO7+VTlViKMxINtZiLihMBmC+PTA0DAAA= Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 04:11:56 -0000 On Sat, 16 Aug 2014, Thomas Schweikle wrote: > FreeBSD. It is merely the same as what FreeBSD has at /proc and is > mounted at /usr/compat/linux/proc (which is linked to > > is normally mounted at /dev/fd. > > There are some other pseudo filesystems you may or may not need to > mount them -- it depends on what programs you run ...! Some of them > mount to /usr/compat, some to /dev (some of them then link to > /usr/compat/ -- these need /usr to be mounted). Ah, yes, this is the more mundane "the mountpoint must exist for the mount to succeed" issue. I don't see any documentation of it in the obvious places in the handbook, though, so thanks for pointing it out. -Ben From owner-freebsd-fs@FreeBSD.ORG Mon Aug 18 08:00:11 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80433392 for ; Mon, 18 Aug 2014 08:00:11 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61E8C3782 for ; Mon, 18 Aug 2014 08:00:11 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s7I80BwW087997 for ; Mon, 18 Aug 2014 08:00:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Message-Id: <201408180800.s7I80BwW087997@kenobi.freebsd.org> From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 18 Aug 2014 08:00:11 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 08:00:11 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (5 bugs) Bug 133174: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=133174 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-fs@FreeBSD.org Status: Needs MFC Resolution: Summary: [msdosfs] [patch] msdosfs must support multibyte international characters in file names Bug 136470: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=136470 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-fs@FreeBSD.org Status: Needs MFC Resolution: Summary: [nfs] Cannot mount / in read-only, over NFS Bug 139651: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=139651 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-fs@FreeBSD.org Status: Needs MFC Resolution: Summary: [nfs] mount(8): read-only remount of NFS volume does not work Bug 144447: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144447 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-fs@FreeBSD.org Status: Needs MFC Resolution: Summary: [zfs] sharenfs fsunshare() & fsshare_main() non functional Bug 155411: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=155411 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-fs@FreeBSD.org Status: Needs MFC Resolution: Summary: [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device From owner-freebsd-fs@FreeBSD.ORG Mon Aug 18 15:18:03 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 532162A8 for ; Mon, 18 Aug 2014 15:18:03 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 149B8334E for ; Mon, 18 Aug 2014 15:18:02 +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.72) (envelope-from ) id 1XJOh0-0004KS-44 for freebsd-fs@freebsd.org; Mon, 18 Aug 2014 17:17:54 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Subject: Re: Strange effect of zfs rename References: <53E61706.4010604@digiware.nl> Date: Mon, 18 Aug 2014 17:17:53 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <53E61706.4010604@digiware.nl> User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, BAYES_40 autolearn=disabled version=3.3.2 X-Scan-Signature: 0cb660a7d4ce909c6359c48b0bded22a X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 15:18:03 -0000 On Sat, 09 Aug 2014 14:41:42 +0200, Willem Jan Withagen wrote: > Hoi, > > In the process of creating backups I have this sequence of: > > /sbin/zfs destroy zfsraid/backups@Saturday-2 > /sbin/zfs rename -f zfsraid/backups@Saturday zfsraid/backups@Saturday-2 > /sbin/zfs snapshot zfsraid/backups@Saturday > > But then I end up with: > # cd /backups/.zfs/snapshot > # ll > ls: Saturday-2: Device busy > total 116 > 0 dr-xr-xr-x 11 root wheel 11 Aug 9 14:15 ./ > 0 dr-xr-xr-x 4 root wheel 4 Jul 30 22:07 ../ > 17 drwxr-xr-x 13 root wheel 16 Jul 31 09:54 20140801/ > 17 drwxr-xr-x 18 root wheel 21 Aug 5 01:03 Friday/ > 17 drwxr-xr-x 16 root wheel 19 Aug 3 01:03 Monday/ > 17 drwxr-xr-x 15 root wheel 18 Aug 2 01:03 Sunday/ > 17 drwxr-xr-x 18 root wheel 21 Aug 5 01:03 Thursday/ > 17 drwxr-xr-x 17 root wheel 20 Aug 4 01:03 Tuesday/ > 17 drwxr-xr-x 18 root wheel 21 Aug 5 01:03 Wednesday/ > Exit 1 > > And the device does not becomen not-busy even after a "long" wait. > > The way to remedy this is: > /sbin/zfs unmount -f zfsraid/backups > /sbin/zfs mount zfsraid/backups > > After that the snapshot-dir is as it should. > > I'm running: > FreeBSD zfs.digiware.nl 9.3-STABLE FreeBSD 9.3-STABLE #272 r269145M: Sun > Jul 27 06:50:06 CEST 2014 > root@zfs.digiware.nl:/usr/obj/usr/srcs/src9/src/sys/ZFS amd64 > > Can other reproduce this? Or is my system suffering from bitrot? > > Regards, > --WjW I don't see this. I used to work on 9-STABLE and now on 10-STABLE (from august 5th). I use zfs rename a lot for handling my snapshots, but I do not use the -f option. I must say I never need to go into the .zfs/snapshot directories, so they are mounted seldom. I just went into them today for a test, but I don't have 'Device busy' problems. Do you keep such a directory active somewhere? Ronald. From owner-freebsd-fs@FreeBSD.ORG Mon Aug 18 19:46:31 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 719846CC for ; Mon, 18 Aug 2014 19:46:31 +0000 (UTC) Received: from caida.org (rommie.caida.org [192.172.226.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D7743E4B for ; Mon, 18 Aug 2014 19:46:30 +0000 (UTC) Message-ID: <53F25402.1020907@caida.org> Date: Mon, 18 Aug 2014 12:29:06 -0700 From: Daniel Andersen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Process enters unkillable state and somewhat wedges zfs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 19:46:31 -0000 We are currently experiencing a strange problem that sort of locks up one of our zfs pools. This is on a FreeBSD 10 machine. Let me give a rough layout of our system to better describe what is happening: We have two pools, tank and work. Both are mounted as /tank and /work respectively. Within these pools, we have a variety of partitions. Each of these partitions is then nullfs mounted into other partitions in an effort to present a common directory structure for users. Below is an example: /tank/a -> /data/a /tank/a -> /export/a /tank/b -> /data/b /work/home -> /home etc. Now, occasionally, something goes horribly wrong with a process ( or sometimes one thread within a process ). It enters a state where it is running, pegging a CPU at 100%, and is unkillable. This process, as I understand it, is attempting to access data on both pools, but only through the nullfs mounts. Now, when this process enters the above mentioned state, the /tank pool becomes inaccessible.. any process attempting to touch it enters the traditional 'D' state and itself becomes unkillable. However... you can *still* access all the data through the nullfs mounts. So, while 'ls /tank/a' wedges, 'ls /data/a' works fine. Typically, this happens when the machine is under high load. Arc memory usage is often at 140+GB ( out of 192GB total ) It has happened under low load once... but I suspect there was still substantial I/O load at the time, as we had been doing many benchmarks trying to trigger this problem, and likely the cache was still flushing to disk. Initially, we thought this was triggered by a process attempting to dump core, as all processes that originally wedged were such.. however, after disabling core dumps, we just had a case where 'sudo -u user su - user' wedged. This has me baffled. If anyone has any hints as to where to even start debugging this, I'd appreciate it greatly. For now, I've tuned down the arc max memory usage.. just as a guess. I saw in another thread here some bugs about FreeBSD not giving back memory from ARC correctly, when needed. I don't know if this could cause a process to enter this state, but figured it was worth a try. Many thanks, Daniel Andersen From owner-freebsd-fs@FreeBSD.ORG Tue Aug 19 20:17:35 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2CFD7CC for ; Tue, 19 Aug 2014 20:17:35 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61D773B07 for ; Tue, 19 Aug 2014 20:17:35 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 8BF541534ED; Tue, 19 Aug 2014 22:17:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4ThPWzmuDII; Tue, 19 Aug 2014 22:16:59 +0200 (CEST) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 641911534C4; Tue, 19 Aug 2014 22:16:59 +0200 (CEST) Message-ID: <53F3B0BD.406@digiware.nl> Date: Tue, 19 Aug 2014 22:17:01 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ronald Klop , freebsd-fs@freebsd.org Subject: Re: Strange effect of zfs rename References: <53E61706.4010604@digiware.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 20:17:35 -0000 On 18-8-2014 17:17, Ronald Klop wrote: > On Sat, 09 Aug 2014 14:41:42 +0200, Willem Jan Withagen > wrote: > >> Hoi, >> >> In the process of creating backups I have this sequence of: >> >> /sbin/zfs destroy zfsraid/backups@Saturday-2 >> /sbin/zfs rename -f zfsraid/backups@Saturday zfsraid/backups@Saturday-2 >> /sbin/zfs snapshot zfsraid/backups@Saturday >> >> But then I end up with: >> # cd /backups/.zfs/snapshot >> # ll >> ls: Saturday-2: Device busy >> total 116 >> 0 dr-xr-xr-x 11 root wheel 11 Aug 9 14:15 ./ >> 0 dr-xr-xr-x 4 root wheel 4 Jul 30 22:07 ../ >> 17 drwxr-xr-x 13 root wheel 16 Jul 31 09:54 20140801/ >> 17 drwxr-xr-x 18 root wheel 21 Aug 5 01:03 Friday/ >> 17 drwxr-xr-x 16 root wheel 19 Aug 3 01:03 Monday/ >> 17 drwxr-xr-x 15 root wheel 18 Aug 2 01:03 Sunday/ >> 17 drwxr-xr-x 18 root wheel 21 Aug 5 01:03 Thursday/ >> 17 drwxr-xr-x 17 root wheel 20 Aug 4 01:03 Tuesday/ >> 17 drwxr-xr-x 18 root wheel 21 Aug 5 01:03 Wednesday/ >> Exit 1 >> >> And the device does not becomen not-busy even after a "long" wait. >> >> The way to remedy this is: >> /sbin/zfs unmount -f zfsraid/backups >> /sbin/zfs mount zfsraid/backups >> >> After that the snapshot-dir is as it should. >> >> I'm running: >> FreeBSD zfs.digiware.nl 9.3-STABLE FreeBSD 9.3-STABLE #272 r269145M: Sun >> Jul 27 06:50:06 CEST 2014 >> root@zfs.digiware.nl:/usr/obj/usr/srcs/src9/src/sys/ZFS amd64 >> >> Can other reproduce this? Or is my system suffering from bitrot? >> >> Regards, >> --WjW > > I don't see this. I used to work on 9-STABLE and now on 10-STABLE (from > august 5th). > > I use zfs rename a lot for handling my snapshots, but I do not use the > -f option. I must say I never need to go into the .zfs/snapshot > directories, so they are mounted seldom. I just went into them today for > a test, but I don't have 'Device busy' problems. Do you keep such a > directory active somewhere? No not really, it is like you suggest: rarely go into the snapshots for recovery. But I do keep 'm online. I'm just using test(1) to see if the snapshot I'd like to destroy is really there. Which is easily done by testing if the snapshot dir exists. --WjW From owner-freebsd-fs@FreeBSD.ORG Wed Aug 20 15:28:59 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EDA72D1 for ; Wed, 20 Aug 2014 15:28:59 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6631B3C9C for ; Wed, 20 Aug 2014 15:28:59 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s7KFSx6t065794 for ; Wed, 20 Aug 2014 15:28:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 187594] [zfs] [patch] ZFS ARC behavior problem and fix Date: Wed, 20 Aug 2014 15:28:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: karl@denninger.net X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 15:28:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 --- Comment #23 from karl@denninger.net --- Status -- still grinning, still doing what it's supposed to on my fairly-heavily loaded production machine..... This machine has a large Postgres database running on it and has 19Gb of RAM wired at the present time. Are there any further comments from the reviewers on integration into the tree for general distribution? [karl@NewFS ~]$ uname -v FreeBSD 10.0-STABLE #0 r265164M: Wed Apr 30 16:55:42 CDT 2014 karl@NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP [karl@NewFS ~]$ uptime 10:24AM up 111 days, 16:56, 1 user, load averages: 0.43, 0.55, 0.51 [karl@NewFS ~]$ zfs-stats -AE ------------------------------------------------------------------------ ZFS Subsystem Report Wed Aug 20 10:24:49 2014 ------------------------------------------------------------------------ ARC Summary: (HEALTHY) Memory Throttle Count: 0 ARC Misc: Deleted: 146.88m Recycle Misses: 6.59m Mutex Misses: 14.19k Evict Skips: 176.63m ARC Size: 65.19% 14.56 GiB Target Size: (Adaptive) 65.19% 14.56 GiB Min Size (Hard Limit): 12.50% 2.79 GiB Max Size (High Water): 8:1 22.33 GiB ARC Size Breakdown: Recently Used Cache Size: 78.62% 11.44 GiB Frequently Used Cache Size: 21.38% 3.11 GiB ARC Hash Breakdown: Elements Max: 1.61m Elements Current: 61.38% 986.56k Collisions: 653.96m Chain Max: 27 Chains: 243.95k ------------------------------------------------------------------------ ARC Efficiency: 6.56b Cache Hit Ratio: 98.75% 6.48b Cache Miss Ratio: 1.25% 81.95m Actual Hit Ratio: 82.14% 5.39b Data Demand Efficiency: 99.56% 3.83b Data Prefetch Efficiency: 23.05% 53.24m CACHE HITS BY CACHE LIST: Anonymously Used: 16.46% 1.07b Most Recently Used: 4.48% 289.87m Most Frequently Used: 78.70% 5.10b Most Recently Used Ghost: 0.07% 4.50m Most Frequently Used Ghost: 0.29% 18.94m CACHE HITS BY DATA TYPE: Demand Data: 58.89% 3.81b Prefetch Data: 0.19% 12.27m Demand Metadata: 17.85% 1.16b Prefetch Metadata: 23.07% 1.49b CACHE MISSES BY DATA TYPE: Demand Data: 20.38% 16.70m Prefetch Data: 49.99% 40.97m Demand Metadata: 16.74% 13.72m Prefetch Metadata: 12.89% 10.56m ------------------------------------------------------------------------ -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Wed Aug 20 15:31:00 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDD8B3C8 for ; Wed, 20 Aug 2014 15:31:00 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D5E243D47 for ; Wed, 20 Aug 2014 15:31:00 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s7KFV0Bh095221 for ; Wed, 20 Aug 2014 15:31:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 187594] [zfs] [patch] ZFS ARC behavior problem and fix Date: Wed, 20 Aug 2014 15:31:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: Mark.Martinec@ijs.si X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 15:31:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 --- Comment #24 from Mark.Martinec@ijs.si --- Please don't miss the 10.1 slush! The fix is still not in 10-STABLE and needs to be manually applied for each new 10 installation. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Wed Aug 20 18:07:02 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A414E2F2 for ; Wed, 20 Aug 2014 18:07:02 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 869EF314A for ; Wed, 20 Aug 2014 18:07:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s7KI72oU004736 for ; Wed, 20 Aug 2014 18:07:02 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s7KI72Pk004733 for freebsd-fs@freebsd.org; Wed, 20 Aug 2014 18:07:02 GMT (envelope-from bdrewery) Received: (qmail 21909 invoked from network); 20 Aug 2014 13:07:00 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 20 Aug 2014 13:07:00 -0500 Message-ID: <53F4E3C0.6000406@FreeBSD.org> Date: Wed, 20 Aug 2014 13:06:56 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Daniel Andersen , freebsd-fs@freebsd.org Subject: Re: Process enters unkillable state and somewhat wedges zfs References: <53F25402.1020907@caida.org> In-Reply-To: <53F25402.1020907@caida.org> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fjRRXwOJxfWsSjEhjwO1rmKaOJhrfWamR" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 18:07:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fjRRXwOJxfWsSjEhjwO1rmKaOJhrfWamR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/18/2014 2:29 PM, Daniel Andersen wrote: > We are currently experiencing a strange problem that sort of locks up o= ne of our zfs pools. This is on a FreeBSD 10 > machine. Let me give a rough layout of our system to better describe w= hat is happening: When it happens get the output of 'procstat -kka|grep zfs' please. --=20 Regards, Bryan Drewery --fjRRXwOJxfWsSjEhjwO1rmKaOJhrfWamR 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.10 (MingW32) iQEcBAEBAgAGBQJT9OPAAAoJEDXXcbtuRpfPuHMIAILOLv7O5Od1uJdYwBQICkLf QLfmh3RkOVEXuHrUbHIUq3CcURed883j5pH3ZY/4MPXaPMY+0GwsiMZHu3y9cxbs jMZ1oSN5PH82qCQL9pcq05SufJTrPMOPzmgW35D8kna2Vmtjlz3MV49P1fMK2HTu D/IAdUMNQiVLCZIWSKXKlKNKkDXZQ+J+cPns+zj0epZ5t/KfC81DQBKice4BEOoj LvP6y6YyJNAaufNOOGseZlb7oGidnif+RU9d8qkGTTPl7x0u/1ss/SrjM04hJZUh fQCSxSS7fgfTVUm8FiTxI5lTuUP8c157fcXjWmGOQr6vEyT2ho41Fh6GOz8ZQ4M= =a4If -----END PGP SIGNATURE----- --fjRRXwOJxfWsSjEhjwO1rmKaOJhrfWamR-- From owner-freebsd-fs@FreeBSD.ORG Thu Aug 21 19:46:03 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FAA1BE7 for ; Thu, 21 Aug 2014 19:46:03 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46D843F12 for ; Thu, 21 Aug 2014 19:46:03 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s7LJk3Me041608 for ; Thu, 21 Aug 2014 19:46:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 144234] [zfs] Cannot boot machine with recent gptzfsboot code [regression] Date: Thu, 21 Aug 2014 19:46:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: elliot.robinson@argiopetech.com X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:46:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144234 Elliot Robinson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |elliot.robinson@argiopetech | |.com --- Comment #3 from Elliot Robinson --- I receive this error message on boot using a Dell Studio XPS 1640 w/ Core2 Duo. I have tested 9.3-RELEASE and 10.0-RELEASE with identical results. I have not yet attempted the original reporter's fix. Steps to reproduce: 1. Install FreeBSD 9.3 or 10 using the "ZFS" partitioning scheme with GPT on a Dell Studio XPS 1640. 2. Reboot -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Fri Aug 22 12:02:48 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7823B786; Fri, 22 Aug 2014 12:02:48 +0000 (UTC) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DF903897; Fri, 22 Aug 2014 12:02:47 +0000 (UTC) Received: from PAIMAIL.pai.local (paimail.pai.local [10.10.0.153]) by mx2.paymentallianceintl.com (8.14.5/8.13.8) with ESMTP id s7MBrv3D098169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 07:53:57 -0400 (EDT) (envelope-from mikej@paymentallianceintl.com) Received: from PAIMAIL.pai.local ([::1]) by PAIMAIL.pai.local ([::1]) with mapi; Fri, 22 Aug 2014 07:53:57 -0400 From: Michael Jung To: "bugzilla-noreply@freebsd.org" , "freebsd-fs@freebsd.org" Date: Fri, 22 Aug 2014 07:53:38 -0400 Subject: RE: [Bug 187594] [zfs] [patch] ZFS ARC behavior problem and fix Thread-Topic: [Bug 187594] [zfs] [patch] ZFS ARC behavior problem and fix Thread-Index: Ac+8i5N5+xT1JwoYTc2L32GZLDEyZwBc5A5g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 12:02:48 -0000 I have been using the patches on a number of machines both physical and vir= tual with between 8-64GB without issues. These include 10/10-STABLE/11-Current serving NFS/S= MB and a poudriere build box that is boot on UFS and ZFS for poudriere. Uptimes of 90+ days without issue. It has been a godsend on all machines e= ven my desktop with 8GB full X11 and numerous application + jails. No ZFS tuning. I hope that whatever further review moves forward so this c= an be committed. --mikej -----Original Message----- From: owner-freebsd-fs@freebsd.org [mailto:owner-freebsd-fs@freebsd.org] On= Behalf Of bugzilla-noreply@freebsd.org Sent: Wednesday, August 20, 2014 11:29 AM To: freebsd-fs@freebsd.org Subject: [Bug 187594] [zfs] [patch] ZFS ARC behavior problem and fix https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D187594 --- Comment #23 from karl@denninger.net --- Status -- still grinning, still= doing what it's supposed to on my fairly-heavily loaded production machine= ..... This machine has a large Postgres database running on it and has 19G= b of RAM wired at the present time. Are there any further comments from the reviewers on integration into the t= ree for general distribution? [karl@NewFS ~]$ uname -v FreeBSD 10.0-STABLE #0 r265164M: Wed Apr 30 16:55:42 CDT 2014 karl@NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP [karl@NewFS ~]$ uptime 10:24AM up 111 days, 16:56, 1 user, load averages: 0.43, 0.55, 0.51 [karl@NewFS ~]$ zfs-stats -AE ------------------------------------------------------------------------ ZFS Subsystem Report Wed Aug 20 10:24:49 2014 ------------------------------------------------------------------------ ARC Summary: (HEALTHY) Memory Throttle Count: 0 ARC Misc: Deleted: 146.88m Recycle Misses: 6.59m Mutex Misses: 14.19k Evict Skips: 176.63m ARC Size: 65.19% 14.56 GiB Target Size: (Adaptive) 65.19% 14.56 GiB Min Size (Hard Limit): 12.50% 2.79 GiB Max Size (High Water): 8:1 22.33 GiB ARC Size Breakdown: Recently Used Cache Size: 78.62% 11.44 GiB Frequently Used Cache Size: 21.38% 3.11 GiB ARC Hash Breakdown: Elements Max: 1.61m Elements Current: 61.38% 986.56k Collisions: 653.96m Chain Max: 27 Chains: 243.95k ------------------------------------------------------------------------ ARC Efficiency: 6.56b Cache Hit Ratio: 98.75% 6.48b Cache Miss Ratio: 1.25% 81.95m Actual Hit Ratio: 82.14% 5.39b Data Demand Efficiency: 99.56% 3.83b Data Prefetch Efficiency: 23.05% 53.24m CACHE HITS BY CACHE LIST: Anonymously Used: 16.46% 1.07b Most Recently Used: 4.48% 289.87m Most Frequently Used: 78.70% 5.10b Most Recently Used Ghost: 0.07% 4.50m Most Frequently Used Ghost: 0.29% 18.94m CACHE HITS BY DATA TYPE: Demand Data: 58.89% 3.81b Prefetch Data: 0.19% 12.27m Demand Metadata: 17.85% 1.16b Prefetch Metadata: 23.07% 1.49b CACHE MISSES BY DATA TYPE: Demand Data: 20.38% 16.70m Prefetch Data: 49.99% 40.97m Demand Metadata: 16.74% 13.72m Prefetch Metadata: 12.89% 10.56m ------------------------------------------------------------------------ -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-fs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" GoPai.com | Facebook.com/PaymentAlliance CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 6060 Dutchmans Lane, Suite 320, Louisville, KY 40205 From owner-freebsd-fs@FreeBSD.ORG Fri Aug 22 12:40:43 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACEF0BCA; Fri, 22 Aug 2014 12:40:43 +0000 (UTC) Received: from mailout05.t-online.de (mailout05.t-online.de [194.25.134.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CD0B3B3C; Fri, 22 Aug 2014 12:40:43 +0000 (UTC) Received: from fwd24.aul.t-online.de (fwd24.aul.t-online.de [172.20.26.129]) by mailout05.t-online.de (Postfix) with SMTP id 9700B60C67B; Fri, 22 Aug 2014 14:40:35 +0200 (CEST) Received: from [192.168.119.33] (G-boWoZdghnLQwTr0jzKCGl-GozAeGj6JchsLSkxjCvypUtI0ziGONMols82j5pQ47@[84.154.101.219]) by fwd24.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XKo8x-0sfyvg0; Fri, 22 Aug 2014 14:40:35 +0200 Message-ID: <53F73A39.9090000@freebsd.org> Date: Fri, 22 Aug 2014 14:40:25 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "freebsd-fs@freebsd.org" Subject: Re: [Bug 187594] [zfs] [patch] ZFS ARC behavior problem and fix References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: G-boWoZdghnLQwTr0jzKCGl-GozAeGj6JchsLSkxjCvypUtI0ziGONMols82j5pQ47 X-TOI-MSGID: 562569bf-0c89-4a1f-aabb-8e25e99aa673 Cc: Michael Jung X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 12:40:43 -0000 Am 22.08.2014 um 13:53 schrieb Michael Jung: > I have been using the patches on a number of machines both physical and virtual with between > 8-64GB without issues. These include 10/10-STABLE/11-Current serving NFS/SMB and a poudriere > build box that is boot on UFS and ZFS for poudriere. > > Uptimes of 90+ days without issue. It has been a godsend on all machines even my desktop with > 8GB full X11 and numerous application + jails. > > No ZFS tuning. I hope that whatever further review moves forward so this can be committed. > > --mikej I second this request. I've also been using this patch on a system that required reboots to recover from low performance states that were not well handled without the patch. My specific use case is a development system (i.e. builds ports and the world nearly every day, often multiple times a day), which is also used as a home server for uncritical services (e.g. as DLNA server). Since I convert and cut DVB-S broadcasts for archival purposes on this system, it does process up to 50 GByte of video files (when I get around to it). The MPEG TS files are stored on a 1TB UFS2 disk, while waiting to be processed, while the system uses a 4*2TB raidz1 ZPOOL for all other purposes (including storage of the converted video files). (And yes, I know that a 4 disk raidz is not optimal, but the performance problems I observed without the patch are not caused by this ...) System specs: i7/2600 24GB RAM 4*2TB ZFS raidz1 1*1TB UFS2 Anyway, even the discouraged combination of ZFS and UFS works without any problem with Karl's patch. The system used to grind to a halt during files system operation (virtually freezing for some 20 to 30 seconds), which makes interactive use for video cutting and conversion rather painful (and does not help when streaming videos to a Smart-TV for display). I don't mind to apply the patch by hand, but since it offers massive performance improvements on systems that trigger the bad behaviour of the current code, this patch should be committed to -CURRENT and MFCed to at least 10-STABLE (and included in 10.1). People comparing different operating systems under load (and include FreeBSD with ZFS in this comparison) will else get disappointing results on out-of-the-box installations. We know from many reports (and in my case from personal experience), what big difference this patch makes! This patch should really have gone into -CURRENT, months ago, IMHO ... Regards, STefan From owner-freebsd-fs@FreeBSD.ORG Fri Aug 22 17:47:42 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC22427D; Fri, 22 Aug 2014 17:47:42 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 362BB3FF5; Fri, 22 Aug 2014 17:47:41 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s7MHldGW040649; Fri, 22 Aug 2014 19:47:39 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id EC8A63ED7; Fri, 22 Aug 2014 19:47:38 +0200 (CEST) Message-ID: <53F78234.4080208@omnilan.de> Date: Fri, 22 Aug 2014 19:47:32 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD Stable , FreeBSD FS Subject: 'File name too long' when ls .zfs/snapshot/ X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1B9F17A27DCA4DC108B00861" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Fri, 22 Aug 2014 19:47:39 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 17:47:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1B9F17A27DCA4DC108B00861 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, I tried to walk into .zfs/snapshot/. It's mountpoint is /zfs/netshares/deployment/OS-Resources/FreeBSD/OmniLAN/ports/ports/ Doing 'ls' gives: ls: daily-2014-08-20: File name too long ls: daily-2014-08-21: File name too long Glad that 'zfs rename' did the trick, but I guess I hit the same limitation I reported three weeks ago: http://lists.freebsd.org/pipermail/freebsd-stable/2014-August/079514.html= Is this limitation known as problematic / hard to relax? Thanks, -Harry --------------enig1B9F17A27DCA4DC108B00861 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlP3gjoACgkQLDqVQ9VXb8hKqgCfcGuWZoyHhl4CsHqu1umdT9Vo a2gAoKJ5h1pUU11HcO4NNUCDMZO1PcIl =gSFU -----END PGP SIGNATURE----- --------------enig1B9F17A27DCA4DC108B00861-- From owner-freebsd-fs@FreeBSD.ORG Fri Aug 22 19:43:16 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 657B3475 for ; Fri, 22 Aug 2014 19:43:16 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2D6003C04 for ; Fri, 22 Aug 2014 19:43:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s7MJhFEm013114 for ; Fri, 22 Aug 2014 19:43:15 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s7MJhFnb013113 for freebsd-fs@freebsd.org; Fri, 22 Aug 2014 19:43:15 GMT (envelope-from bdrewery) Received: (qmail 77488 invoked from network); 22 Aug 2014 14:43:14 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 22 Aug 2014 14:43:14 -0500 Message-ID: <53F79D4B.5070502@FreeBSD.org> Date: Fri, 22 Aug 2014 14:43:07 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Harald Schmalzbauer , FreeBSD Stable , FreeBSD FS Subject: Re: 'File name too long' when ls .zfs/snapshot/ References: <53F78234.4080208@omnilan.de> In-Reply-To: <53F78234.4080208@omnilan.de> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QhV8r5D3jXlfucGHdPn8i6lvXTas5xB0b" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:43:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QhV8r5D3jXlfucGHdPn8i6lvXTas5xB0b Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable On 8/22/2014 12:47 PM, Harald Schmalzbauer wrote: > Hello, >=20 > I tried to walk into .zfs/snapshot/. It's mountpoint is > /zfs/netshares/deployment/OS-Resources/FreeBSD/OmniLAN/ports/ports/ > Doing 'ls' gives: > ls: daily-2014-08-20: File name too long > ls: daily-2014-08-21: File name too long >=20 > Glad that 'zfs rename' did the trick, but I guess I hit the same > limitation I reported three weeks ago: > http://lists.freebsd.org/pipermail/freebsd-stable/2014-August/079514.ht= ml >=20 > Is this limitation known as problematic / hard to relax? >=20 > Thanks, >=20 > -Harry >=20 This thread discusses the issue and a potential patch. http://lists.freebsd.org/pipermail/freebsd-hackers/2013-November/043798.h= tml --=20 Regards, Bryan Drewery --QhV8r5D3jXlfucGHdPn8i6lvXTas5xB0b 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.10 (MingW32) iQEcBAEBAgAGBQJT951LAAoJEDXXcbtuRpfPqy8H/2xBrgIwCf7kE9WQ7Yu4G9kA xT/Ly1kHTVwlK40ZduwplzQcW9G+EH4FsXDXHDNjOafT/miWdmYEFGJ72+oCXeO/ g55NI34CPkUnTTCUwMOSx5jvJ4sXFHOMYXzMlx7qs1xmRBUQIbVSt8p7BcAozDSX NfKq/5zA5FVeqOeetvzrYG03jmK8SmRC7CaeanyDa76dZ7ZDDjdDZnjjk7M6W6jM na90MGa22eXGWuIqqlHpOwjNEyg1o68HwiKgaVEsWg1PA9o2CtKtawXIiICKipc0 dbV++7pUtJidEk7YUv0Z8oUTkhm+AHxV6QQsNeh+ApnGLzNSTwy/UUhXQhKNauc= =s1Hu -----END PGP SIGNATURE----- --QhV8r5D3jXlfucGHdPn8i6lvXTas5xB0b-- From owner-freebsd-fs@FreeBSD.ORG Fri Aug 22 21:27:01 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E3416BC for ; Fri, 22 Aug 2014 21:27:01 +0000 (UTC) Received: from mail.theusgroup.com (mail.theusgroup.com [64.122.243.222]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F12C93616 for ; Fri, 22 Aug 2014 21:27:00 +0000 (UTC) Received: by mail.theusgroup.com (Postfix, from userid 20) id 62F8096D; Fri, 22 Aug 2014 14:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=theusgroup.com; s=mail; t=1408742299; bh=EFo0Wu9JuSkWy7SucFGXOMDCyCs8FvS+b7v78Apos2k=; h=From:To:Subject:In-reply-to:References:Date; b=iWQMAEGgrxCMZscp46xPGCqNJqUbG/sI3k59+MGiBOEHZDi7akEGTqdI38ebUSk3/ y61ORbBH98HmmC+p05IB06mD2Squ2zj0vBJ6vcQMLZ1e4siXQyuc7OE/4mJahqCPVT kjcbGypxlHNaVb1WgA5j4aJnRn7quaWzRCgz179U= From: John To: "freebsd-fs@freebsd.org" Subject: Re: [Bug 187594] [zfs] [patch] ZFS ARC behavior problem and fix In-reply-to: <53F73A39.9090000@freebsd.org> References: <53F73A39.9090000@freebsd.org> Comments: In-reply-to Stefan Esser message dated "Fri, 22 Aug 2014 14:40:25 +0200." Date: Fri, 22 Aug 2014 14:18:19 -0700 Message-Id: <20140822211819.62F8096D@mail.theusgroup.com> X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 21:27:01 -0000 >Am 22.08.2014 um 13:53 schrieb Michael Jung: >> I have been using the patches on a number of machines both physical and virtual with between >> 8-64GB without issues. These include 10/10-STABLE/11-Current serving NFS/SMB and a poudriere >> build box that is boot on UFS and ZFS for poudriere. >> >> Uptimes of 90+ days without issue. It has been a godsend on all machines even my desktop with >> 8GB full X11 and numerous application + jails. >> >> No ZFS tuning. I hope that whatever further review moves forward so this can be committed. >> >> --mikej > >I second this request. I've also been using this patch on a system that >required reboots to recover from low performance states that were not >well handled without the patch. > ... >This patch should really have gone into -CURRENT, months ago, IMHO ... > >Regards, STefan Given how long this patch has been in use with nothing but positive feedback, and still having not been committed, one has to wonder why? Is it NIH, and something else. It least one committer commented in the past that Karl's approach isn't how he would have done it. Is that the problem? It's ridiculous we've had to keep adding this patch to keep our zfs systems running with decent performance. Why hasn't this been committed? John Theus TheUsGroup.com From owner-freebsd-fs@FreeBSD.ORG Sat Aug 23 01:37:18 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D4BD3A5 for ; Sat, 23 Aug 2014 01:37:18 +0000 (UTC) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE8E43AB7 for ; Sat, 23 Aug 2014 01:37:16 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id x13so11159638wgg.7 for ; Fri, 22 Aug 2014 18:37:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-type; bh=QfNUCibY+yMF3VQJ1XWVNxxb3QCcHiXGkWU8miu9qPk=; b=OuJgIQKNu2sjcoRpdaihAuf43oBVqZDgeqtG5YfCPb6x3QaBx7HqgzTysyB6T7Vk4T CWCGs/nv5a5AznThNLHbQmC8aj8ekN7vKQBJ2zDNJzgow9mLCQJtkG6amsZOwy0DyFKI /BUEuSCzD4N3N17UkdKiKGPdygC2JWn9sJ6LjsrVOxMkWGCAa68oc9L5sGG8IJxHPWWE Lba/+fR3bzTwUmVMsI7EU+2j/6DrPV6X0e3CKBW5jh8TVAFx2N8eTuQDtDHiI5a3pTtk qmk5FEklWIPYZAtlPs2PGSp6yHG1i086jUFVvsfg47OsTxnsyWXFmF9PrzTGK/wgY2EP 7/Dw== X-Gm-Message-State: ALoCoQlAfT7S2JEEr+/pb39tB0szfO7xVL1gaQTohyA9DFgpO1g1p/0aIpV+jAVubJEUTyneSBIK X-Received: by 10.194.95.66 with SMTP id di2mr8156114wjb.47.1408757834624; Fri, 22 Aug 2014 18:37:14 -0700 (PDT) Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id fs3sm3830144wic.20.2014.08.22.18.37.13 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 22 Aug 2014 18:37:13 -0700 (PDT) Message-ID: From: "Steven Hartland" To: "John" , References: <53F73A39.9090000@freebsd.org> <20140822211819.62F8096D@mail.theusgroup.com> Subject: Re: [Bug 187594] [zfs] [patch] ZFS ARC behavior problem and fix Date: Sat, 23 Aug 2014 02:37:10 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_04A6_01CFBE7B.23C80680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 01:37:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04A6_01CFBE7B.23C80680 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "John via freebsd-fs" > Given how long this patch has been in use with nothing but positive > feedback, > and still having not been committed, one has to wonder why? > > Is it NIH, and something else. It least one committer commented in the > past > that Karl's approach isn't how he would have done it. Is that the > problem? > > It's ridiculous we've had to keep adding this patch to keep our zfs > systems > running with decent performance. > > Why hasn't this been committed? I've actually been looking at this patch today in relation to my investigation of: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191510 I would appreciate it if people could test the attached patch, which was created against stable/10 It should achieve the same as Karl's patch as well as: * More closely matching original Solaris logic * Provide better control of the reclaim trigger (absolute not percentage based, which becomes a problem in larger memory machines) * Uses direct kernel values instead of interfacing via sysctl's. * Should fix the issue identified in #191510 as well. Basic design is it will trigger ARC reclaim when free pages drops below vfs.zfs.arc_free_target, which by default is 3 x that of the VM's target free pages as exposed by vm.v_free_target (matching Solaris). Its really late here now and I've only just knocked it together to test it out on our event big cache box over the weekend, so it may be a little rough. All feedback welcome :) Regards Steve ------=_NextPart_000_04A6_01CFBE7B.23C80680 Content-Type: application/octet-stream; name="arc-reclaim.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="arc-reclaim.patch" Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c (revision = 270315)=0A= +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c (working copy)=0A= @@ -138,6 +138,7 @@=0A= #include =0A= =0A= #include =0A= +#include =0A= =0A= #ifdef illumos=0A= #ifndef _KERNEL=0A= @@ -204,11 +205,23 @@=0A= int zfs_arc_p_min_shift =3D 0;=0A= int zfs_disable_dup_eviction =3D 0;=0A= uint64_t zfs_arc_average_blocksize =3D 8 * 1024; /* 8KB */=0A= +u_int zfs_arc_free_target =3D (1 << 30) / PAGE_SIZE; /* 1GB */=0A= =0A= +static void=0A= +arc_free_target_init(void *unused __unused)=0A= +{=0A= +=0A= + zfs_arc_free_target =3D (uint64_t)cnt.v_free_target * 3;=0A= +}=0A= +SYSINIT(arc_free_target_init, SI_SUB_KTHREAD_PAGE, SI_ORDER_ANY,=0A= + arc_free_target_init, NULL);=0A= +=0A= +=0A= TUNABLE_QUAD("vfs.zfs.arc_max", &zfs_arc_max);=0A= TUNABLE_QUAD("vfs.zfs.arc_min", &zfs_arc_min);=0A= TUNABLE_QUAD("vfs.zfs.arc_meta_limit", &zfs_arc_meta_limit);=0A= TUNABLE_QUAD("vfs.zfs.arc_average_blocksize", = &zfs_arc_average_blocksize);=0A= +TUNABLE_INT("vfs.zfs.arc_free_target", &zfs_arc_free_target);=0A= SYSCTL_DECL(_vfs_zfs);=0A= SYSCTL_UQUAD(_vfs_zfs, OID_AUTO, arc_max, CTLFLAG_RDTUN, &zfs_arc_max, = 0,=0A= "Maximum ARC size");=0A= @@ -217,6 +230,9 @@=0A= SYSCTL_UQUAD(_vfs_zfs, OID_AUTO, arc_average_blocksize, CTLFLAG_RDTUN,=0A= &zfs_arc_average_blocksize, 0,=0A= "ARC average blocksize");=0A= +SYSCTL_UINT(_vfs_zfs, OID_AUTO, arc_free_target, CTLFLAG_RWTUN,=0A= + &zfs_arc_free_target, 0,=0A= + "Desired number of free pages below which ARC triggers reclaim");=0A= =0A= /*=0A= * Note that buffers can be in one of 6 states:=0A= @@ -2458,6 +2474,9 @@=0A= if (needfree)=0A= return (1);=0A= =0A= + if (cnt.v_free_count < zfs_arc_free_target)=0A= + return (1);=0A= +=0A= /*=0A= * Cooperate with pagedaemon when it's time for it to scan=0A= * and reclaim some pages.=0A= @@ -2507,9 +2526,6 @@=0A= (btop(vmem_size(heap_arena, VMEM_FREE | VMEM_ALLOC)) >> 2))=0A= return (1);=0A= #endif=0A= -#else /* !sun */=0A= - if (kmem_used() > (kmem_size() * 3) / 4)=0A= - return (1);=0A= #endif /* sun */=0A= =0A= #else=0A= Index: sys/vm/vm_pageout.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/vm/vm_pageout.c (revision 270315)=0A= +++ sys/vm/vm_pageout.c (working copy)=0A= @@ -115,10 +115,14 @@=0A= =0A= /* the kernel process "vm_pageout"*/=0A= static void vm_pageout(void);=0A= +static void vm_pageout_init(void);=0A= static int vm_pageout_clean(vm_page_t);=0A= static void vm_pageout_scan(struct vm_domain *vmd, int pass);=0A= static void vm_pageout_mightbe_oom(struct vm_domain *vmd, int pass);=0A= =0A= +SYSINIT(pagedaemon_init, SI_SUB_KTHREAD_PAGE, SI_ORDER_FIRST, = vm_pageout_init,=0A= + NULL);=0A= +=0A= struct proc *pageproc;=0A= =0A= static struct kproc_desc page_kp =3D {=0A= @@ -126,7 +130,7 @@=0A= vm_pageout,=0A= &pageproc=0A= };=0A= -SYSINIT(pagedaemon, SI_SUB_KTHREAD_PAGE, SI_ORDER_FIRST, kproc_start,=0A= +SYSINIT(pagedaemon, SI_SUB_KTHREAD_PAGE, SI_ORDER_SECOND, kproc_start,=0A= &page_kp);=0A= =0A= #if !defined(NO_SWAPPING)=0A= @@ -1647,15 +1651,11 @@=0A= }=0A= =0A= /*=0A= - * vm_pageout is the high level pageout daemon.=0A= + * vm_pageout_init initialises basic pageout daemon settings.=0A= */=0A= static void=0A= -vm_pageout(void)=0A= +vm_pageout_init(void)=0A= {=0A= -#if MAXMEMDOM > 1=0A= - int error, i;=0A= -#endif=0A= -=0A= /*=0A= * Initialize some paging parameters.=0A= */=0A= @@ -1701,7 +1701,18 @@=0A= /* XXX does not really belong here */=0A= if (vm_page_max_wired =3D=3D 0)=0A= vm_page_max_wired =3D cnt.v_free_count / 3;=0A= +}=0A= =0A= +/*=0A= + * vm_pageout is the high level pageout daemon.=0A= + */=0A= +static void=0A= +vm_pageout(void)=0A= +{=0A= +#if MAXMEMDOM > 1=0A= + int error, i;=0A= +#endif=0A= +=0A= swap_pager_swap_init();=0A= #if MAXMEMDOM > 1=0A= for (i =3D 1; i < vm_ndomains; i++) {=0A= ------=_NextPart_000_04A6_01CFBE7B.23C80680-- From owner-freebsd-fs@FreeBSD.ORG Sat Aug 23 04:53:27 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D9BFE7D for ; Sat, 23 Aug 2014 04:53:27 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1441E3D92 for ; Sat, 23 Aug 2014 04:53:27 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s7N4rQ0S032830 for ; Sat, 23 Aug 2014 04:53:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 149015] [zfs] [patch] misc fixes for ZFS code to build on Glibc Date: Sat, 23 Aug 2014 04:53:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pfg@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 04:53:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=149015 --- Comment #2 from Pedro F. Giffuni --- While I understand this may be good for the Debian kFreeBSD guys, adding them to our local changes may complicate a bit our regular merges from upstream. These should be submitted to the OpenZFS developers directly. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sat Aug 23 11:37:56 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF34E4FA for ; Sat, 23 Aug 2014 11:37:56 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A72893B11 for ; Sat, 23 Aug 2014 11:37:56 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s7NBbuMS062852 for ; Sat, 23 Aug 2014 11:37:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 187594] [zfs] [patch] ZFS ARC behavior problem and fix Date: Sat, 23 Aug 2014 11:37:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: fullermd@over-yonder.net X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 11:37:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 --- Comment #25 from fullermd@over-yonder.net --- Having run it for a few months on a number of boxes now, my general impression is that it seems like it goes a little _too_ far (with default options anyway; I haven't tried any tuning) toward making the ARC give up its lunch money to anybody who looks threateningly at it. It feels like it should be a bit more aggressive, and historically was and did fine. However, it's still _much_ nicer than the unpatched case, where the rest of the system starves and hides out in the swap space. So from here, while perhaps imperfect and in need of some tuning work, it's still a significant improvement on the prior state, so landing it sounds just fine to me. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sat Aug 23 14:14:08 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BACC5C17; Sat, 23 Aug 2014 14:14:08 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 13FA93826; Sat, 23 Aug 2014 14:14:07 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 6700920E70885; Sat, 23 Aug 2014 14:14:00 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1, MIME_QP_LONG_LINE, RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id A99AB20E70885; Sat, 23 Aug 2014 14:13:58 +0000 (UTC) Message-ID: From: "Steven Hartland" To: , References: Subject: Re: [Bug 187594] [zfs] [patch] ZFS ARC behavior problem and fix Date: Sat, 23 Aug 2014 15:13:56 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_05CD_01CFBEE4.DBEE9260" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 14:14:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_05CD_01CFBEE4.DBEE9260 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit ----- Original Message ----- From: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 > > --- Comment #25 from fullermd@over-yonder.net --- > Having run it for a few months on a number of boxes now, my general > impression > is that it seems like it goes a little _too_ far (with default options > anyway; > I haven't tried any tuning) toward making the ARC give up its lunch > money to > anybody who looks threateningly at it. It feels like it should be a > bit more > aggressive, and historically was and did fine. > > However, it's still _much_ nicer than the unpatched case, where the > rest of the > system starves and hides out in the swap space. So from here, while > perhaps > imperfect and in need of some tuning work, it's still a significant > improvement > on the prior state, so landing it sounds just fine to me. The attached updated patch, which has been cleaned up and hammered hard at the event here I'll look to commit to head soon if there are no objections. Regards Steve ------=_NextPart_000_05CD_01CFBEE4.DBEE9260 Content-Type: application/octet-stream; name="arc-reclaim.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="arc-reclaim.patch" Index: sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c (revision 270315)=0A= +++ sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c (working copy)=0A= @@ -126,20 +126,42 @@=0A= }=0A= SYSINIT(kmem_size_init, SI_SUB_KMEM, SI_ORDER_ANY, kmem_size_init, = NULL);=0A= =0A= +/*=0A= + * The returns from kmem_free_*size are only valid once the pagedaemon=0A= + * has been initialised, before then they return 0.=0A= + * =0A= + * To ensure the returns are valid the caller can use a SYSINIT with=0A= + * subsystem set to SI_SUB_KTHREAD_PAGE and order of at least=0A= + * SI_ORDER_SECOND.=0A= + */=0A= uint64_t=0A= -kmem_size(void)=0A= +kmem_free_target_size(void)=0A= {=0A= =0A= - return (kmem_size_val);=0A= + return ((uint64_t)cnt.v_free_target * PAGE_SIZE);=0A= }=0A= =0A= uint64_t=0A= -kmem_used(void)=0A= +kmem_free_min_size(void)=0A= {=0A= =0A= - return (vmem_size(kmem_arena, VMEM_ALLOC));=0A= + return ((uint64_t)cnt.v_free_min * PAGE_SIZE);=0A= }=0A= =0A= +uint64_t=0A= +kmem_free_size(void)=0A= +{=0A= +=0A= + return ((uint64_t)cnt.v_free_count * PAGE_SIZE);=0A= +}=0A= +=0A= +uint64_t=0A= +kmem_size(void)=0A= +{=0A= +=0A= + return (kmem_size_val);=0A= +}=0A= +=0A= static int=0A= kmem_std_constructor(void *mem, int size __unused, void *private, int = flags)=0A= {=0A= Index: sys/cddl/compat/opensolaris/sys/kmem.h=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/cddl/compat/opensolaris/sys/kmem.h (revision 270315)=0A= +++ sys/cddl/compat/opensolaris/sys/kmem.h (working copy)=0A= @@ -66,7 +66,12 @@=0A= void *zfs_kmem_alloc(size_t size, int kmflags);=0A= void zfs_kmem_free(void *buf, size_t size);=0A= uint64_t kmem_size(void);=0A= -uint64_t kmem_used(void);=0A= +=0A= +/* Return vals from kmem_free_*size are only valid after the pagedaemon = init. */=0A= +uint64_t kmem_free_size(void);=0A= +uint64_t kmem_free_target_size(void);=0A= +uint64_t kmem_free_min_size(void);=0A= +=0A= kmem_cache_t *kmem_cache_create(char *name, size_t bufsize, size_t = align,=0A= int (*constructor)(void *, void *, int), void (*destructor)(void *, = void *),=0A= void (*reclaim)(void *) __unused, void *private, vmem_t *vmp, int = cflags);=0A= Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c (revision = 270315)=0A= +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c (working copy)=0A= @@ -193,9 +193,6 @@=0A= */=0A= static boolean_t arc_warm;=0A= =0A= -/*=0A= - * These tunables are for performance analysis.=0A= - */=0A= uint64_t zfs_arc_max;=0A= uint64_t zfs_arc_min;=0A= uint64_t zfs_arc_meta_limit =3D 0;=0A= @@ -204,7 +201,20 @@=0A= int zfs_arc_p_min_shift =3D 0;=0A= int zfs_disable_dup_eviction =3D 0;=0A= uint64_t zfs_arc_average_blocksize =3D 8 * 1024; /* 8KB */=0A= +uint64_t zfs_arc_free_target =3D (1 << 30); /* 1GB */=0A= =0A= +static int sysctl_vfs_zfs_arc_free_target(SYSCTL_HANDLER_ARGS);=0A= +=0A= +static void=0A= +arc_free_target_init(void *unused __unused)=0A= +{=0A= +=0A= + zfs_arc_free_target =3D kmem_free_target_size() * 3;=0A= +}=0A= +SYSINIT(arc_free_target_init, SI_SUB_KTHREAD_PAGE, SI_ORDER_ANY,=0A= + arc_free_target_init, NULL);=0A= +=0A= +=0A= TUNABLE_QUAD("vfs.zfs.arc_max", &zfs_arc_max);=0A= TUNABLE_QUAD("vfs.zfs.arc_min", &zfs_arc_min);=0A= TUNABLE_QUAD("vfs.zfs.arc_meta_limit", &zfs_arc_meta_limit);=0A= @@ -217,7 +227,34 @@=0A= SYSCTL_UQUAD(_vfs_zfs, OID_AUTO, arc_average_blocksize, CTLFLAG_RDTUN,=0A= &zfs_arc_average_blocksize, 0,=0A= "ARC average blocksize");=0A= +/*=0A= + * We don't have a tunable for arc_free_target due to the dependency on=0A= + * pagedaemon initialisation.=0A= + */=0A= +SYSCTL_PROC(_vfs_zfs, OID_AUTO, arc_free_target,=0A= + CTLTYPE_U64 | CTLFLAG_MPSAFE | CTLFLAG_RW, 0, sizeof(uint64_t),=0A= + sysctl_vfs_zfs_arc_free_target, "QU",=0A= + "Desired amount of free memory below which ARC triggers reclaim");=0A= =0A= +static int=0A= +sysctl_vfs_zfs_arc_free_target(SYSCTL_HANDLER_ARGS)=0A= +{=0A= + uint64_t val;=0A= + int err;=0A= +=0A= + val =3D zfs_arc_free_target;=0A= + err =3D sysctl_handle_64(oidp, &val, 0, req);=0A= + if (err !=3D 0 || req->newptr =3D=3D NULL)=0A= + return (err);=0A= +=0A= + if (val < kmem_free_min_size())=0A= + return (EINVAL);=0A= +=0A= + zfs_arc_free_target =3D val;=0A= +=0A= + return (0);=0A= +}=0A= +=0A= /*=0A= * Note that buffers can be in one of 6 states:=0A= * ARC_anon - anonymous (discussed below)=0A= @@ -2421,9 +2458,12 @@=0A= void=0A= arc_shrink(void)=0A= {=0A= +=0A= if (arc_c > arc_c_min) {=0A= uint64_t to_free;=0A= =0A= + DTRACE_PROBE2(arc__shrink, uint64_t, arc_c, uint64_t,=0A= + arc_c_min);=0A= #ifdef _KERNEL=0A= to_free =3D arc_c >> arc_shrink_shift;=0A= #else=0A= @@ -2443,8 +2483,11 @@=0A= ASSERT((int64_t)arc_p >=3D 0);=0A= }=0A= =0A= - if (arc_size > arc_c)=0A= + if (arc_size > arc_c) {=0A= + DTRACE_PROBE2(arc__shrink_adjust, uint64_t, arc_size,=0A= + uint64_t, arc_c);=0A= arc_adjust();=0A= + }=0A= }=0A= =0A= static int needfree =3D 0;=0A= @@ -2455,15 +2498,24 @@=0A= =0A= #ifdef _KERNEL=0A= =0A= - if (needfree)=0A= + if (needfree) {=0A= + DTRACE_PROBE(arc__reclaim_needfree);=0A= return (1);=0A= + }=0A= =0A= + if (kmem_free_size() < zfs_arc_free_target) {=0A= + DTRACE_PROBE(arc__reclaim_freetarget);=0A= + return (1);=0A= + }=0A= +=0A= /*=0A= * Cooperate with pagedaemon when it's time for it to scan=0A= * and reclaim some pages.=0A= */=0A= - if (vm_paging_needed())=0A= + if (vm_paging_needed()) {=0A= + DTRACE_PROBE(arc__reclaim_paging);=0A= return (1);=0A= + }=0A= =0A= #ifdef sun=0A= /*=0A= @@ -2507,9 +2559,6 @@=0A= (btop(vmem_size(heap_arena, VMEM_FREE | VMEM_ALLOC)) >> 2))=0A= return (1);=0A= #endif=0A= -#else /* !sun */=0A= - if (kmem_used() > (kmem_size() * 3) / 4)=0A= - return (1);=0A= #endif /* sun */=0A= =0A= #else=0A= @@ -2516,6 +2565,8 @@=0A= if (spa_get_random(100) =3D=3D 0)=0A= return (1);=0A= #endif=0A= + DTRACE_PROBE(arc__reclaim_no);=0A= +=0A= return (0);=0A= }=0A= =0A= Index: sys/vm/vm_pageout.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- sys/vm/vm_pageout.c (revision 270315)=0A= +++ sys/vm/vm_pageout.c (working copy)=0A= @@ -115,10 +115,14 @@=0A= =0A= /* the kernel process "vm_pageout"*/=0A= static void vm_pageout(void);=0A= +static void vm_pageout_init(void);=0A= static int vm_pageout_clean(vm_page_t);=0A= static void vm_pageout_scan(struct vm_domain *vmd, int pass);=0A= static void vm_pageout_mightbe_oom(struct vm_domain *vmd, int pass);=0A= =0A= +SYSINIT(pagedaemon_init, SI_SUB_KTHREAD_PAGE, SI_ORDER_FIRST, = vm_pageout_init,=0A= + NULL);=0A= +=0A= struct proc *pageproc;=0A= =0A= static struct kproc_desc page_kp =3D {=0A= @@ -126,7 +130,7 @@=0A= vm_pageout,=0A= &pageproc=0A= };=0A= -SYSINIT(pagedaemon, SI_SUB_KTHREAD_PAGE, SI_ORDER_FIRST, kproc_start,=0A= +SYSINIT(pagedaemon, SI_SUB_KTHREAD_PAGE, SI_ORDER_SECOND, kproc_start,=0A= &page_kp);=0A= =0A= #if !defined(NO_SWAPPING)=0A= @@ -1647,15 +1651,11 @@=0A= }=0A= =0A= /*=0A= - * vm_pageout is the high level pageout daemon.=0A= + * vm_pageout_init initialises basic pageout daemon settings.=0A= */=0A= static void=0A= -vm_pageout(void)=0A= +vm_pageout_init(void)=0A= {=0A= -#if MAXMEMDOM > 1=0A= - int error, i;=0A= -#endif=0A= -=0A= /*=0A= * Initialize some paging parameters.=0A= */=0A= @@ -1701,7 +1701,18 @@=0A= /* XXX does not really belong here */=0A= if (vm_page_max_wired =3D=3D 0)=0A= vm_page_max_wired =3D cnt.v_free_count / 3;=0A= +}=0A= =0A= +/*=0A= + * vm_pageout is the high level pageout daemon.=0A= + */=0A= +static void=0A= +vm_pageout(void)=0A= +{=0A= +#if MAXMEMDOM > 1=0A= + int error, i;=0A= +#endif=0A= +=0A= swap_pager_swap_init();=0A= #if MAXMEMDOM > 1=0A= for (i =3D 1; i < vm_ndomains; i++) {=0A= ------=_NextPart_000_05CD_01CFBEE4.DBEE9260-- From owner-freebsd-fs@FreeBSD.ORG Sat Aug 23 14:16:39 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD9BECA8 for ; Sat, 23 Aug 2014 14:16:39 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A54683845 for ; Sat, 23 Aug 2014 14:16:39 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s7NEGdxW049292 for ; Sat, 23 Aug 2014 14:16:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 187594] [zfs] [patch] ZFS ARC behavior problem and fix Date: Sat, 23 Aug 2014 14:16:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: smh@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 14:16:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 Steven Hartland changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |smh@FreeBSD.org --- Comment #26 from Steven Hartland --- I've actually been looking at this patch today in relation to my investigation of: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191510 I would appreciate it if people could test the attached patch, which was created against stable/10 It should achieve the same as Karl's patch as well as: * More closely matching original Solaris logic * Provide better control of the reclaim trigger (absolute not percentage based, which becomes a problem in larger memory machines) * Uses direct kernel values instead of interfacing via sysctl's. * Should fix the issue identified in #191510 as well. Basic design is it will trigger ARC reclaim when free pages drops below vfs.zfs.arc_free_target, which by default is 3 x that of the VM's target free pages as exposed by vm.v_free_target (matching Solaris). -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sat Aug 23 14:18:51 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08820D5F for ; Sat, 23 Aug 2014 14:18:51 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E43E3385E for ; Sat, 23 Aug 2014 14:18:50 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s7NEIomV050049 for ; Sat, 23 Aug 2014 14:18:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 187594] [zfs] [patch] ZFS ARC behavior problem and fix Date: Sat, 23 Aug 2014 14:18:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: smh@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 14:18:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 --- Comment #27 from Steven Hartland --- Created attachment 146178 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=146178&action=edit refactor arc reclaim logic -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sat Aug 23 14:19:16 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99E4DDDD for ; Sat, 23 Aug 2014 14:19:16 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 819AE386F for ; Sat, 23 Aug 2014 14:19:16 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s7NEJGS7050262 for ; Sat, 23 Aug 2014 14:19:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 187594] [zfs] [patch] ZFS ARC behavior problem and fix Date: Sat, 23 Aug 2014 14:19:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: smh@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: smh@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 14:19:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 Steven Hartland changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-fs@FreeBSD.org |smh@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sat Aug 23 15:53:04 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AB056BA for ; Sat, 23 Aug 2014 15:53:04 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5A8F3078 for ; Sat, 23 Aug 2014 15:53:03 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s7NFr3MP061065 for ; Sat, 23 Aug 2014 15:53:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 149014] [zfs] [patch] declarations in ZFS libraries/utilities collide with glibc namespace Date: Sat, 23 Aug 2014 15:53:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pfg@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 15:53:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=149014 Pedro F. Giffuni changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pfg@FreeBSD.org See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=1490 | |15 --- Comment #3 from Pedro F. Giffuni --- As in PR/149015, I think this should be taken to the OpenZFS/Illumos maintainers first to avoid having us to carry too many changes. This should also be useful for the Linux port and are probably cleaner than what they have (I haven't really looked though). -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sat Aug 23 15:53:04 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 564286BC for ; Sat, 23 Aug 2014 15:53:04 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DB1A307B for ; Sat, 23 Aug 2014 15:53:04 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s7NFr4eL061120 for ; Sat, 23 Aug 2014 15:53:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 149015] [zfs] [patch] misc fixes for ZFS code to build on Glibc Date: Sat, 23 Aug 2014 15:53:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pfg@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 15:53:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=149015 Pedro F. Giffuni changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=1490 | |14 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sat Aug 23 18:25:17 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D6BCE9C for ; Sat, 23 Aug 2014 18:25:17 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 146B23F0B for ; Sat, 23 Aug 2014 18:25:17 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s7NIPGf6099157 for ; Sat, 23 Aug 2014 18:25:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 191510] [zfs] ZFS doesn't use all available memory Date: Sat, 23 Aug 2014 18:25:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: smh@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 18:25:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191510 --- Comment #12 from Steven Hartland --- Please try the latest patch on: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sat Aug 23 19:26:07 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83A7B377 for ; Sat, 23 Aug 2014 19:26:07 +0000 (UTC) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B447350F for ; Sat, 23 Aug 2014 19:26:06 +0000 (UTC) Received: by mail-qg0-f54.google.com with SMTP id j5so8903321qga.13 for ; Sat, 23 Aug 2014 12:26:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pMRVTaFq0It4Xq4RVxOoH5seii9mUDklBeYkKyTYaAo=; b=Uuv/FY42uS/NctJTB8inj4nNdkqU8OaUlYKn4OYPCEcDqXiSYphi6cVFx0Mpu/ghaO WHXKDbONxi27J9BzSCsHSl9iJXQ8JfKP/+nbLXwzOJ6b1F3R2gGxqarnVRJOBMnay4CM Zk4pItpMuIKAaFxjqlGkj5rxyoWG/hAOnsdUXgq42mFtIok6SrzLYz85bTs9vpjMUNDR 4eUlaH2KxE4gKZxxZSSnvf2MD/+id4G988G1ubS/RzwrNp/IuHrgWRGrqdNT+jVkUyBP TIs8V7fEpTUjHXXaFJrZy7JXfIBpQsT4RTpeHcv4hmStawdFcYnDInzOg35DFOS99kh2 ERbg== X-Gm-Message-State: ALoCoQkTTWWRPCFul77XoWhMjjt3x3YDmSg/XNP0ca+GG6qADQQ+vMb2n/dLzvKa/Mepra3+54Qe MIME-Version: 1.0 X-Received: by 10.224.88.3 with SMTP id y3mr20235658qal.65.1408821960458; Sat, 23 Aug 2014 12:26:00 -0700 (PDT) Received: by 10.229.213.129 with HTTP; Sat, 23 Aug 2014 12:26:00 -0700 (PDT) X-Originating-IP: [73.189.167.30] In-Reply-To: References: <6ADBB2BF-C7E8-4050-9278-2565A63D2EA8@gluster.org> <20140627070411.GI24440@ivaldir.etoilebsd.net> <0F20AEEC-6244-42BC-815C-1440BBBDE664@mail.turbofuzz.com> <20140629203746.GI34108@ivaldir.etoilebsd.net> <1A58F492-946F-46D4-A19E-2734F368CDAC@mail.turbofuzz.com> <0ABAE2AC-BF1B-4125-ACA9-C6177D013E25@mail.turbofuzz.com> <20140706230910.GA8523@ivaldir.etoilebsd.net> <2F416D06-0A98-4E66-902C-ED0690A4B1C0@ixsystems.com> Date: Sat, 23 Aug 2014 12:26:00 -0700 Message-ID: Subject: Re: FreeBSD support being added to GlusterFS From: Harshavardhana To: Jordan Hubbard Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 19:26:07 -0000 > That is a correct assesment, but Cmockery2 is "patch ready" here - > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192420 - just needs > to be pushed in if there are no other issues. > http://svnweb.freebsd.org/ports?view=revision&revision=365741 - cmockery2 is part of FreeBSD ports now. -- Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes From owner-freebsd-fs@FreeBSD.ORG Sat Aug 23 20:20:18 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 704511F5; Sat, 23 Aug 2014 20:20:18 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B235539AC; Sat, 23 Aug 2014 20:20:17 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 564EA7E4B1; Sat, 23 Aug 2014 13:20:17 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 54327-10; Sat, 23 Aug 2014 13:20:17 -0700 (PDT) Received: from [10.8.0.26] (unknown [10.8.0.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 5E8FC7E4A6; Sat, 23 Aug 2014 13:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1408825217; bh=KEUHK8EK006RDLRg+Cn37ZgiomUq3Aa1EcOgJXCrDz8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=n0uist5FktEKTfilTO5LY1JETVfVh13+JOMwUvTMFblbNDS2uaVAFp3tY6lxc2TVa H/mRvp23MkhTgIQuOtU9y1guLH1QAbYUC/pppsKHGi21dOI4CGe58lc4Tz0nO/zw1b YlHBpZ1UQzZo5rYuySpJw0kzZC8nsWzD4/2XjfAE= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: FreeBSD support being added to GlusterFS From: Jordan Hubbard In-Reply-To: Date: Sat, 23 Aug 2014 13:20:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6ADBB2BF-C7E8-4050-9278-2565A63D2EA8@gluster.org> <20140627070411.GI24440@ivaldir.etoilebsd.net> <0F20AEEC-6244-42BC-815C-1440BBBDE664@mail.turbofuzz.com> <20140629203746.GI34108@ivaldir.etoilebsd.net> <1A58F492-946F-46D4-A19E-2734F368CDAC@mail.turbofuzz.com> <0ABAE2AC-BF1B-4125-ACA9-C6177D013E25@mail.turbofuzz.com> <20140706230910.GA8523@ivaldir.etoilebsd.net> <2F416D06-0A98-4E66-902C-ED0690A4B1C0@ixsystems.com> To: Harshavardhana X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 20:20:18 -0000 Thanks. Please let me know (anyone?) when the glusterfs port is updated = and I=92ll merge them into FreeNAS master and try another build, then I = can give you some test results on a =93live=94 system. - Jordan On Aug 23, 2014, at 12:26 PM, Harshavardhana = wrote: >> That is a correct assesment, but Cmockery2 is "patch ready" here - >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192420 - just = needs >> to be pushed in if there are no other issues. >>=20 >=20 > http://svnweb.freebsd.org/ports?view=3Drevision&revision=3D365741 - > cmockery2 is part of FreeBSD ports now. >=20 > --=20 > Religious confuse piety with mere ritual, the virtuous confuse > regulation with outcomes