From owner-freebsd-fs@FreeBSD.ORG Sun May 9 01:03:07 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6EEFF106566B for ; Sun, 9 May 2010 01:03:07 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 222AE8FC1D for ; Sun, 9 May 2010 01:03:06 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN6m5UuDaFvH/2dsb2JhbACeGHG8f4J3CoIUBI9G X-IronPort-AV: E=Sophos;i="4.52,354,1270440000"; d="scan'208";a="76042589" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 08 May 2010 21:03:06 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 4D51C10842EA; Sat, 8 May 2010 21:03:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5ShntfyQKGW; Sat, 8 May 2010 21:03:05 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id E713310842DC; Sat, 8 May 2010 21:03:04 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o491HsW22951; Sat, 8 May 2010 21:17:55 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sat, 8 May 2010 21:17:54 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Cheng-Lin Yang In-Reply-To: <1273340061.16836.yuwen@exodus.cs.ccu.edu.tw> Message-ID: References: <1272960060.34062.yuwen@exodus.cs.ccu.edu.tw> <4BDFE843.7050600@fuujingroup.com> <1273022040.28218.yuwen@exodus.cs.ccu.edu.tw> <20100505013136.GA48843@icarus.home.lan> <1273026479.56161.yuwen@exodus.cs.ccu.edu.tw> <1273340061.16836.yuwen@exodus.cs.ccu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs , lab Subject: Re: Struggling on NFS problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 01:03:07 -0000 On Sun, 9 May 2010, Cheng-Lin Yang wrote: > Hi Rick and all, > I've upgrade the NFS server up to RELENG_8_0 with Rick's patches. I still see the negative "BioW Hits" on my FreeBSD NFS clients but the system is not hanged as before. So I would say somehow the upgrade is "partially successful" to solve the issue. > The -ve BioW value isn't particularily meaningful. For some reason, it is bogus, but it is just fyi and has no effect on the client's behaviour. (Also, note that it is a client side stat, not one for the server, so it isn't at all relevant to the server.) > Howerver, new issue bumps up after the upgrade, My mail server which runs Dovecot also mounted on NFS server, shows the following error message after the upgrade > ==== > May 8 21:46:24 mail dovecot: IMAP(USERID): fcntl(write-lock) locking failed for file cshome/professor/USERID/Maildir/.OLD2/dovecot.index.log: Operation not supported > May 8 21:46:24 mail dovecot: IMAP(USERID): mail_index_wait_lock_fd() failed with file cshome/professor/USERID/Maildir/.OLD2/dovecot.index.log: Operation not supported > May 8 21:46:24 mail dovecot: IMAP(USERID): fcntl(write-lock) locking failed for file cshome/professor/USERID/Maildir/.OLD2/dovecot.index.log: Operation not supported > May 8 21:46:24 mail dovecot: IMAP(USERID): mail_index_wait_lock_fd() failed with file /cshome/professor/USERID/Maildir/.OLD2/dovecot.index.log: Operation not supported > ==== > > Could you please kindly take a look on this new issue? Thank you. :) > If the files used by dovecot are not being concurrently accessed by other NFS clients, your best bet is to use the "nolockd" option on the mount command for dovecot. (If doevcot is a Linux client, there is a similar mount option, which I think is called "nolock" but can't remember for sure.) This option tells the client to do file locking locally in the client and imho is simpler than trying to get the Network Lock Manager working. If the files are read/write shared among multiple clients, then you'll need to try and get the Network Lock Manager (NLM) going. I don't use it (I've always thought that the protocol was poorly designed and avoided it) so I don't know much about it, but the 2 rpc servers called rpc.statd and rpc.lockd must be running on the server and the clients must be able to IP broadcast to the server. rick From owner-freebsd-fs@FreeBSD.ORG Sun May 9 01:58:21 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD2BA1065675 for ; Sun, 9 May 2010 01:58:21 +0000 (UTC) (envelope-from james-freebsd-fs2@jrv.org) Received: from zimbra.jrv.org (adsl-70-243-84-11.dsl.austtx.swbell.net [70.243.84.11]) by mx1.freebsd.org (Postfix) with ESMTP id 6D29C8FC0C for ; Sun, 9 May 2010 01:58:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.jrv.org (Postfix) with ESMTP id 69EC616A06D for ; Sat, 8 May 2010 20:58:20 -0500 (CDT) X-Virus-Scanned: amavisd-new at zimbra.housenet.jrv Received: from zimbra.jrv.org ([127.0.0.1]) by localhost (zimbra.housenet.jrv [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ai4EZjhSY8IC for ; Sat, 8 May 2010 20:58:19 -0500 (CDT) Received: from [10.0.2.15] (adsl-70-243-84-14.dsl.austtx.swbell.net [70.243.84.14]) by zimbra.jrv.org (Postfix) with ESMTPSA id 9882216A044 for ; Sat, 8 May 2010 20:58:19 -0500 (CDT) Message-ID: <4BE616D6.7000901@jrv.org> Date: Sat, 08 May 2010 20:58:46 -0500 From: "James R. Van Artsdalen" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: ZFS doesn't mountroot: Unable to open /dev/ad4p3 for writing (error=1). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 01:58:21 -0000 FreeBSD 9.0-svn207742 #0: Sat May 8 17:13:06 UTC 2010 root@clunk.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 I am no longer able to boot my newly-created ZFS pools in a VirtualBox VM: the "Unable to open /dev/ad4p3 for writing" error shown below prevents the pool from being imported even though it is found. When the pool was created it was on disk ad6, but it is now booting on ad4: zpool.cache contains wrong disk names so the kernel finds the pool member(s) by guid, not name. I'm guessing that the February 4 change to vdev_geom.c may play a role: if the disk is already exclusively write-opened by the attach-by-guid code then perhaps the g_access that triggers the error message fails because the disk is already open? Also, at newlines are missing from a/some printf in that vdev_geom change. PS. I am already aware of the FLUSH issues of running ZFS in a VM. Trying to mount root from zfs:CLANK vdev_geom_open_by_guid:434[1]: Searching by guid [1167978064333731518]. vdev_geom_read_guid:302[1]: Reading guid from acd0... vdev_geom_read_guid:302[1]: Reading guid from ad4p3... vdev_geom_read_guid:340[1]: guid for ad4p3 is 1167978064333731518 vdev_geom_attach:113[1]: Attachi67978064333731518] succeeded, provider /dev/ad4p3. vdev_geom_detach:174[1]: Closing access to ad4p3. vdev_geom_detach:178[1]: Destroyed consumer to ad4p3. vdev_geom_detach:186[1]: Destroyed geom zfs::vdev. vdev_geom_open_by_guid:434[1]: Searching by guid [1167978064333731518]. vdev_geom_read_guid:302[1]: Reading guid from acd0... vdev_geom_read_guid:302[1]: Reading guid from ad4p3... vdev_geom_read_guid:340[1]: guid for ad4p3 is 1167978064333731518 vdev_geom_attach:113[1]: Attaching to ad4p3. vdev_geom_attach:134[1]: Created geom and consumer for ad4p3. vdev_geom_open_by_guid:445[1]: Attach by guid [1167978064333731518] succeeded, provider /dev/ad4p3. ZFS WARNING: Unable to open /dev/ad4p3 for writing (error=1).vdev_geom_detach:174[1]: Closing access to ad4p3. vdev_geom_detach:178[1]: Destroyed consumer to ad4p3. vdev_geom_detach:186[1]: Destroyed geom zfs::vdev. ROOT MOUNT ERROR: From owner-freebsd-fs@FreeBSD.ORG Sun May 9 02:01:48 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90DAF106566B for ; Sun, 9 May 2010 02:01:48 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 731998FC15 for ; Sun, 9 May 2010 02:01:48 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta01.emeryville.ca.mail.comcast.net with comcast id FDfu1e0021smiN4A1E1oAA; Sun, 09 May 2010 02:01:48 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.emeryville.ca.mail.comcast.net with comcast id FE1n1e0033S48mS8gE1ntT; Sun, 09 May 2010 02:01:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CA1439B425; Sat, 8 May 2010 19:01:45 -0700 (PDT) Date: Sat, 8 May 2010 19:01:45 -0700 From: freebsd To: Rick Macklem Message-ID: <20100509020145.GA6725@icarus.home.lan> References: <1272960060.34062.yuwen@exodus.cs.ccu.edu.tw> <4BDFE843.7050600@fuujingroup.com> <1273022040.28218.yuwen@exodus.cs.ccu.edu.tw> <20100505013136.GA48843@icarus.home.lan> <1273026479.56161.yuwen@exodus.cs.ccu.edu.tw> <1273340061.16836.yuwen@exodus.cs.ccu.edu.tw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs , Cheng-Lin Yang , lab Subject: Re: Struggling on NFS problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 02:01:48 -0000 On Sat, May 08, 2010 at 09:17:54PM -0400, Rick Macklem wrote: > >May 8 21:46:24 mail dovecot: IMAP(USERID): fcntl(write-lock) locking failed for file cshome/professor/USERID/Maildir/.OLD2/dovecot.index.log: Operation not supported > >May 8 21:46:24 mail dovecot: IMAP(USERID): mail_index_wait_lock_fd() failed with file cshome/professor/USERID/Maildir/.OLD2/dovecot.index.log: Operation not supported > >May 8 21:46:24 mail dovecot: IMAP(USERID): fcntl(write-lock) locking failed for file cshome/professor/USERID/Maildir/.OLD2/dovecot.index.log: Operation not supported > >May 8 21:46:24 mail dovecot: IMAP(USERID): mail_index_wait_lock_fd() failed with file /cshome/professor/USERID/Maildir/.OLD2/dovecot.index.log: Operation not supported > >==== > > > >Could you please kindly take a look on this new issue? Thank you. :) > > > If the files used by dovecot are not being concurrently accessed by > other NFS clients, your best bet is to use the "nolockd" option on > the mount command for dovecot. (If doevcot is a Linux client, there > is a similar mount option, which I think is called "nolock" but > can't remember for sure.) Dovecot is an IMAP/POP3 server/daemon. Dovecot is attempting to perform an fcntl() lock on its indexing files. This is happening when one of the OPs users attempts to modify their IMAP mailbox called "OLD2". The Dovecot folks advocate use of dotlocks instead of fcntl() in situations like the above. The OP should set lock_method = dotlock in his dovecot.conf and the problem should go away. If the OP is using Dovecot prior to 1.1, he should consider setting dotlock_use_excl = yes as well (which sets the O_EXCL flag when calling open(2)). All of this is covered in the Dovecot NFS-related documentation: http://wiki.dovecot.org/MailLocation/SharedDisk There are also some other configuration options which are badly described, such as "mail_nfs_storage" and "mail_nfs_index". I have no idea what these do; the descriptions are ambiguous: http://wiki.dovecot.org/MainConfig#Mail_processes -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sun May 9 22:09:13 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E342106566C; Sun, 9 May 2010 22:09:13 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 367148FC14; Sun, 9 May 2010 22:09:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o49M9Deb074743; Sun, 9 May 2010 22:09:13 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o49M9Djo074739; Sun, 9 May 2010 22:09:13 GMT (envelope-from linimon) Date: Sun, 9 May 2010 22:09:13 GMT Message-Id: <201005092209.o49M9Djo074739@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146410: [zfs] [patch] bad file copy performance from UFS to ZFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 22:09:13 -0000 Old Synopsis: [PATCH] bad file copy performance from UFS to ZFS New Synopsis: [zfs] [patch] bad file copy performance from UFS to ZFS Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun May 9 22:08:29 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=146410 From owner-freebsd-fs@FreeBSD.ORG Mon May 10 10:04:12 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 040041065672; Mon, 10 May 2010 10:04:12 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id C94528FC1C; Mon, 10 May 2010 10:04:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4AA4BNF027957; Mon, 10 May 2010 10:04:11 GMT (envelope-from pjd@freefall.freebsd.org) Received: (from pjd@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4AA4BR6027953; Mon, 10 May 2010 10:04:11 GMT (envelope-from pjd) Date: Mon, 10 May 2010 10:04:11 GMT Message-Id: <201005101004.o4AA4BR6027953@freefall.freebsd.org> To: pjd@FreeBSD.org, freebsd-fs@FreeBSD.org, pjd@FreeBSD.org From: pjd@FreeBSD.org Cc: Subject: Re: kern/146410: [zfs] [patch] bad file copy performance from UFS to ZFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 10:04:12 -0000 Synopsis: [zfs] [patch] bad file copy performance from UFS to ZFS Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: pon 10 maj 2010 10:03:51 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=146410 From owner-freebsd-fs@FreeBSD.ORG Mon May 10 11:06:56 2010 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1B4A106566C for ; Mon, 10 May 2010 11:06:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id B61B48FC14 for ; Mon, 10 May 2010 11:06:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4AB6u5p082067 for ; Mon, 10 May 2010 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4AB6u5Z082065 for freebsd-fs@FreeBSD.org; Mon, 10 May 2010 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 May 2010 11:06:56 GMT Message-Id: <201005101106.o4AB6u5Z082065@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 11:06:57 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/146375 fs [nfs] [patch] Typos in macro variables names in sys/fs o kern/145802 fs [zfs] page fault under load o kern/145778 fs [zfs] [panic] panic in zfs_fuid_map_id (known issue fi o kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat s kern/145424 fs [zfs] [patch] move source closer to v15 o kern/145423 fs [zfs] ZFS/zpool status shows deleted/not present pools o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an o kern/145339 fs [zfs] deadlock after detaching block device from raidz o kern/145309 fs [disklabel]: Editing disk label invalidates the whole o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c o kern/144458 fs [nfs] [patch] nfsd fails as a kld o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o bin/144214 fs zfsboot fails on gang block after upgrade to zfs v14 o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o kern/143345 fs [ext2fs] [patch] extfs minor header cleanups to better o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142924 fs [ext2fs] [patch] Small cleanup for the inode struct in o kern/142914 fs [zfs] ZFS performance degradation over time o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142401 fs [ntfs] [patch] Minor updates to NTFS from NetBSD o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140433 fs [zfs] [panic] panic while replaying ZIL after crash o kern/140134 fs [msdosfs] write and fsck destroy filesystem integrity o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs o bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/139363 fs [nfs] diskless root nfs mount from non FreeBSD server o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb f kern/137037 fs [zfs] [hang] zfs rollback on root causes FreeBSD to fr o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic o kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [panic] panic: ffs_truncate: read-only filesystem o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int f kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/129059 fs [zfs] [patch] ZFS bootloader whitelistable via WITHOUT f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS p kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [fs] [snapshot] System crashes when manipulati o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/119735 fs [zfs] geli + ZFS + samba starting on boot panics 7.0-B o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116913 fs [ffs] [panic] ffs_blkfree: freeing free block p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/115645 fs [snapshots] [panic] lockmgr: thread 0xc4c00d80, not ex o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] mount_msdosfs: msdosfs_iconv: Operation not o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/53137 fs [ffs] [panic] background fscking causing ffs_valloc pa o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/33464 fs [ufs] soft update inconsistencies after system crash o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 174 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon May 10 16:16:50 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2CDB11065675; Mon, 10 May 2010 16:16:50 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 046808FC0A; Mon, 10 May 2010 16:16:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4AGGnFO054322; Mon, 10 May 2010 16:16:49 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4AGGn9x054318; Mon, 10 May 2010 16:16:49 GMT (envelope-from linimon) Date: Mon, 10 May 2010 16:16:49 GMT Message-Id: <201005101616.o4AGGn9x054318@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146471: [zfs] [patch] zfs bugfixes (6784757, 6784924, 6826861) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 16:16:50 -0000 Synopsis: [zfs] [patch] zfs bugfixes (6784757, 6784924, 6826861) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 10 16:16:38 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=146471 From owner-freebsd-fs@FreeBSD.ORG Mon May 10 16:40:52 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C312C106566C; Mon, 10 May 2010 16:40:52 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 9AD208FC12; Mon, 10 May 2010 16:40:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4AGeqO2078903; Mon, 10 May 2010 16:40:52 GMT (envelope-from pjd@freefall.freebsd.org) Received: (from pjd@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4AGeqmr078838; Mon, 10 May 2010 16:40:52 GMT (envelope-from pjd) Date: Mon, 10 May 2010 16:40:52 GMT Message-Id: <201005101640.o4AGeqmr078838@freefall.freebsd.org> To: jhell@DataIX.net, pjd@FreeBSD.org, pjd@FreeBSD.org, freebsd-fs@FreeBSD.org From: pjd@FreeBSD.org Cc: Subject: Re: kern/144447: [zfs] sharenfs fsunshare() & fsshare_main() non functiional. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 16:40:52 -0000 Synopsis: [zfs] sharenfs fsunshare() & fsshare_main() non functiional. State-Changed-From-To: feedback->patched State-Changed-By: pjd State-Changed-When: pon 10 maj 2010 16:39:48 UTC State-Changed-Why: I believe problem is fixed in HEAD and stable/8, but the submitter is looking for someone who can merge it to stable/7. Responsible-Changed-From-To: pjd->freebsd-fs Responsible-Changed-By: pjd Responsible-Changed-When: pon 10 maj 2010 16:39:48 UTC Responsible-Changed-Why: I believe problem is fixed in HEAD and stable/8, but the submitter is looking for someone who can merge it to stable/7. http://www.freebsd.org/cgi/query-pr.cgi?pr=144447 From owner-freebsd-fs@FreeBSD.ORG Mon May 10 18:26:02 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F21C106564A for ; Mon, 10 May 2010 18:26:02 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [109.74.192.160]) by mx1.freebsd.org (Postfix) with ESMTP id 43C598FC15 for ; Mon, 10 May 2010 18:26:02 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id D18E7C400D for ; Mon, 10 May 2010 18:10:31 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-3.3 required=8.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from core.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA for ; Mon, 10 May 2010 18:10:31 +0000 (UTC) From: Bruce Cran To: freebsd-fs@freebsd.org Date: Mon, 10 May 2010 19:09:41 +0100 User-Agent: KMail/1.13.3 (FreeBSD/9.0-CURRENT; KDE/4.4.3; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201005101909.41614.bruce@cran.org.uk> Subject: vm.kmem_size and ZFS on 9-CURRENT X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 18:26:02 -0000 Hi, I recently converted my /home and /usr slices over to ZFS on my desktop running 9-CURRENT amd64 with 6GB RAM. In the process of copying data off /var to convert it too, I got the "kmem_map too small" panic, which led me to the thread at http://lists.freebsd.org/pipermail/freebsd- current/2010-April/016984.html which appears to conclude that the defaults even on -CURRENT aren't suitable and that vm.kmem_size needs tuned to be 2xRAM. Since I had followed the guide at http://wiki.freebsd.org/ZFSQuickStartGuide and http://wiki.freebsd.org/ZFSTuningGuide which didn't mention any tuning for amd64 with plenty of memory I had thought 9-CURRENT should "just work". Is the tuning of vm.kmem_size really needed? I've seen mention of an ARC tunable too - does it need changed? -- Bruce Cran From owner-freebsd-fs@FreeBSD.ORG Mon May 10 23:19:05 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A44C71065670 for ; Mon, 10 May 2010 23:19:05 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (fbx.keltia.net [82.230.37.243]) by mx1.freebsd.org (Postfix) with ESMTP id 5F1E48FC12 for ; Mon, 10 May 2010 23:19:05 +0000 (UTC) Received: from centre.keltia.net (unknown [IPv6:2a01:240:fe5c::41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id 639317AC5 for ; Tue, 11 May 2010 01:01:23 +0200 (CEST) Date: Tue, 11 May 2010 01:01:19 +0200 From: Ollivier Robert To: freebsd-fs@freebsd.org Message-ID: <20100510230119.GA97909@centre.keltia.net> References: <201005101909.41614.bruce@cran.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <201005101909.41614.bruce@cran.org.uk> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (keltia.net); Tue, 11 May 2010 01:01:23 +0200 (CEST) Subject: Re: vm.kmem_size and ZFS on 9-CURRENT X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 23:19:05 -0000 According to Bruce Cran: > ZFS on my desktop running 9-CURRENT amd64 with 6GB RAM. In the process of= =20 > copying data off /var to convert it too, I got the "kmem_map too small" p= anic,=20 > which led me to the thread at http://lists.freebsd.org/pipermail/freebsd- > current/2010-April/016984.html which appears to conclude that the default= s=20 > even on -CURRENT aren't suitable and that vm.kmem_size needs tuned to be= =20 > 2xRAM. I'm currently using kmem_size =7F=3D"6G" on a 6GB machine and have got no panic at all.=7F (using the full zfs option though). --=20 Ollivier ROBERT -=3D- FreeBSD: The Power to Serve! -=3D- roberto@keltia.fre= enix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-fs@FreeBSD.ORG Mon May 10 23:29:53 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6079D106566B; Mon, 10 May 2010 23:29:53 +0000 (UTC) (envelope-from rpp@ci.com.au) Received: from mippet.ci.com.au (mippet.ci.com.au [192.65.182.30]) by mx1.freebsd.org (Postfix) with ESMTP id EF2578FC21; Mon, 10 May 2010 23:29:52 +0000 (UTC) Received: from mippet.ci.com.au (localhost [127.0.0.1]) by mippet.ci.com.au (8.14.4/8.14.3/CE070809/cml) with ESMTP id o4ANEPUB046926; Tue, 11 May 2010 09:14:26 +1000 (EST) (envelope-from rpp@mippet.ci.com.au) Received: (from rpp@localhost) by mippet.ci.com.au (8.14.4/8.14.3/Submit) id o4ANEOQw046921; Tue, 11 May 2010 09:14:24 +1000 (EST) (envelope-from rpp) Date: Tue, 11 May 2010 09:14:24 +1000 From: Richard Perini To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20100510231424.GA38308@mippet.ci.com.au> References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <20100505075242.GA57550@icarus.home.lan> <4BE13067.1060606@zirakzigil.org> <20100505133302.GB1626@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100505133302.GB1626@garage.freebsd.pl> X-Scanned-By: MIMEDefang 2.67 on 192.65.182.30 Cc: Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 23:29:53 -0000 On Wed, May 05, 2010 at 03:33:02PM +0200, Pawel Jakub Dawidek wrote: > On Wed, May 05, 2010 at 10:46:31AM +0200, Giulio Ferro wrote: > > On 05.05.2010 09:52, Jeremy Chadwick wrote: > > > > Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G... > > [ ... ] > Could you try to track down the commit that is causing your problems? > Could you try 8-STABLE kernel from before r206815? A quick note to say "same here", but on i386. FreeBSD 8.0-STABLE as of 8/5/2010 paniced last night with same symptoms, approx 48 hours uptime. Previous kernel was FreeBSD 8.0-STABLE from Sun Mar 7 14:31:45 EST 2010, perfectly stable for intervening 2 months, about 2 months uptime. Please let me know if full details would help (as opposed to just adding noise :-) -- Richard Perini Internet: rpp@ci.com.au Corinthian Engineering Pty Ltd PHONE: +61 2 9552 5500 Sydney, Australia FAX: +61 2 9552 5549 From owner-freebsd-fs@FreeBSD.ORG Mon May 10 23:43:27 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41A9E106564A; Mon, 10 May 2010 23:43:27 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0A77C8FC12; Mon, 10 May 2010 23:43:26 +0000 (UTC) Received: by pwi9 with SMTP id 9so2062517pwi.13 for ; Mon, 10 May 2010 16:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=mTHuXlbFRPTGjQzy4V0IdkhQr7Ii8QjtzbR+yd5MGkk=; b=DoSlkJ8MwzLpdHNVvOagYiuTtErddKBMT3qDkmAMTEdoniUI+e2kG/B87VerlkWCVL ygD+8aAvnKTevcaivY9QS1vhiVYFLNwVgI+Ka19HOPA6VkNe0cBcJ8Cqhl/4DJ8sYdDd 0cR9DZhAV0Y/bJpMJS4RLHQrXDpltFW3VHfOQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=dtgNMxcpSj4eP76jK3jLBO2u0VijDNAXv/jqLW6hzV26CGlZ7n/lFs81Z7Q9FoLMD9 EOaMtoMZQt4Kzjk1+mX9VK98Kerlooh+lz9RCHWlG6+hSz7V5FiADA/DKi4Asac6KzX7 r+T/4lkce6lGleEJhec8hEu81u7zgrX3q7eTE= MIME-Version: 1.0 Received: by 10.141.214.24 with SMTP id r24mr3132223rvq.273.1273535006377; Mon, 10 May 2010 16:43:26 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.141.40.4 with HTTP; Mon, 10 May 2010 16:43:26 -0700 (PDT) In-Reply-To: <20100510231424.GA38308@mippet.ci.com.au> References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <20100505075242.GA57550@icarus.home.lan> <4BE13067.1060606@zirakzigil.org> <20100505133302.GB1626@garage.freebsd.pl> <20100510231424.GA38308@mippet.ci.com.au> Date: Mon, 10 May 2010 16:43:26 -0700 X-Google-Sender-Auth: 0iSU8Di4EwKPCpYRnK4zoX7Oh_M Message-ID: From: Artem Belevich To: Richard Perini Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 23:43:27 -0000 You can try disabling ZIO_USE_UMA in sys/modules/zfs/Makefile Comment out following line in that file: CFLAGS+=3D-DZIO_USE_UMA This should revert memory allocation method back to its previous mode. Let us know whether it helps or not. --Artem On Mon, May 10, 2010 at 4:14 PM, Richard Perini wrote: > On Wed, May 05, 2010 at 03:33:02PM +0200, Pawel Jakub Dawidek wrote: >> On Wed, May 05, 2010 at 10:46:31AM +0200, Giulio Ferro wrote: >> > On 05.05.2010 09:52, Jeremy Chadwick wrote: >> > >> > Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G= ... >> > > > [ ... ] > >> Could you try to track down the commit that is causing your problems? >> Could you try 8-STABLE kernel from before r206815? > > A quick note to say "same here", but on i386. > > FreeBSD 8.0-STABLE as of 8/5/2010 paniced last night with same symptoms, > approx 48 hours uptime. > > Previous kernel was FreeBSD 8.0-STABLE from Sun Mar =A07 14:31:45 EST 201= 0, > perfectly stable for intervening 2 months, about 2 months uptime. > > Please let me know if full details would help (as opposed to just adding = noise :-) > > -- > Richard Perini =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 Internet: =A0rpp@ci.com.au > Corinthian Engineering Pty Ltd =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 PHONE: =A0 +61 2 9552 5500 > Sydney, Australia =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0FAX: =A0 =A0 +61 2 9552 5549 > _______________________________________________ > 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" > From owner-freebsd-fs@FreeBSD.ORG Mon May 10 23:57:58 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0DC621065673; Mon, 10 May 2010 23:57:57 +0000 (UTC) (envelope-from rpp@ci.com.au) Received: from mippet.ci.com.au (mippet.ci.com.au [192.65.182.30]) by mx1.freebsd.org (Postfix) with ESMTP id 663438FC0A; Mon, 10 May 2010 23:57:57 +0000 (UTC) Received: from mippet.ci.com.au (localhost [127.0.0.1]) by mippet.ci.com.au (8.14.4/8.14.3/CE070809/cml) with ESMTP id o4ANvs9G079379; Tue, 11 May 2010 09:57:55 +1000 (EST) (envelope-from rpp@mippet.ci.com.au) Received: (from rpp@localhost) by mippet.ci.com.au (8.14.4/8.14.3/Submit) id o4ANvr7H079365; Tue, 11 May 2010 09:57:53 +1000 (EST) (envelope-from rpp) Date: Tue, 11 May 2010 09:57:53 +1000 From: Richard Perini To: Artem Belevich Message-ID: <20100510235753.GA74801@mippet.ci.com.au> References: <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <20100505075242.GA57550@icarus.home.lan> <4BE13067.1060606@zirakzigil.org> <20100505133302.GB1626@garage.freebsd.pl> <20100510231424.GA38308@mippet.ci.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.67 on 192.65.182.30 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 23:57:58 -0000 On Mon, May 10, 2010 at 04:43:26PM -0700, Artem Belevich wrote: > You can try disabling ZIO_USE_UMA in sys/modules/zfs/Makefile > > Comment out following line in that file: > CFLAGS+=-DZIO_USE_UMA > > This should revert memory allocation method back to its previous mode. > Let us know whether it helps or not. Thanks Artem, I'll try the suggestion and report back. I'll give it 72 hours. The workload of the machine is fairly consistent day to day. Cheers, -- Richard Perini Internet: rpp@ci.com.au Corinthian Engineering Pty Ltd PHONE: +61 2 9552 5500 Sydney, Australia FAX: +61 2 9552 5549 From owner-freebsd-fs@FreeBSD.ORG Tue May 11 09:20:03 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 154761065781 for ; Tue, 11 May 2010 09:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 066E48FC1F for ; Tue, 11 May 2010 09:20:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4B9K2Ad067473 for ; Tue, 11 May 2010 09:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4B9K2dl067472; Tue, 11 May 2010 09:20:02 GMT (envelope-from gnats) Date: Tue, 11 May 2010 09:20:02 GMT Message-Id: <201005110920.o4B9K2dl067472@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/146471: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 09:20:03 -0000 The following reply was made to PR kern/146471; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/146471: commit references a PR Date: Tue, 11 May 2010 09:19:55 +0000 (UTC) Author: mm Date: Tue May 11 09:19:41 2010 New Revision: 207909 URL: http://svn.freebsd.org/changeset/base/207909 Log: Fix zfs rename (may occasionally fail with dataset busy). OpenSolaris onnv revision: 8517:41a0783dde17 PR: kern/146471 Approved by: pjd, delphij (mentor) Obtained from: OpenSolaris (Bug ID 6784757) MFC after: 3 days Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c Tue May 11 07:25:13 2010 (r207908) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c Tue May 11 09:19:41 2010 (r207909) @@ -19,7 +19,7 @@ * CDDL HEADER END */ /* - * Copyright 2008 Sun Microsystems, Inc. All rights reserved. + * Copyright 2009 Sun Microsystems, Inc. All rights reserved. * Use is subject to license terms. */ @@ -2205,6 +2205,12 @@ dsl_dataset_rename(char *oldname, const err = dsl_dir_open(oldname, FTAG, &dd, &tail); if (err) return (err); + /* + * If there are more than 2 references there may be holds + * hanging around that haven't been cleared out yet. + */ + if (dmu_buf_refcount(dd->dd_dbuf) > 2) + txg_wait_synced(dd->dd_pool, 0); if (tail == NULL) { int delta = strlen(newname) - strlen(oldname); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Tue May 11 09:27:17 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6259106566B; Tue, 11 May 2010 09:27:17 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 9FA8B8FC0C; Tue, 11 May 2010 09:27:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4B9RH0V075571; Tue, 11 May 2010 09:27:17 GMT (envelope-from mm@freefall.freebsd.org) Received: (from mm@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4B9RHhN075567; Tue, 11 May 2010 09:27:17 GMT (envelope-from mm) Date: Tue, 11 May 2010 09:27:17 GMT Message-Id: <201005110927.o4B9RHhN075567@freefall.freebsd.org> To: mm@FreeBSD.org, freebsd-fs@FreeBSD.org, mm@FreeBSD.org From: mm@FreeBSD.org Cc: Subject: Re: kern/146471: [zfs] [patch] zfs bugfixes (6784757, 6784924, 6826861) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 09:27:17 -0000 Synopsis: [zfs] [patch] zfs bugfixes (6784757, 6784924, 6826861) Responsible-Changed-From-To: freebsd-fs->mm Responsible-Changed-By: mm Responsible-Changed-When: Tue May 11 09:27:17 UTC 2010 Responsible-Changed-Why: This is my PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=146471 From owner-freebsd-fs@FreeBSD.ORG Tue May 11 14:21:54 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E739106564A for ; Tue, 11 May 2010 14:21:54 +0000 (UTC) (envelope-from shurik@zk.informjust.ua) Received: from lambent.informjust.ua (lambent.informjust.ua [193.111.173.22]) by mx1.freebsd.org (Postfix) with ESMTP id A27B68FC1D for ; Tue, 11 May 2010 14:21:53 +0000 (UTC) Received: from status.informjust.ua ([10.1.10.202]) by lambent.informjust.ua with esmtp (Exim 4.71) (envelope-from ) id L29CQF-0003M8-26 for freebsd-fs@freebsd.org; Tue, 11 May 2010 16:42:16 +0300 Received: from [192.168.72.1] (helo=zk.informjust.ua) by status.informjust.ua with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OBpk9-0003xN-Gm for freebsd-fs@freebsd.org; Tue, 11 May 2010 16:43:29 +0300 Received: from monstro.zk.informjust.ua ([10.2.113.96]) by zk.informjust.ua with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OBpjl-000BLl-OA for freebsd-fs@freebsd.org; Tue, 11 May 2010 16:43:05 +0300 Message-ID: <4BE95F1F.5090009@zk.informjust.ua> Date: Tue, 11 May 2010 16:43:59 +0300 From: "Alexander V. Ribchansky" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru; rv:1.9.1.5) Gecko/20091217 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: 20100510231424.GA38308@mippet.ci.com.au Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Report: Spam detection software, running on the system "lambent.informjust.ua", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see root@localhost for details. Content preview: As Artem advised, I comment out CFLAGS+=-DZIO_USE_UMA in sys/modules/zfs/Makefile and things like to be "back in USSR :)" if seriously - all become as good as before 18.04.2010 mega ZFS-MFC. While with UMA, Wired memory constantly grow up to kmem_max limit and than PANIC! :(, without it, Wired is approx 380 - 450M on typical 8-STABLE KDE3 desktop with plain ZFS. So or there is something wrong with my (and many many other's people's) hands or UMA broke ZFS at all. [...] Content analysis details: (-3.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.1 BAYES_05 BODY: Bayesian spam probability is 1 to 5% [score: 0.0130] -0.5 AWL AWL: From: address is in the auto white-list X-Spam-Score: -3.4 (---) Subject: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 14:21:54 -0000 As Artem advised, I comment out CFLAGS+=-DZIO_USE_UMA in sys/modules/zfs/Makefile and things like to be "back in USSR :)" if seriously - all become as good as before 18.04.2010 mega ZFS-MFC. While with UMA, Wired memory constantly grow up to kmem_max limit and than PANIC! :(, without it, Wired is approx 380 - 450M on typical 8-STABLE KDE3 desktop with plain ZFS. So or there is something wrong with my (and many many other's people's) hands or UMA broke ZFS at all. Thank you, Artem for hint! I already start to think, that revert to pre-18.04.2010 8-STABLE is the only solution. -- AVR39-RIPE From owner-freebsd-fs@FreeBSD.ORG Tue May 11 15:30:07 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76ED3106566B for ; Tue, 11 May 2010 15:30:07 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8AC438FC0C for ; Tue, 11 May 2010 15:30:05 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 6A61C45CDC; Tue, 11 May 2010 17:30:03 +0200 (CEST) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id DF48745C89; Tue, 11 May 2010 17:29:55 +0200 (CEST) Date: Tue, 11 May 2010 17:29:48 +0200 From: Pawel Jakub Dawidek To: "Alexander V. Ribchansky" Message-ID: <20100511152948.GC1667@garage.freebsd.pl> References: <4BE95F1F.5090009@zk.informjust.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GpGaEY17fSl8rd50" Content-Disposition: inline In-Reply-To: <4BE95F1F.5090009@zk.informjust.ua> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 15:30:07 -0000 --GpGaEY17fSl8rd50 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 11, 2010 at 04:43:59PM +0300, Alexander V. Ribchansky wrote: > As Artem advised, I comment out >=20 > CFLAGS+=3D-DZIO_USE_UMA in sys/modules/zfs/Makefile >=20 > and things like to be "back in USSR :)" if seriously - all become as good= =20 > as before 18.04.2010 mega ZFS-MFC. > While with UMA, Wired memory constantly grow up to kmem_max limit and tha= n=20 > PANIC! :(, without it, Wired is approx 380 - 450M on typical 8-STABLE KDE= 3=20 > desktop with plain ZFS. > So or there is something wrong with my (and many many other's people's)= =20 > hands or UMA broke ZFS at all. >=20 > Thank you, Artem for hint! I already start to think, that revert to=20 > pre-18.04.2010 8-STABLE is the only solution. Thanks for confirmation, I also suspected that. I'll turn using UMA for zio allocations off. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --GpGaEY17fSl8rd50 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvpd+sACgkQForvXbEpPzTMewCbBXFQRFNtGHhGZI8/eYyLP/pT rHIAn0DL3GKqAZPvwgqAYyMMdHdgTxnx =ipyG -----END PGP SIGNATURE----- --GpGaEY17fSl8rd50-- From owner-freebsd-fs@FreeBSD.ORG Tue May 11 15:31:31 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 223B61065688 for ; Tue, 11 May 2010 15:31:31 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id E9F958FC13 for ; Tue, 11 May 2010 15:31:30 +0000 (UTC) Received: by pwi9 with SMTP id 9so2487594pwi.13 for ; Tue, 11 May 2010 08:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=XZeMu43Ss1h/PUy5fia25EVGLRekXO3kghE5Ye6fQCc=; b=jq4/Od5f4FDGPz4gHP/SudS48vlORRKvBfZ4pn4suifOWqzKfR4JbZqY2CjObIde8t KwoHU0g9DKRoEuhbDe0uXPMlxIl0vZRkNs0qOJBg+QjNDQaqIxo4e8vOnI0NDpShId3j aIM6A5gbntdUU/llEDMU7L3KmogzEQJPk1Fk4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=phtKCd609L4pxNGEe9Si9Aud4qv6lBV1MN1z6/tPfksWdwFuOra0HZkbYXScq9mEpJ 4EjvqQqSTI/nF3XAeIihwH+u62h3KTNOL1DyBA1nsl/pLLxmHy1Lex2QZPqX/NZMzGH6 WwvzzVt3BCEZSlrBLWhrVB0rTduP9KhU6JhzU= MIME-Version: 1.0 Received: by 10.141.2.6 with SMTP id e6mr3892264rvi.64.1273591890481; Tue, 11 May 2010 08:31:30 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.141.40.4 with HTTP; Tue, 11 May 2010 08:31:29 -0700 (PDT) In-Reply-To: <4BE95F1F.5090009@zk.informjust.ua> References: <4BE95F1F.5090009@zk.informjust.ua> Date: Tue, 11 May 2010 08:31:29 -0700 X-Google-Sender-Auth: n56IMAGlievsjleKOCRVmtZ7AOI Message-ID: From: Artem Belevich To: "Alexander V. Ribchansky" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 15:31:31 -0000 > Thank you, Artem for hint! I already start to think, that revert to > pre-18.04.2010 8-STABLE is the only solution. I would not rush. the same commit that changed the way ARC memory is allocated has also MFC'ed ton of bugfixes and improvements. --Artem 2010/5/11 Alexander V. Ribchansky : > As Artem advised, I comment out > > CFLAGS+=3D-DZIO_USE_UMA in sys/modules/zfs/Makefile > > and things like to be "back in USSR :)" if seriously - all become as good= as > before 18.04.2010 mega ZFS-MFC. > While with UMA, Wired memory constantly grow up to kmem_max limit and tha= n > PANIC! :(, without it, Wired is approx 380 - 450M on typical 8-STABLE KDE= 3 > desktop with plain ZFS. > So or there is something wrong with my (and many many other's people's) > hands or UMA broke ZFS at all. > > Thank you, Artem for hint! I already start to think, that revert to > pre-18.04.2010 8-STABLE is the only solution. > > -- > =A0 =A0 =A0 =A0AVR39-RIPE > > > > _______________________________________________ > 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" > From owner-freebsd-fs@FreeBSD.ORG Tue May 11 15:44:08 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA0ED106566B; Tue, 11 May 2010 15:44:08 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id B71FA8FC17; Tue, 11 May 2010 15:44:08 +0000 (UTC) Received: by pvf33 with SMTP id 33so180876pvf.13 for ; Tue, 11 May 2010 08:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=I7Ttjeqml12bLItvH25RPky63uhyyLYSuEfjEPRWabU=; b=DrpzeTkty+B/OAl0GhzgMer8Ka2iJJjk9uEYsDVUxiHRBeLYrjKyZdSeQsV+Q72qxG AnwK5S9fkOawu2LC00GuMwgA98zqeys6ng8f9pJHRclfXXJxxno84q6as4pRKxmRwDEc LcsNJy2QMo+HkE1p97KPw9CGunNvfpiIbGc7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=tM409dXdJTpjyMxXsDWTQodL1wScQtv7QRRtvlksHF79G8REyTHDI4l/eAqTkADbdG wKp2IOLdUTzM5C/fmSotp1nt8Bj39JqXgDztGBTskuCA/a2BKHNU1+FHiNn6ig8zp++O rq7erdnsIHDVJYTQygUQshBQgG8cLhpurgCSo= MIME-Version: 1.0 Received: by 10.140.55.9 with SMTP id d9mr3946520rva.164.1273592647774; Tue, 11 May 2010 08:44:07 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.141.40.4 with HTTP; Tue, 11 May 2010 08:44:07 -0700 (PDT) In-Reply-To: <20100511152948.GC1667@garage.freebsd.pl> References: <4BE95F1F.5090009@zk.informjust.ua> <20100511152948.GC1667@garage.freebsd.pl> Date: Tue, 11 May 2010 08:44:07 -0700 X-Google-Sender-Auth: FN6l08r4um0rnWPQjH4xoYdqLNs Message-ID: From: Artem Belevich To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, "Alexander V. Ribchansky" Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 15:44:09 -0000 > Thanks for confirmation, I also suspected that. I'll turn using UMA for > zio allocations off. Perhaps on i386 only? memory fragmentation is only of concern if you don't have enough VM space. on amd64 it's easily solved by bumping vm.kmem_size up -- something that one's typically advised to do anyways. If I understand it correctly, without ZIO_USE_UMA, ZFS ARC allocations would normally be served from power-of-two zones. For relatively random allocations it would result in fair amount of waste for smaller sized allocations. The increase in apparent amount of wired memory is a bit of red herring. If ARC size is limited to below wired max and there's enough physical memory, then UMA caches may keep a lot of memory hanging on caches' free lists. That memory will be given up as soon as pagedaemon bothers to wake up. --Artem On Tue, May 11, 2010 at 8:29 AM, Pawel Jakub Dawidek wrot= e: > On Tue, May 11, 2010 at 04:43:59PM +0300, Alexander V. Ribchansky wrote: >> As Artem advised, I comment out >> >> CFLAGS+=3D-DZIO_USE_UMA in sys/modules/zfs/Makefile >> >> and things like to be "back in USSR :)" if seriously - all become as goo= d >> as before 18.04.2010 mega ZFS-MFC. >> While with UMA, Wired memory constantly grow up to kmem_max limit and th= an >> PANIC! :(, without it, Wired is approx 380 - 450M on typical 8-STABLE KD= E3 >> desktop with plain ZFS. >> So or there is something wrong with my (and many many other's people's) >> hands or UMA broke ZFS at all. >> >> Thank you, Artem for hint! I already start to think, that revert to >> pre-18.04.2010 8-STABLE is the only solution. > > Thanks for confirmation, I also suspected that. I'll turn using UMA for > zio allocations off. > > -- > Pawel Jakub Dawidek =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://ww= w.wheelsystems.com > pjd@FreeBSD.org =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http:= //www.FreeBSD.org > FreeBSD committer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Am I Ev= il? Yes, I Am! > From owner-freebsd-fs@FreeBSD.ORG Tue May 11 17:10:45 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 228D9106566B for ; Tue, 11 May 2010 17:10:45 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id C5DDF8FC0A for ; Tue, 11 May 2010 17:10:43 +0000 (UTC) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta08.westchester.pa.mail.comcast.net with comcast id GBLk1e0070cZkys58HAkLD; Tue, 11 May 2010 17:10:44 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta10.westchester.pa.mail.comcast.net with comcast id GHAi1e00P3S48mS3WHAjGW; Tue, 11 May 2010 17:10:43 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 41FB49B419; Tue, 11 May 2010 10:10:41 -0700 (PDT) Date: Tue, 11 May 2010 10:10:41 -0700 From: Jeremy Chadwick To: "Alexander V. Ribchansky" Message-ID: <20100511171041.GA2930@icarus.home.lan> References: <4BE95F1F.5090009@zk.informjust.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE95F1F.5090009@zk.informjust.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 17:10:45 -0000 On Tue, May 11, 2010 at 04:43:59PM +0300, Alexander V. Ribchansky wrote: > As Artem advised, I comment out > > CFLAGS+=-DZIO_USE_UMA in sys/modules/zfs/Makefile > > and things like to be "back in USSR :)" if seriously - all become as good as before 18.04.2010 mega ZFS-MFC. > While with UMA, Wired memory constantly grow up to kmem_max limit and than PANIC! :(, without it, Wired is approx 380 - 450M on typical 8-STABLE KDE3 desktop with plain ZFS. > So or there is something wrong with my (and many many other's people's) hands or UMA broke ZFS at all. > > Thank you, Artem for hint! I already start to think, that revert to pre-18.04.2010 8-STABLE is the only solution. The interesting thing is that I'm not seeing this behaviour on either of our boxes running RELENG_8 kernel/world dated after 2010/04/18. Below are some stats. I don't know if these are any help. $ for i in localhost ra anubis; do echo ; ssh $i "uname -a ; sysctl kstat.zfs.misc.arcstats | egrep '(p|c|c_min|c_max|\.size|evict_skip|memory_throttle_count):' ; sysctl hw | egrep '(physmem|realmem|usermem):' ; egrep '(kmem_size|arc_max)=' /boot/loader.conf" ; done FreeBSD icarus.home.lan 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Apr 22 06:11:56 PDT 2010 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 kstat.zfs.misc.arcstats.evict_skip: 0 kstat.zfs.misc.arcstats.p: 780308480 kstat.zfs.misc.arcstats.c: 1560281088 kstat.zfs.misc.arcstats.c_min: 201326592 kstat.zfs.misc.arcstats.c_max: 1610612736 kstat.zfs.misc.arcstats.size: 1560271336 kstat.zfs.misc.arcstats.memory_throttle_count: 0 hw.physmem: 4285079552 hw.usermem: 2546024448 hw.realmem: 5100273664 vm.kmem_size="2048M" vfs.zfs.arc_max="1536M" FreeBSD ra 8.0-STABLE FreeBSD 8.0-STABLE #0: Mon Apr 26 02:26:36 PDT 2010 root@ra:/usr/obj/usr/src/sys/X7SBI_RELENG_8_amd64 amd64 kstat.zfs.misc.arcstats.evict_skip: 211067 kstat.zfs.misc.arcstats.p: 2633281083 kstat.zfs.misc.arcstats.c: 2968678030 kstat.zfs.misc.arcstats.c_min: 469762048 kstat.zfs.misc.arcstats.c_max: 3758096384 kstat.zfs.misc.arcstats.size: 2622834360 kstat.zfs.misc.arcstats.memory_throttle_count: 0 hw.physmem: 8580050944 hw.usermem: 2859462656 hw.realmem: 9395240960 vm.kmem_size="4096M" vfs.zfs.arc_max="3584M" FreeBSD anubis 8.0-STABLE FreeBSD 8.0-STABLE #0: Fri Mar 26 10:41:14 PDT 2010 root@anubis:/usr/obj/usr/src/sys/PDSMI_PLUS_RELENG_8_amd64 amd64 kstat.zfs.misc.arcstats.evict_skip: 1395 kstat.zfs.misc.arcstats.p: 1879163904 kstat.zfs.misc.arcstats.c: 3758096384 kstat.zfs.misc.arcstats.c_min: 469762048 kstat.zfs.misc.arcstats.c_max: 3758096384 kstat.zfs.misc.arcstats.size: 1421240344 kstat.zfs.misc.arcstats.memory_throttle_count: 0 hw.physmem: 8580870144 hw.usermem: 6518259712 hw.realmem: 9126805504 vm.kmem_size="4096M" vfs.zfs.arc_max="3584M" -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Tue May 11 19:55:06 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71A05106566B for ; Tue, 11 May 2010 19:55:06 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 2A09C8FC17 for ; Tue, 11 May 2010 19:55:05 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OBvXk-0002ps-6z for freebsd-fs@freebsd.org; Tue, 11 May 2010 21:55:04 +0200 Received: from 142-076-ppp.kubtelecom.ru ([142-076-ppp.kubtelecom.ru]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 May 2010 21:55:04 +0200 Received: from yuri.pankov by 142-076-ppp.kubtelecom.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 May 2010 21:55:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org connect(): No such file or directory From: Yuri Pankov Date: Tue, 11 May 2010 19:44:46 +0000 (UTC) Lines: 20 Message-ID: References: <4BE616D6.7000901@jrv.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 213.132.76.142 (Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.3) Gecko/20100511 Firefox/3.6.3) Subject: Re: ZFS doesn't mountroot: Unable to open /dev/ad4p3 for writing (error=1). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 19:55:06 -0000 James R. Van Artsdalen jrv.org> writes: > > FreeBSD 9.0-svn207742 #0: Sat May 8 17:13:06 UTC 2010 > root clunk.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 > > I am no longer able to boot my newly-created ZFS pools in a VirtualBox > VM: the "Unable to open /dev/ad4p3 for writing" error shown below > prevents the pool from being imported even though it is found. > > When the pool was created it was on disk ad6, but it is now booting on > ad4: zpool.cache contains wrong disk names so the kernel finds the pool > member(s) by guid, not name. Same here on recent -CURRENT. I recently needed to disable ahci(4) driver (pool was created on ada0p3), and got the same error about ad4p3 (device name without ahci driver). Yuri From owner-freebsd-fs@FreeBSD.ORG Tue May 11 21:52:53 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D21D7106564A for ; Tue, 11 May 2010 21:52:53 +0000 (UTC) (envelope-from cmoulin@simplerezo.com) Received: from mail.simplerezo.com (smtp.simplerezo.com [89.185.51.240]) by mx1.freebsd.org (Postfix) with ESMTP id D509A8FC13 for ; Tue, 11 May 2010 21:52:52 +0000 (UTC) Received: (qmail 66569 invoked by uid 89); 11 May 2010 23:26:10 +0200 Received: from unknown (HELO ALIEN) (cmoulin@simplerezo.com@unknown) by unknown (envelope-from cmoulin@simplerezo.com) with SMTP; 11 May 2010 23:26:10 +0200 From: =?iso-8859-1?Q?Cl=E9ment_Moulin?= To: Date: Tue, 11 May 2010 23:26:07 +0200 Organization: SimpleRezo Message-ID: <00e201caf150$91d3b950$b57b2bf0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrxUJF6x69ktKrVSC6sBBL5t974Wg== Content-Language: fr Subject: Very bad ZFS performance on fresh FreeBSD 8 installation X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 21:52:54 -0000 Hi We have recently added 3 new disks to one of our storage servers = (Opteron DualCore 2.2 GHz, 2048 MB RAM). We made a ZFS pool storage of this 3 disks (2 TB each) attached to a = PCIX SATA RAID controllers (3ware 9550SX-16ML), and made a fresh installation = of FreeBSD 8/amd64. Disk performance other the ZFS storage is very bad (about 8-9 MB read or write...). And when machine has low FREE memory (lot of INACTIVE memory used), it's even worst (about 2MB/s)... ~$ uname -a FreeBSD ---.simplerezo.com 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Wed = Apr 28 23:07:37 CEST 2010 root@---.simplerezo.com:/usr/obj/usr/src/sys/KERNEL amd64 # NOTE: tried with -RELEASE, running -STABLE (same results) ~$ zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 5,44T 1,26T 4,18T 23% ONLINE - ~$ zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 da0p2 ONLINE 0 0 0 da1p2 ONLINE 0 0 0 da2p2 ONLINE 0 0 0 errors: No known data errors ~$ tw_cli /c0 show all /c0 Driver Version =3D 3.70.05.001 /c0 Model =3D 9550SX-16ML /c0 Available Memory =3D 224MB /c0 Firmware Version =3D FE9X 3.08.00.029 /c0 Bios Version =3D BE9X 3.10.00.003 /c0 Boot Loader Version =3D BL9X 3.01.00.006 /c0 Serial Number =3D L021603A6120017 /c0 PCB Version =3D Rev 032 /c0 PCHIP Version =3D 1.60 /c0 ACHIP Version =3D 1.70 /c0 Number of Ports =3D 16 /c0 Number of Drives =3D 13 /c0 Number of Units =3D 7 /c0 Total Optimal Units =3D 7 /c0 Not Optimal Units =3D 0 /c0 JBOD Export Policy =3D off /c0 Disk Spinup Policy =3D 1 /c0 Spinup Stagger Time Policy (sec) =3D 1 /c0 Auto-Carving Policy =3D off /c0 Auto-Carving Size =3D 2048 GB /c0 Auto-Rebuild Policy =3D on /c0 Rebuild Rate =3D 1 /c0 Verify Rate =3D 1 /c0 Controller Bus Type =3D PCIX /c0 Controller Bus Width =3D 64 bits /c0 Controller Bus Speed =3D 133 Mhz Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy -------------------------------------------------------------------------= --- -- u0 SINGLE OK - - - 1862.63 ON = OFF u1 SINGLE OK - - - 1862.63 ON = OFF u2 SINGLE OK - - - 1862.63 ON = OFF u3 RAID-5 OK - - 64K 931.303 ON = OFF u4 RAID-5 OK - - 64K 931.303 ON = OFF u5 RAID-5 OK - - 64K 1396.96 ON = OFF u6 SINGLE OK - - - 1862.63 ON = OFF Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 1.82 TB 3907029168 S1UYJ1BZ102991 p1 OK u1 1.82 TB 3907029168 JK1170YAHU3KVP p2 OK u2 1.82 TB 3907029168 S1UYJ1LZ110057 p3 OK u4 465.76 GB 976773168 KRVN33ZAHEKHXD p4 OK u4 465.76 GB 976773168 KRVN33ZAHE54XD p5 OK u4 465.76 GB 976773168 KRVN33ZAHDZPMD p6 OK u5 698.63 GB 1465149168 3QD08DVE p7 OK u5 698.63 GB 1465149168 3QD09JMS p8 OK u5 698.63 GB 1465149168 3QD09758 p9 NOT-PRESENT - - - - p10 NOT-PRESENT - - - - p11 OK u3 465.76 GB 976773168 KRVN33ZAHG0DED p12 OK u3 465.76 GB 976773168 KRVN33ZAHAJ4ZD p13 OK u3 465.76 GB 976773168 KRVN33ZAH80K6D p14 OK u6 1.82 TB 3907029168 JK1120YAG2K1DP p15 NOT-PRESENT - - - - Name OnlineState BBUReady Status Volt Temp Hours = LastCapTest -------------------------------------------------------------------------= -- bbu On Yes OK OK OK 255 = 03-Oct-2009 ~$ diskinfo -c -t /dev/da0 /dev/da0 512 # sectorsize 1999988850688 # mediasize in bytes (1.8T) 3906228224 # mediasize in sectors 243151 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. BZ102991D7FFC800F1DE # Disk ident. I/O command overhead: time to read 10MB block 0.109465 sec =3D 0.005 msec/sector time to read 20480 sectors 3.105226 sec =3D 0.152 msec/sector calculated command overhead =3D 0.146 msec/sector Seek times: Full stroke: 250 iter in 5.754512 sec =3D 23.018 msec Half stroke: 250 iter in 4.829476 sec =3D 19.318 msec Quarter stroke: 500 iter in 9.630453 sec =3D 19.261 msec Short forward: 400 iter in 5.849457 sec =3D 14.624 msec Short backward: 400 iter in 4.123671 sec =3D 10.309 msec Seq outer: 2048 iter in 0.222291 sec =3D 0.109 msec Seq inner: 2048 iter in 0.229290 sec =3D 0.112 msec Transfer rates: outside: 102400 kbytes in 1.024872 sec =3D 99915 = kbytes/sec middle: 102400 kbytes in 1.220958 sec =3D 83869 = kbytes/sec inside: 102400 kbytes in 2.315101 sec =3D 44231 = kbytes/sec ~$ diskinfo -c -t /dev/da1 /dev/da1 512 # sectorsize 1999988850688 # mediasize in bytes (1.8T) 3906228224 # mediasize in sectors 243151 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. YAHU3KVPD7FFCD0054FA # Disk ident. I/O command overhead: time to read 10MB block 0.111094 sec =3D 0.005 msec/sector time to read 20480 sectors 4.501331 sec =3D 0.220 msec/sector calculated command overhead =3D 0.214 msec/sector Seek times: Full stroke: 250 iter in 5.741269 sec =3D 22.965 msec Half stroke: 250 iter in 3.777884 sec =3D 15.112 msec Quarter stroke: 500 iter in 6.487416 sec =3D 12.975 msec Short forward: 400 iter in 3.129467 sec =3D 7.824 msec Short backward: 400 iter in 2.411493 sec =3D 6.029 msec Seq outer: 2048 iter in 0.419405 sec =3D 0.205 msec Seq inner: 2048 iter in 0.425003 sec =3D 0.208 msec Transfer rates: outside: 102400 kbytes in 0.808851 sec =3D 126599 = kbytes/sec middle: 102400 kbytes in 1.716277 sec =3D 59664 = kbytes/sec inside: 102400 kbytes in 1.985879 sec =3D 51564 = kbytes/sec # NOTE: da2 not showed (same h/w as da1) ~$ dd if=3D/dev/zero of=3Dtest1G bs=3D1M count=3D1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 133.956339 secs (8015610 bytes/sec) # gstat and zpool iostat reports same values # The same test done on the same machine (da6 is the similar disk as = da1), on an UFS partition (results is about 80 MB/s): ~$ dd if=3D/dev/zero of=3Dtest1G bs=3D1M count=3D1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 12.543317 secs (85602701 bytes/sec) ~$ cat /boot/loader.conf zfs_load=3D"YES" vfs.root.mountfrom=3D"zfs:tank/root" vfs.zfs.arc_max=3D"64M" vm.kmem_size=3D"1024M" vm.swap_enabled=3D"0" ~$ sysctl vfs.zfs kstat.zfs vfs.zfs.l2c_only_size: 0 vfs.zfs.mfu_ghost_data_lsize: 0 vfs.zfs.mfu_ghost_metadata_lsize: 0 vfs.zfs.mfu_ghost_size: 0 vfs.zfs.mfu_data_lsize: 0 vfs.zfs.mfu_metadata_lsize: 0 vfs.zfs.mfu_size: 114688 vfs.zfs.mru_ghost_data_lsize: 0 vfs.zfs.mru_ghost_metadata_lsize: 0 vfs.zfs.mru_ghost_size: 0 vfs.zfs.mru_data_lsize: 512 vfs.zfs.mru_metadata_lsize: 0 vfs.zfs.mru_size: 59429376 vfs.zfs.anon_data_lsize: 0 vfs.zfs.anon_metadata_lsize: 0 vfs.zfs.anon_size: 1656320 vfs.zfs.l2arc_noprefetch: 0 vfs.zfs.l2arc_feed_secs_shift: 1 vfs.zfs.l2arc_feed_secs: 1 vfs.zfs.l2arc_headroom: 128 vfs.zfs.l2arc_write_boost: 67108864 vfs.zfs.l2arc_write_max: 67108864 vfs.zfs.arc_meta_limit: 16777216 vfs.zfs.arc_meta_used: 107541232 vfs.zfs.mdcomp_disable: 0 vfs.zfs.arc_min: 33554432 vfs.zfs.arc_max: 67108864 vfs.zfs.zfetch.array_rd_sz: 1048576 vfs.zfs.zfetch.block_cap: 256 vfs.zfs.zfetch.min_sec_reap: 2 vfs.zfs.zfetch.max_streams: 8 vfs.zfs.prefetch_disable: 1 vfs.zfs.recover: 0 vfs.zfs.txg.synctime: 5 vfs.zfs.txg.timeout: 30 vfs.zfs.scrub_limit: 10 vfs.zfs.vdev.cache.bshift: 16 vfs.zfs.vdev.cache.size: 10485760 vfs.zfs.vdev.cache.max: 16384 vfs.zfs.vdev.aggregation_limit: 131072 vfs.zfs.vdev.ramp_rate: 2 vfs.zfs.vdev.time_shift: 6 vfs.zfs.vdev.min_pending: 4 vfs.zfs.vdev.max_pending: 35 vfs.zfs.cache_flush_disable: 0 vfs.zfs.zil_disable: 0 vfs.zfs.version.zpl: 3 vfs.zfs.version.vdev_boot: 1 vfs.zfs.version.spa: 13 vfs.zfs.version.dmu_backup_stream: 1 vfs.zfs.version.dmu_backup_header: 2 vfs.zfs.version.acl: 1 vfs.zfs.debug: 0 vfs.zfs.super_owner: 0 kstat.zfs.misc.arcstats.hits: 677531 kstat.zfs.misc.arcstats.misses: 805411 kstat.zfs.misc.arcstats.demand_data_hits: 524276 kstat.zfs.misc.arcstats.demand_data_misses: 570927 kstat.zfs.misc.arcstats.demand_metadata_hits: 153255 kstat.zfs.misc.arcstats.demand_metadata_misses: 234484 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 0 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 0 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 0 kstat.zfs.misc.arcstats.mru_hits: 634920 kstat.zfs.misc.arcstats.mru_ghost_hits: 4103 kstat.zfs.misc.arcstats.mfu_hits: 42611 kstat.zfs.misc.arcstats.mfu_ghost_hits: 5985 kstat.zfs.misc.arcstats.allocated: 1132742 kstat.zfs.misc.arcstats.deleted: 839033 kstat.zfs.misc.arcstats.stolen: 378817 kstat.zfs.misc.arcstats.recycle_miss: 751590 kstat.zfs.misc.arcstats.mutex_miss: 457 kstat.zfs.misc.arcstats.evict_skip: 713728 kstat.zfs.misc.arcstats.hash_elements: 3639 kstat.zfs.misc.arcstats.hash_elements_max: 6958 kstat.zfs.misc.arcstats.hash_collisions: 146864 kstat.zfs.misc.arcstats.hash_chains: 195 kstat.zfs.misc.arcstats.hash_chain_max: 4 kstat.zfs.misc.arcstats.p: 33554432 kstat.zfs.misc.arcstats.c: 33554432 kstat.zfs.misc.arcstats.c_min: 33554432 kstat.zfs.misc.arcstats.c_max: 67108864 kstat.zfs.misc.arcstats.size: 107823344 kstat.zfs.misc.arcstats.hdr_size: 764608 kstat.zfs.misc.arcstats.l2_hits: 0 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 0 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 0 kstat.zfs.misc.arcstats.l2_writes_done: 0 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 0 kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 0 kstat.zfs.misc.arcstats.l2_write_trylock_fail: 0 kstat.zfs.misc.arcstats.l2_write_passed_headroom: 0 kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 0 kstat.zfs.misc.arcstats.l2_write_in_l2: 0 kstat.zfs.misc.arcstats.l2_write_io_in_progress: 0 kstat.zfs.misc.arcstats.l2_write_not_cacheable: 0 kstat.zfs.misc.arcstats.l2_write_full: 0 kstat.zfs.misc.arcstats.l2_write_buffer_iter: 0 kstat.zfs.misc.arcstats.l2_write_pios: 0 kstat.zfs.misc.arcstats.l2_write_bytes_written: 0 kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 0 kstat.zfs.misc.vdev_cache_stats.delegations: 3113 kstat.zfs.misc.vdev_cache_stats.hits: 342284 kstat.zfs.misc.vdev_cache_stats.misses: 50877 ... -- Cl=E9ment Moulin SimpleRezo www.simplerezo.com From owner-freebsd-fs@FreeBSD.ORG Tue May 11 22:02:06 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C6241065673 for ; Tue, 11 May 2010 22:02:06 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by mx1.freebsd.org (Postfix) with ESMTP id 11D8F8FC13 for ; Tue, 11 May 2010 22:02:05 +0000 (UTC) Received: by pzk4 with SMTP id 4so2718001pzk.7 for ; Tue, 11 May 2010 15:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=L+RAYM0Ley3HYvb45Cl6jj3BGUtcrUoTYhrjm3kGjIs=; b=eOUTM7rjedZvYItXBFupXJlXetfGRQrM/5uUP3KTbjxK3gZDSkhEDdpvo1FvRiPy6d KCExVyc2F29t3NUf3QydCFvIb6RX3wPHuMZw7c7ln9Cu7+wdgA7eJGRNTyi9OovrcVqa DnF+8y8yC/9AEUumDj+94qdw8BBPbaf4GYSc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=fZdB/bldCzdbi+B0/kfRjy/qYtuPm9mJrQgaDBD8EaFFFkOxMzqosuwvxD9vxZw3D7 bmW6FRXe2aioRGXYkdy+7mWsWCUY5fCC6orYrUOh9162g8bvPKP0rU6gaFjRNq6a9vib ArX9uroKoNM/FoJcwECcLKATgMiiKp5l+o248= MIME-Version: 1.0 Received: by 10.143.153.23 with SMTP id f23mr4477420wfo.64.1273615325129; Tue, 11 May 2010 15:02:05 -0700 (PDT) Received: by 10.143.41.20 with HTTP; Tue, 11 May 2010 15:02:05 -0700 (PDT) In-Reply-To: <00e201caf150$91d3b950$b57b2bf0$@com> References: <00e201caf150$91d3b950$b57b2bf0$@com> Date: Tue, 11 May 2010 15:02:05 -0700 Message-ID: From: Freddie Cash To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Very bad ZFS performance on fresh FreeBSD 8 installation X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 22:02:06 -0000 You've limited the ARC to 64 MB, limited the kernel to 1 GB, and wondering why performance is slow? :) You're running the 64-bit version of FreeBSD. You can remove the kmem settings from loader.conf. And you should be able to boost the ARC to at least 1 GB (unless you really need the RAM for app uses). The best thing to do to improve performance is to add more RAM. :) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Tue May 11 22:30:27 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBDA0106564A for ; Tue, 11 May 2010 22:30:27 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id EAC258FC1B for ; Tue, 11 May 2010 22:30:26 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 85EFB45E97; Wed, 12 May 2010 00:30:24 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 2D73A45E11; Wed, 12 May 2010 00:30:18 +0200 (CEST) Date: Wed, 12 May 2010 00:30:09 +0200 From: Pawel Jakub Dawidek To: Yuri Pankov Message-ID: <20100511223009.GA3044@garage.freebsd.pl> References: <4BE616D6.7000901@jrv.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS doesn't mountroot: Unable to open /dev/ad4p3 for writing (error=1). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 22:30:27 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 11, 2010 at 07:44:46PM +0000, Yuri Pankov wrote: > James R. Van Artsdalen jrv.org> writes: >=20 > >=20 > > FreeBSD 9.0-svn207742 #0: Sat May 8 17:13:06 UTC 2010 > > root clunk.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 > >=20 > > I am no longer able to boot my newly-created ZFS pools in a VirtualBox > > VM: the "Unable to open /dev/ad4p3 for writing" error shown below > > prevents the pool from being imported even though it is found. > >=20 > > When the pool was created it was on disk ad6, but it is now booting on > > ad4: zpool.cache contains wrong disk names so the kernel finds the pool > > member(s) by guid, not name. > >=20 > Same here on recent -CURRENT. I recently needed to disable ahci(4) driver= (pool > was created on ada0p3), and got the same error about ad4p3 (device name w= ithout > ahci driver). It should be worked around in r207936. Could you guys try it? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvp2nEACgkQForvXbEpPzS1fwCgiyw0LnDlByWC0cJvKg/lIH5z KUIAnj8HchiaGDFAwslliRKMUa2xjVAK =ymme -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From owner-freebsd-fs@FreeBSD.ORG Tue May 11 22:38:28 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B60C51065672 for ; Tue, 11 May 2010 22:38:28 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 06F9E8FC17 for ; Tue, 11 May 2010 22:38:27 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5BAA945CD9; Wed, 12 May 2010 00:38:26 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 3F4C645685; Wed, 12 May 2010 00:38:21 +0200 (CEST) Date: Wed, 12 May 2010 00:38:13 +0200 From: Pawel Jakub Dawidek To: "Alexander V. Ribchansky" Message-ID: <20100511223813.GB3044@garage.freebsd.pl> References: <4BE95F1F.5090009@zk.informjust.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O5XBE6gyVG5Rl6Rj" Content-Disposition: inline In-Reply-To: <4BE95F1F.5090009@zk.informjust.ua> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 22:38:28 -0000 --O5XBE6gyVG5Rl6Rj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 11, 2010 at 04:43:59PM +0300, Alexander V. Ribchansky wrote: > As Artem advised, I comment out >=20 > CFLAGS+=3D-DZIO_USE_UMA in sys/modules/zfs/Makefile >=20 > and things like to be "back in USSR :)" if seriously - all become as good= =20 > as before 18.04.2010 mega ZFS-MFC. > While with UMA, Wired memory constantly grow up to kmem_max limit and tha= n=20 > PANIC! :(, without it, Wired is approx 380 - 450M on typical 8-STABLE KDE= 3=20 > desktop with plain ZFS. > So or there is something wrong with my (and many many other's people's)= =20 > hands or UMA broke ZFS at all. >=20 > Thank you, Artem for hint! I already start to think, that revert to=20 > pre-18.04.2010 8-STABLE is the only solution. Could you try the following patch without disabling UMA? http://people.freebsd.org/~pjd/patches/vfs_subr.c.7.patch It works quite well for me. Also we still don't have back-pressure mechanism when arc_meta_limit is exceeded. OpenSolaris frees namecache entires then and we currently do nothing. I'll experiment with a bit and let you know if the patch above doesn't fix your problem still. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --O5XBE6gyVG5Rl6Rj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvp3FQACgkQForvXbEpPzQHaACg6wqosWZoS9sKdKsA7K0SzJq0 wMgAn14JByxnIaSZsrw2wLxk6PHJKSZ+ =oyce -----END PGP SIGNATURE----- --O5XBE6gyVG5Rl6Rj-- From owner-freebsd-fs@FreeBSD.ORG Tue May 11 23:00:15 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BFC91065670; Tue, 11 May 2010 23:00:15 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id ACA228FC1E; Tue, 11 May 2010 23:00:14 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so1163832fge.13 for ; Tue, 11 May 2010 16:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received :x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=HzdCB3EVRGAY9rLJuDEC02WKs9bNUIHUjzXfAU4RIjk=; b=UjV6fm7SkzmtYm0Q2RkBC8Tb0SLABi78090nf5AfpIgBscTiqbm3K4tuev+bgPVGph P7oUoETUDRc2uVl9LQoHXb95sT7eO3xzJwDGtFFRhjuzL/INCsDRWj7C0uQCJUG/cTll GCtknzlOLqPwEDWFRrELnjg9VW4PJp7O+O/ZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; b=DEB77hPSD3WRljFyxtnldsiTuxuHPZKwEnoSNUtDmE+590XcS4Cv3vg6Zz5ijri2X1 zsRXc1q30dZPJA3Q4fbPZxUToxn7Byxn2KG+N3if+Pe+tCWH22e861NbhpRMc9T/yXst f8IgvsmVZ36ZKWIwPunXXnJGLZfs2Eqcb1d8M= Received: by 10.86.239.37 with SMTP id m37mr12926959fgh.72.1273618813783; Tue, 11 May 2010 16:00:13 -0700 (PDT) Received: from darklight.org.ru ([213.132.76.142]) by mx.google.com with ESMTPS id d13sm12193642fka.32.2010.05.11.16.00.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 May 2010 16:00:13 -0700 (PDT) Received: from darklight.org.ru (yuri@darklight.org.ru [127.0.0.1]) by darklight.org.ru (8.14.4/8.14.4) with ESMTP id o4BN0AqK001892; Wed, 12 May 2010 03:00:11 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by darklight.org.ru (8.14.4/8.14.4/Submit) id o4BN0AqY001890; Wed, 12 May 2010 03:00:10 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: darklight.org.ru: yuri set sender to yuri.pankov@gmail.com using -f Date: Wed, 12 May 2010 03:00:10 +0400 From: Yuri Pankov To: Pawel Jakub Dawidek Message-ID: <20100511230010.GA1608@darklight.org.ru> References: <4BE616D6.7000901@jrv.org> <20100511223009.GA3044@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100511223009.GA3044@garage.freebsd.pl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org Subject: Re: ZFS doesn't mountroot: Unable to open /dev/ad4p3 for writing (error=1). X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 23:00:15 -0000 On Wed, May 12, 2010 at 12:30:09AM +0200, Pawel Jakub Dawidek wrote: > On Tue, May 11, 2010 at 07:44:46PM +0000, Yuri Pankov wrote: > > James R. Van Artsdalen jrv.org> writes: > > > > > > > > FreeBSD 9.0-svn207742 #0: Sat May 8 17:13:06 UTC 2010 > > > root clunk.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 > > > > > > I am no longer able to boot my newly-created ZFS pools in a VirtualBox > > > VM: the "Unable to open /dev/ad4p3 for writing" error shown below > > > prevents the pool from being imported even though it is found. > > > > > > When the pool was created it was on disk ad6, but it is now booting on > > > ad4: zpool.cache contains wrong disk names so the kernel finds the pool > > > member(s) by guid, not name. > > > > > > Same here on recent -CURRENT. I recently needed to disable ahci(4) driver (pool > > was created on ada0p3), and got the same error about ad4p3 (device name without > > ahci driver). > > It should be worked around in r207936. Could you guys try it? > > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! Worked like a charm, successfully booted from ad4p3 (no ahci and ATA_CAM). Thanks, Yuri From owner-freebsd-fs@FreeBSD.ORG Wed May 12 10:22:12 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2DDF106564A for ; Wed, 12 May 2010 10:22:11 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 5C6D18FC08 for ; Wed, 12 May 2010 10:22:11 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id D85DC45F28; Wed, 12 May 2010 12:22:09 +0200 (CEST) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id C1EF045C89; Wed, 12 May 2010 12:22:03 +0200 (CEST) Date: Wed, 12 May 2010 12:21:56 +0200 From: Pawel Jakub Dawidek To: =?iso-8859-1?Q?St=E5le?= Kristoffersen Message-ID: <20100512102156.GE1703@garage.freebsd.pl> References: <20100506012217.GA41806@putsch.kolbu.ws> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZInfyf7laFu/Kiw7" Content-Disposition: inline In-Reply-To: <20100506012217.GA41806@putsch.kolbu.ws> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: Bad hardware + zfs = panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 10:22:12 -0000 --ZInfyf7laFu/Kiw7 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 06, 2010 at 03:22:17AM +0200, St=E5le Kristoffersen wrote: > I've been debugging a hardware error for the past few days, and I think it > was the CPU and that it is now fixed. But reading a file that was written= to a > zfs-pool when stuff got corrupted still triggered a panic in ZFS code: >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x28 > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff8106f2d3 > stack pointer =3D 0x28:0xffffff80774914e0 > frame pointer =3D 0x28:0xffffff8077491510 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 1350 (smbd) > trap number =3D 12 > panic: page fault > cpuid =3D 0 > Uptime: 2m53s >=20 > The lines in the backtrace that got my attention was: > #6 0xffffffff80847c73 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:224 > #7 0xffffffff8106f2d3 in vdev_is_dead (vd=3D0x0) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs= /vdev.c:1847 > #8 0xffffffff8106f2ed in vdev_readable (vd=3D0x0) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs= /vdev.c:1854 >=20 > The complete bt is available here: > http://heim.ifi.uio.no/staalebk/zfs-panic.txt >=20 > As you can see vd=3D0x0, and I think that caused the panic, since it > tried to follow that pointer: > return (vd->vdev_state < VDEV_STATE_DEGRADED); >=20 > I then tried to remove the file and I got this: > Solaris: WARNING: metaslab_free_dva(): bad DVA > 199476166:1296607792756162560 > Solaris: WARNING: metaslab_free_dva(): bad DVA 4236221:7256850009726709760 > Solaris: WARNING: metaslab_free_dva(): bad DVA > 935912721:16480078061480073216 >=20 > Maybe there should be a test to check if vd was zero, and > throw an io-error or something, instead of panicing? Well, I don't think it should be possible for vdev to be NULL. But if you still have this panic, can you try this patch: http://people.freebsd.org/~pjd/patches/vdev_mirror.c.patch --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ZInfyf7laFu/Kiw7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvqgUQACgkQForvXbEpPzRT3QCggcAC+rgE41ax0FogOXLwdndT xc0AoMnrOnLO3C/0GciJBMYblVqwGzAn =nntN -----END PGP SIGNATURE----- --ZInfyf7laFu/Kiw7-- From owner-freebsd-fs@FreeBSD.ORG Wed May 12 11:08:19 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB3ED106567C for ; Wed, 12 May 2010 11:08:19 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 251898FC12 for ; Wed, 12 May 2010 11:08:18 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id A21E945CDC; Wed, 12 May 2010 13:08:17 +0200 (CEST) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id EBEF345C9F; Wed, 12 May 2010 13:08:10 +0200 (CEST) Date: Wed, 12 May 2010 13:08:03 +0200 From: Pawel Jakub Dawidek To: =?iso-8859-1?Q?St=E5le?= Kristoffersen Message-ID: <20100512110803.GF1703@garage.freebsd.pl> References: <20100506012217.GA41806@putsch.kolbu.ws> <20100512102156.GE1703@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9ADF8FXzFeE7X4jE" Content-Disposition: inline In-Reply-To: <20100512102156.GE1703@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: Bad hardware + zfs = panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 11:08:19 -0000 --9ADF8FXzFeE7X4jE Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 12, 2010 at 12:21:56PM +0200, Pawel Jakub Dawidek wrote: > On Thu, May 06, 2010 at 03:22:17AM +0200, St=E5le Kristoffersen wrote: > > I've been debugging a hardware error for the past few days, and I think= it > > was the CPU and that it is now fixed. But reading a file that was writt= en to a > > zfs-pool when stuff got corrupted still triggered a panic in ZFS code: > >=20 > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 0; apic id =3D 00 > > fault virtual address =3D 0x28 > > fault code =3D supervisor read data, page not present > > instruction pointer =3D 0x20:0xffffffff8106f2d3 > > stack pointer =3D 0x28:0xffffff80774914e0 > > frame pointer =3D 0x28:0xffffff8077491510 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > current process =3D 1350 (smbd) > > trap number =3D 12 > > panic: page fault > > cpuid =3D 0 > > Uptime: 2m53s > >=20 > > The lines in the backtrace that got my attention was: > > #6 0xffffffff80847c73 in calltrap () at > > /usr/src/sys/amd64/amd64/exception.S:224 > > #7 0xffffffff8106f2d3 in vdev_is_dead (vd=3D0x0) at > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/z= fs/vdev.c:1847 > > #8 0xffffffff8106f2ed in vdev_readable (vd=3D0x0) at > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/z= fs/vdev.c:1854 > >=20 > > The complete bt is available here: > > http://heim.ifi.uio.no/staalebk/zfs-panic.txt > >=20 > > As you can see vd=3D0x0, and I think that caused the panic, since it > > tried to follow that pointer: > > return (vd->vdev_state < VDEV_STATE_DEGRADED); > >=20 > > I then tried to remove the file and I got this: > > Solaris: WARNING: metaslab_free_dva(): bad DVA > > 199476166:1296607792756162560 > > Solaris: WARNING: metaslab_free_dva(): bad DVA 4236221:7256850009726709= 760 > > Solaris: WARNING: metaslab_free_dva(): bad DVA > > 935912721:16480078061480073216 > >=20 > > Maybe there should be a test to check if vd was zero, and > > throw an io-error or something, instead of panicing? >=20 > Well, I don't think it should be possible for vdev to be NULL. > But if you still have this panic, can you try this patch: >=20 > http://people.freebsd.org/~pjd/patches/vdev_mirror.c.patch It looks like: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=3D6435666 The work-around is to remove /boot/zfs/zpool.cache and import the pool again. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --9ADF8FXzFeE7X4jE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvqjBMACgkQForvXbEpPzTIKQCfSPZ24aVE0byoGcc8QWFu0lSs XWQAniO5HRNLwN6LW7h/iqpelbjkvJgL =zgE8 -----END PGP SIGNATURE----- --9ADF8FXzFeE7X4jE-- From owner-freebsd-fs@FreeBSD.ORG Wed May 12 12:36:49 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6491A1065670; Wed, 12 May 2010 12:36:49 +0000 (UTC) (envelope-from shurik@zk.informjust.ua) Received: from lambent.informjust.ua (lambent.informjust.ua [193.111.173.22]) by mx1.freebsd.org (Postfix) with ESMTP id CB71E8FC1C; Wed, 12 May 2010 12:36:48 +0000 (UTC) Received: from status.informjust.ua ([10.1.10.202]) by lambent.informjust.ua with esmtp (Exim 4.71) (envelope-from ) id L2B4AL-00008I-N8; Wed, 12 May 2010 15:35:11 +0300 Received: from [192.168.72.1] (helo=zk.informjust.ua) by status.informjust.ua with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OCBAr-0009sP-46; Wed, 12 May 2010 15:36:29 +0300 Received: from monstro.zk.informjust.ua ([10.2.113.96]) by zk.informjust.ua with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OCBAS-000BmM-AU; Wed, 12 May 2010 15:36:04 +0300 Message-ID: <4BEAA0EB.3010407@zk.informjust.ua> Date: Wed, 12 May 2010 15:36:59 +0300 From: "Alexander V. Ribchansky" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru; rv:1.9.1.5) Gecko/20091217 Thunderbird/3.0 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4BE95F1F.5090009@zk.informjust.ua> <20100511223813.GB3044@garage.freebsd.pl> In-Reply-To: <20100511223813.GB3044@garage.freebsd.pl> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Report: Spam detection software, running on the system "lambent.informjust.ua", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see root@localhost for details. Content preview: 12.05.2010 01:38, Pawel Jakub Dawidek пишет: > -skip- > Could you try the following patch without disabling UMA? > > http://people.freebsd.org/~pjd/patches/vfs_subr.c.7.patch > > It works quite well for me. > > Also we still don't have back-pressure mechanism when arc_meta_limit is > exceeded. OpenSolaris frees namecache entires then and we currently do > nothing. I'll experiment with a bit and let you know if the patch above > doesn't fix your problem still. > > [...] Content analysis details: (-4.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 AWL AWL: From: address is in the auto white-list X-Spam-Score: -4.0 (----) Cc: freebsd-fs@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 12:36:49 -0000 12.05.2010 01:38, Pawel Jakub Dawidek пишет: > -skip- > Could you try the following patch without disabling UMA? > > http://people.freebsd.org/~pjd/patches/vfs_subr.c.7.patch > > It works quite well for me. > > Also we still don't have back-pressure mechanism when arc_meta_limit is > exceeded. OpenSolaris frees namecache entires then and we currently do > nothing. I'll experiment with a bit and let you know if the patch above > doesn't fix your problem still. > > I apply you patch on today's STABLE. with 2Gb of ram m.kmem_size_max: 1073741824 vm.kmem_size_min: 0 vm.kmem_size: 1073741824 hw.physmem: 2125430784 hw.usermem: 1291554816 hw.realmem: 2146959360 vfs.zfs.arc_max: 268435456 it survive two sequent buildworld & buildkernel. Wired memory is 791M. Without UMA Wired memory was around 500M on THE SAME settings. Could you please explain as for nOOb, what we get with UMA, and why it uses MORE Wired memory? Is it for better perfomance or for what? What is your recomended tuning for i386 FreeBSD-8 on 2Gb ram typical desktop? And.. again, thank you for your great work on ZFS!! You are MONSTER! :) -- AVR39-RIPE From owner-freebsd-fs@FreeBSD.ORG Wed May 12 22:02:22 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A968A106564A for ; Wed, 12 May 2010 22:02:22 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id ECF928FC08 for ; Wed, 12 May 2010 22:02:21 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id CA29945E8E; Thu, 13 May 2010 00:02:20 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 3150E45DF4; Thu, 13 May 2010 00:02:15 +0200 (CEST) Date: Thu, 13 May 2010 00:02:06 +0200 From: Pawel Jakub Dawidek To: "Alexander V. Ribchansky" Message-ID: <20100512220206.GB2154@garage.freebsd.pl> References: <4BE95F1F.5090009@zk.informjust.ua> <20100511223813.GB3044@garage.freebsd.pl> <4BEAA0EB.3010407@zk.informjust.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oLBj+sq0vYjzfsbl" Content-Disposition: inline In-Reply-To: <4BEAA0EB.3010407@zk.informjust.ua> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 22:02:22 -0000 --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 12, 2010 at 03:36:59PM +0300, Alexander V. Ribchansky wrote: > I apply you patch on today's STABLE. with 2Gb of ram > m.kmem_size_max: 1073741824 > vm.kmem_size_min: 0 > vm.kmem_size: 1073741824 >=20 > hw.physmem: 2125430784 > hw.usermem: 1291554816 > hw.realmem: 2146959360 >=20 > vfs.zfs.arc_max: 268435456 >=20 > it survive two sequent buildworld & buildkernel. Wired memory is 791M.=20 > Without UMA Wired memory was around 500M on THE SAME settings. > Could you please explain as for nOOb, what we get with UMA, and why it=20 > uses MORE Wired memory? Is it for better perfomance or for what? [...] Well, UMA doesn't really free memory until it is asked by the pageout daemon when we are running out of physical pages. In general UMA allows to achive better performance than regular malloc(9), but I wasn't the one who decided to switch to UMA - it was Kip Macy. I'm not sure what tests he performed and what performance benefits he measured. > [...] What is=20 > your recomended tuning for i386 FreeBSD-8 on 2Gb ram typical desktop? Well, I was running i386 kernel on my laptop with 2.5GB for a few years without single 'kmem_map too small' panic. I had KVA_PAGES set to 512 in my kernel config and vm.kmem_size set to around 1GB (the biggest possible value I could find). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvrJV0ACgkQForvXbEpPzSJswCfcUrhTGZrZ1z2Qq3gSSkFFDex jFQAnAnWPOql5WOwH2Ox14dzt2VtUaWI =ZicN -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl-- From owner-freebsd-fs@FreeBSD.ORG Thu May 13 00:00:28 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A665E1065674 for ; Thu, 13 May 2010 00:00:28 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 746298FC0C for ; Thu, 13 May 2010 00:00:27 +0000 (UTC) Received: (qmail 12737 invoked from network); 13 May 2010 00:00:26 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@96.224.221.101) by acm.poly.edu with AES256-SHA encrypted SMTP; 13 May 2010 00:00:26 -0000 Message-ID: <4BEB40EB.2030206@acm.poly.edu> Date: Wed, 12 May 2010 19:59:39 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.24 (X11/20100330) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ZFS and __FreeBSD_version X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 00:00:28 -0000 Hi. Can __FreeBSD_version be bumped if ZFS's userland API is ever changed again? I got slightly bitten by the state_to_name()-to-zpool_state_to_name() change from version 6 to version 13 and would like a reliable way of keeping track of this type of stuff in the future. Thanks. -Boris From owner-freebsd-fs@FreeBSD.ORG Thu May 13 05:09:27 2010 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9FAF1065678; Thu, 13 May 2010 05:09:27 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 012828FC0A; Thu, 13 May 2010 05:09:26 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA23551; Thu, 13 May 2010 08:09:24 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OCQfk-000HAS-1E; Thu, 13 May 2010 08:09:24 +0300 Message-ID: <4BEB8983.407@icyb.net.ua> Date: Thu, 13 May 2010 08:09:23 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Navdeep Parhar References: <4B9FD6E0.5000303@icyb.net.ua> <4BD9B406.5070009@icyb.net.ua> <20100429211525.GA91893@hub.freebsd.org> In-Reply-To: <20100429211525.GA91893@hub.freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.ORG Subject: Re: few ideas for zfsloader (boot environments) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 05:09:28 -0000 on 30/04/2010 00:15 Navdeep Parhar said the following: > On Thu, Apr 29, 2010 at 07:29:58PM +0300, Andriy Gapon wrote: >> BTW, it's already possible to use FreeBSD+ZFS+GRUB and have this ability (in some >> form). But it would great to have that "natively". >> >> Couple of useful links: >> http://grub.enbug.org/GRUB2FreeBSDZFS > > ^^^^ Oh, and I hope you weren't crediting me for any of the functionality > explained at the link above..? I have nothing to do with it - it's all > someone else's work. In fact, I'm not too fond of the kfreebsd, > kfreebsd_module, ... style of booting FreeBSD from GRUB2 personally. Oops, I got slightly confused there. BTW, it seems that ZFS support is not 'officially' in GRUB2 yet and you have to patch it? >> http://www.mail-archive.com/grub-devel@gnu.org/msg15161.html > > The patch in this email is the only functionality I've ever offered to the > GRUB project. And that's a very useful one, IMO. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 13 05:50:07 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A3AE1065670 for ; Thu, 13 May 2010 05:50:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0248F8FC0C for ; Thu, 13 May 2010 05:50:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4D5o6YM011832 for ; Thu, 13 May 2010 05:50:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4D5o6iu011831; Thu, 13 May 2010 05:50:06 GMT (envelope-from gnats) Date: Thu, 13 May 2010 05:50:06 GMT Message-Id: <201005130550.o4D5o6iu011831@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/145339: [zfs] deadlock after detaching block device from raidz pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 05:50:07 -0000 The following reply was made to PR kern/145339; it has been noted by GNATS. From: Andriy Gapon To: Alex Bakhtin Cc: bug-followup@freebsd.org, Pawel Jakub Dawidek Subject: Re: kern/145339: [zfs] deadlock after detaching block device from raidz pool Date: Thu, 13 May 2010 08:44:52 +0300 on 04/05/2010 02:23 Alex Bakhtin said the following: > > So, I can still easily reproduce this problem on 8-STABLE. Your > simple patch helps to avoid page fault but dead-locks the system. Are > you sure that you can just return at this point? Probably it make > sense to set some error flag before return? You are correct, my simple patch is far from being correct. And properly fixing the problem is not trivial. Some issues: 1. vdev_geom_release() sets vdev_tsd to NULL before shutting down the corresponding gc_queue; because of that, bios that may later come via vdev_geom_io_intr() can not be mapped to their gc_queue and thus there is no choice but to drop them on the floor. 2. Shutdown logic in vdev_geom_worker() does not seem to be reliable. I think that vdev thread may get stuck forever if a bio happens to be on gc_queue when vdev_geom_release() is called. In that case gc_state check may be skipped and gc_queue may never be waken up again. 3. I am not sure if pending zios are taken care of when vdev_geom_release() is called. If not, then they may get stuck forever. Hopefully Pawel can help us here. > 2010/4/23 Andriy Gapon : >> Can you try this patch? >> >> --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c >> +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c >> @@ -603,6 +603,9 @@ vdev_geom_io_intr(struct bio *bp) >> zio = bp->bio_caller1; >> ctx = zio->io_vd->vdev_tsd; >> >> + if (ctx == NULL) >> + return; >> + >> if ((zio->io_error = bp->bio_error) == 0 && bp->bio_resid != 0) >> zio->io_error = EIO; >> >> >> -- >> Andriy Gapon >> -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 13 05:50:36 2010 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E0181065672 for ; Thu, 13 May 2010 05:50:36 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 670928FC1F for ; Thu, 13 May 2010 05:50:35 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA24455; Thu, 13 May 2010 08:50:32 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OCRJX-000HLh-Tv; Thu, 13 May 2010 08:50:32 +0300 Message-ID: <4BEB9327.6040405@icyb.net.ua> Date: Thu, 13 May 2010 08:50:31 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Volodymyr Kostyrko References: <201004291220.o3TCK3Bo029643@freefall.freebsd.org> <4BE09F5D.2080100@gmail.com> In-Reply-To: <4BE09F5D.2080100@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 05:50:36 -0000 on 05/05/2010 01:27 Volodymyr Kostyrko said the following: > On 29.04.2010 15:20, Andriy Gapon wrote: >> Just to be on the sure side: have you guys actually updated bootblocks on >> your system? I.e. the code that runs before loader and that resides beyond >> filesystems. > > Yes, I do. Pardon me, but please clarify what you mean by this answer. See below for explanation of my confusion. > Actually I was hit by the same bug recently one more time. After rebuild > machine refuses to boot because of some gang blocks. I've tried to use i386 > for the restoration purpose and set up a virtualbox in which I more then ten > times tried to rewrite /boot and reboot from pool. Possible results were: > > * instant crash with colorful junk on the screen, just after the wiggling > dash appear - seems like corrupted zfsloader; * refusing to load kernel > showing the error; * lotsa gibberish about forth words unknown - seems like > loader or some config files corrupted. > > Having played for 1 day with the disk I find that amount of luck for me to > boot should be heavy, so I switched virtualbox to amd64 and just after the > first rewrite of /boot system was up and running. > > 1. I used the same FreeBSD version to rewrite the data: > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201004/FreeBSD-8.0-STABLE-201004-amd64-livefs.iso > > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201004/FreeBSD-8.0-STABLE-201004-i386-livefs.iso > > > 2. I used the same boot code and haven't changed it. This is what I am confused about. What do you mean by the same 'boot code'? I originally asked if you have the *latest* bootcode installed, but you seem to be giving contradicting answers... You detailed your magic workaround of re-writing data, but you haven't mentioned how you updated your boot code. Could you please report the actual commands that you use to update the boot blocks? Just so we are sure that the problem is indeed present in the latest code. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 13 06:00:20 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8951A1065690 for ; Thu, 13 May 2010 06:00:20 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3FD058FC19 for ; Thu, 13 May 2010 06:00:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4D60JRQ019984 for ; Thu, 13 May 2010 06:00:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4D60JW8019983; Thu, 13 May 2010 06:00:19 GMT (envelope-from gnats) Date: Thu, 13 May 2010 06:00:19 GMT Message-Id: <201005130600.o4D60JW8019983@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 06:00:20 -0000 The following reply was made to PR bin/144214; it has been noted by GNATS. From: Andriy Gapon To: bug-followup@FreeBSD.org, c.kworr@gmail.com Cc: Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 Date: Thu, 13 May 2010 08:59:28 +0300 I had a private conversation with Daniel Gerzo (danger@) and neither him nor mm@ are sure that the system for which they reported the problem had the latest boot blocks that are supposed to actually support zfs gang blocks. P.S. gang block support seems to have been added to stable/8 by rnoland@ on 21 Nov 2009 in r199634, so anything before that is not expected to work. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 13 06:44:30 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAE41106566C for ; Thu, 13 May 2010 06:44:30 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 76CEE8FC16 for ; Thu, 13 May 2010 06:44:30 +0000 (UTC) Received: by fxm1 with SMTP id 1so1045523fxm.13 for ; Wed, 12 May 2010 23:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3U1vlDIwkm4TAVQCK1i7l2KjTzJaOIrDZAEsQ3Qa0xc=; b=EQWSvkh3bIh+b0pfBbpkVkw6xP9jARklQREvKlSSRKCOlQCE840EyGXoWWhZb3ssRl JIEdqkcEPdzliQ7teKxeNIl3VfLpyEUURP7wTHxVuhrdDqvyWqVoUSWPw/5rRh70py9U qyT2Wduo4bjrZEZ4HcOwmIkK78KGM+qBnFALs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=d+2Z2Nlhry1bGCZ3D7x/YozwS8TBqkmHGXL60dF8ebCBRUXTeau4uIAvzKaPtdwgd7 YlXC8otHAdkkGT3TCyxvry8h0DguRJC1ADGkjEyb/IgkR7iKP8xIhQ4ZDZeDs1AUBgxz ITzxI62op1j2U9JsuAjYcSUgQW0RZ+pXL+fGk= MIME-Version: 1.0 Received: by 10.103.4.13 with SMTP id g13mr5312470mui.12.1273733069129; Wed, 12 May 2010 23:44:29 -0700 (PDT) Received: by 10.102.244.10 with HTTP; Wed, 12 May 2010 23:44:29 -0700 (PDT) In-Reply-To: <4BEB9327.6040405@icyb.net.ua> References: <201004291220.o3TCK3Bo029643@freefall.freebsd.org> <4BE09F5D.2080100@gmail.com> <4BEB9327.6040405@icyb.net.ua> Date: Thu, 13 May 2010 09:44:29 +0300 Message-ID: From: Volodymyr Kostyrko To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 06:44:31 -0000 2010/5/13 Andriy Gapon : > This is what I am confused about. > What do you mean by the same 'boot code'? > I originally asked if you have the *latest* bootcode installed, but you s= eem to > be giving contradicting answers... > > You detailed your magic workaround of re-writing data, but you haven't me= ntioned > how you updated your boot code. > Could you please report the actual commands that you use to update the bo= ot > blocks? =C2=A0Just so we are sure that the problem is indeed present in t= he latest code. 1. I have updated bootcode just in month or so before the failure. dd if=3D/boot/zfsboot of=3D/dev/slice count=3D1 bs=3D512 dd if=3D/boot/zfsboot of=3D/dev/slice skip=3D1 seek=3D1024 bs=3D512 Yes, this means revision 206815 was not there. 2. After the computer fails this time I haven't touched bootcode. I see your point and I'll try to retest on recent STABLE. This changes nothing though. http://svn.freebsd.org/viewvc/base/stable/8/sys/boot/zfs/zfs.c?r1=3D199634&= r2=3D206815&pathrev=3D206815 I'll try to retest writing on recent STABLE on i386. Maybe not the bootcode is culprit here. --=20 Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Thu May 13 07:00:18 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22C04106566C for ; Thu, 13 May 2010 07:00:18 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F04448FC18 for ; Thu, 13 May 2010 07:00:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4D70HHU075034 for ; Thu, 13 May 2010 07:00:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4D70HWQ075033; Thu, 13 May 2010 07:00:17 GMT (envelope-from gnats) Date: Thu, 13 May 2010 07:00:17 GMT Message-Id: <201005130700.o4D70HWQ075033@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 07:00:18 -0000 The following reply was made to PR bin/144214; it has been noted by GNATS. From: Andriy Gapon To: bug-followup@FreeBSD.org, c.kworr@gmail.com Cc: Robert Noland Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 Date: Thu, 13 May 2010 09:59:00 +0300 This is a multi-part message in MIME format. --------------010603020208000201000600 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit It seems that I have been misunderstanding the problem. "ZFS: gang block detected" won't even appear if boot code is too old. Having briefly glanced over the code and comparing it to the code in osol and in zio_gang_tree_issue(), I think the following change is needed. But I am not sure if it is a real fix for the issue at hand. If anyone can reproduce the problem, could you please test this change? Thanks! -- Andriy Gapon --------------010603020208000201000600 Content-Type: text/plain; name="zfs-boot-gang.patch" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="zfs-boot-gang.patch" ZGlmZiAtLWdpdCBhL3N5cy9ib290L3pmcy96ZnNpbXBsLmMgYi9zeXMvYm9vdC96ZnMvemZz aW1wbC5jCmluZGV4IGRjMjllMGUuLmVhZTAwMjMgMTAwNjQ0Ci0tLSBhL3N5cy9ib290L3pm cy96ZnNpbXBsLmMKKysrIGIvc3lzL2Jvb3QvemZzL3pmc2ltcGwuYwpAQCAtOTYyLDggKzk2 MiwxMyBAQCB6aW9fcmVhZF9nYW5nKHNwYV90ICpzcGEsIGNvbnN0IGJsa3B0cl90ICpicCwg Y29uc3QgZHZhX3QgKmR2YSwgdm9pZCAqYnVmKQogCQlyZXR1cm4gKEVJTyk7CiAKIAlmb3Ig KGkgPSAwOyBpIDwgU1BBX0dCSF9OQkxLUFRSUzsgaSsrKSB7Ci0JCWlmICh6aW9fcmVhZChz cGEsICZ6aW9fZ2IuemdfYmxrcHRyW2ldLCBidWYpKQorCQlibGtwdHJfdCAqZ2JwID0gJnpp b19nYi56Z19ibGtwdHJbaV07CisKKwkJaWYgKEJQX0lTX0hPTEUoZ2JwKSkKKwkJCWNvbnRp bnVlOworCQlpZiAoemlvX3JlYWQoc3BhLCBnYnAsIGJ1ZikpCiAJCQlyZXR1cm4gKEVJTyk7 CisJCWJ1ZiA9IChjaGFyKilidWYgKyBCUF9HRVRfUFNJWkUoZ2JwKTsKIAl9CiAgCiAJcmV0 dXJuICgwKTsK --------------010603020208000201000600-- From owner-freebsd-fs@FreeBSD.ORG Thu May 13 07:35:22 2010 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EB0C106566B; Thu, 13 May 2010 07:35:22 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 96BA48FC19; Thu, 13 May 2010 07:35:20 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA27767; Thu, 13 May 2010 10:35:19 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OCSwx-000Hal-Ge; Thu, 13 May 2010 10:35:19 +0300 Message-ID: <4BEBABB6.2050205@icyb.net.ua> Date: Thu, 13 May 2010 10:35:18 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Navdeep Parhar References: <4B9FD6E0.5000303@icyb.net.ua> <4BD9B406.5070009@icyb.net.ua> <20100429211525.GA91893@hub.freebsd.org> <4BEB8983.407@icyb.net.ua> In-Reply-To: <4BEB8983.407@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.ORG Subject: Re: few ideas for zfsloader (boot environments) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 07:35:22 -0000 on 13/05/2010 08:09 Andriy Gapon said the following: > BTW, it seems that ZFS support is not 'officially' in GRUB2 yet and you have to > patch it? Oh, it's in grub-extras. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 13 07:59:28 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5AB4106566C for ; Thu, 13 May 2010 07:59:28 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 262E68FC20 for ; Thu, 13 May 2010 07:59:27 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA28118 for ; Thu, 13 May 2010 10:59:26 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OCTKH-000Hc8-Oc for freebsd-fs@FreeBSD.org; Thu, 13 May 2010 10:59:25 +0300 Message-ID: <4BEBB15C.5000704@freebsd.org> Date: Thu, 13 May 2010 10:59:24 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4B9FD6E0.5000303@icyb.net.ua> <4BD9B94F.7090709@icyb.net.ua> In-Reply-To: <4BD9B94F.7090709@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: few ideas for zfsloader ( bootfs -> vfs.root.mountfrom) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 07:59:28 -0000 on 29/04/2010 19:52 Andriy Gapon said the following: > I've made some progress on this, see the attached patch. > The patch is not complete. > > What it can do right now: > 1. set vfs.zfs.bootfs to something like "zfs:tank:1111" where 'tank' is a pool > name and '1111' is object id of dataset selected as boot filesystem (e.g. via bootfs). > 2. set vfs.root.mountfrom to value of vfs.zfs.bootfs iff it was not set > explicietly and '/' entry was not found in fstab. > > But right now ZFS can not be mounted using a filesystem specification in the above > format. > > I see two ways forward: > 1. Enhance ZFS mount kernel code, so that it accepts dataset id instead of its > name. This doesn't seem to be very hard. > 2. Enhance zfs boot code (zfsloader) to map boot dataset id to its name. I have > prototype code (unfinished, non-working) for this that navigates from a dataset up > the hierarchy (via dir_obj, parent_dir_obj) and does a reverse lookup in directory > child map to find a name component. > > While #2 seems nicer it also seems to be a waste, since the name will ultimately > be mapped to object id by ZFS kernel code anyways. OpenSolaris+GRUB do things the way described in #1. ZFS v22 has code for mounting a (root) filesystem by its object id. We probably will do the same when our ZFS gets updated to v22. But right now I decided that it's easier for me to follow path #2 and hack on boot code instead of ZFS code. The result is here: http://people.freebsd.org/~avg/zfsboot.diff This patch is supposed to do the job. Main routine is zfs_build_name. Some things to consider/improve: 1. Currently loader sets currdev="zfs0" loaddev="disk0a:" I changed it to currdev="zfs0:" loaddev="zfs0:" Not sure which value in loaddev is more useful and whether it is used anywhere at all. 2. Note amount of code duplication between *zap_lookup and *zap_rlookup. 3. Probably some functions should get better names, e.g. zfs_build_name => zfs_rloookup. 4. Probably there should be checks against buffer overflowing in zfs_build_name and *_rlookup. 5. (zfs)boot2 should pass to loader not only boot pool id, but also boot filesystem id, so that loader doesn't have to repeat bootfs or root dataset lookup. This should come handy when/if zfsboot provides ability to select alternative boot filesystem. 6. spa_t should hold information about a pool, but information about currently 'mounted' filesystem/dataset should go into a separate structure. zfsboot or loader might want to read files from more than one filesystem of the pool. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 13 09:34:44 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C05C31065677; Thu, 13 May 2010 09:34:44 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 979148FC22; Thu, 13 May 2010 09:34:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4D9YitO039466; Thu, 13 May 2010 09:34:44 GMT (envelope-from pjd@freefall.freebsd.org) Received: (from pjd@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4D9YiJL039462; Thu, 13 May 2010 09:34:44 GMT (envelope-from pjd) Date: Thu, 13 May 2010 09:34:44 GMT Message-Id: <201005130934.o4D9YiJL039462@freefall.freebsd.org> To: Alex.Bakhtin@gmail.com, pjd@FreeBSD.org, freebsd-fs@FreeBSD.org, pjd@FreeBSD.org From: pjd@FreeBSD.org Cc: Subject: Re: kern/145339: [zfs] deadlock after detaching block device from raidz pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 09:34:44 -0000 Synopsis: [zfs] deadlock after detaching block device from raidz pool State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: czw 13 maj 2010 09:33:20 UTC State-Changed-Why: Could you try this patch: http://people.freebsd.org/~pjd/patches/vdev_geom.c.3.patch It is against most recent HEAD. If it is rejected on 8-STABLE, just grab entire vdev_geom.c from HEAD and patch this. Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: czw 13 maj 2010 09:33:20 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=145339 From owner-freebsd-fs@FreeBSD.ORG Thu May 13 11:36:33 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F7A8106566C for ; Thu, 13 May 2010 11:36:33 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 183C88FC15 for ; Thu, 13 May 2010 11:36:32 +0000 (UTC) Received: from mb01.admin.lan.kkip.pl ([10.66.3.254]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OCWiF-000NBq-Gi for freebsd-fs@freebsd.org; Thu, 13 May 2010 13:36:30 +0200 Message-ID: <4BEBE437.9020404@kkip.pl> Date: Thu, 13 May 2010 13:36:23 +0200 From: Bartosz Stec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-fs References: <201004291220.o3TCK3Bo029643@freefall.freebsd.org> <4BE09F5D.2080100@gmail.com> <4BEB9327.6040405@icyb.net.ua> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.71 (build at 02-Feb-2010 20:10:28) X-Date: 2010-05-13 13:36:30 X-Connected-IP: 10.66.3.254:1804 X-Message-Linecount: 61 X-Body-Linecount: 47 X-Message-Size: 2984 X-Body-Size: 2209 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 11:36:33 -0000 W dniu 2010-05-13 08:44, Volodymyr Kostyrko pisze: > 2010/5/13 Andriy Gapon: > >> This is what I am confused about. >> What do you mean by the same 'boot code'? >> I originally asked if you have the *latest* bootcode installed, but you seem to >> be giving contradicting answers... >> >> You detailed your magic workaround of re-writing data, but you haven't mentioned >> how you updated your boot code. >> Could you please report the actual commands that you use to update the boot >> blocks? Just so we are sure that the problem is indeed present in the latest code. >> >> I am watching this thread from some time and maybe it's worth to mention that my raidz pool was hit by this bug also on CURRENT on april 30. I did make buildword; make buildkernel; make installkernel; reboot and I didn't realized that at this moment zpool was 98% full (about 300-400MB free space left). Loader catched gang block while trying to loading kernel and after a moment it give up, informing that it can't find from what device is booting from. So at this moment my system was in non-bootable state, with installed kernel but without new world installed. Zpool however was fine, I didn't have any problems accesing it from fixit environment. So what I did at first time was installing world and updating bootblocks from freshly builded /boot using fixit dvd. Of course it left my zpool with even less free space. After reboot loader text show itself for about half a second and after that I could only watch blank screen. I also tried some other things from fixit environment: installing bootcode from 8.0-release (it failed because zpool v13 vs v14 mismatch), revert back from snapshot from time before new world and kernel was build (gang block again), and finally I fixed issue by deleting all snapshots and deleted as max files as possible (so I had about 5GB free space left) and then: cp -pR /boot /boot2 ; mv /boot /boot.bak ; mv /boot2 /boot ; reboot As my system was bootable again, I have csupped new sources, rebuilded world and kernel, updated bootcodes and everything was fine. It seems that bug can be catched only with almost full zpool. -- Bartosz Stec From owner-freebsd-fs@FreeBSD.ORG Thu May 13 11:44:42 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E7771065672; Thu, 13 May 2010 11:44:42 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 60E6A8FC21; Thu, 13 May 2010 11:44:42 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EAB2D46B92; Thu, 13 May 2010 07:44:41 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (localhost [IPv6:::1]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 204478A01F; Thu, 13 May 2010 07:44:41 -0400 (EDT) Message-ID: <4BEBE634.4080102@FreeBSD.org> Date: Thu, 13 May 2010 07:44:52 -0400 From: John Baldwin User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Boris Kochergin References: <4BEB40EB.2030206@acm.poly.edu> In-Reply-To: <4BEB40EB.2030206@acm.poly.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 13 May 2010 07:44:41 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and __FreeBSD_version X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 11:44:42 -0000 Boris Kochergin wrote: > Hi. Can __FreeBSD_version be bumped if ZFS's userland API is ever > changed again? I got slightly bitten by the > state_to_name()-to-zpool_state_to_name() change from version 6 to > version 13 and would like a reliable way of keeping track of this type > of stuff in the future. Thanks. Yes, it should be bumped anytime the API changes. That is definitely a bug that it wasn't done properly last time. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Thu May 13 12:43:20 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13382106566B for ; Thu, 13 May 2010 12:43:20 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 7AFE28FC0A for ; Thu, 13 May 2010 12:43:18 +0000 (UTC) Received: from mb01.admin.lan.kkip.pl ([10.66.3.254]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OCXks-000F4t-Ib for freebsd-fs@freebsd.org; Thu, 13 May 2010 14:43:17 +0200 Message-ID: <4BEBF3DE.4090207@it4pro.pl> Date: Thu, 13 May 2010 14:43:10 +0200 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-fs References: <201004291220.o3TCK3Bo029643@freefall.freebsd.org> <4BE09F5D.2080100@gmail.com> <4BEB9327.6040405@icyb.net.ua> <4BEBE437.9020404@kkip.pl> In-Reply-To: <4BEBE437.9020404@kkip.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.71 (build at 02-Feb-2010 20:10:28) X-Date: 2010-05-13 14:43:17 X-Connected-IP: 10.66.3.254:2522 X-Message-Linecount: 27 X-Body-Linecount: 12 X-Message-Size: 1220 X-Body-Size: 413 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 12:43:20 -0000 W dniu 2010-05-13 13:36, Bartosz Stec pisze: > It seems that bug can be catched only with almost full zpool. > Whoops, I didn't checked earlier what in fact gang block is. If I understand correctly they are straight realted to insufficient space so my conclusion was obvious and useless ;) Fact is - zfs loader doesn't work well with gang blocks, at least it didnt 2 weeks ago on -CURRENT. -- Bartosz Stec From owner-freebsd-fs@FreeBSD.ORG Thu May 13 14:00:13 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B1AD106566C for ; Thu, 13 May 2010 14:00:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E51B78FC18 for ; Thu, 13 May 2010 14:00:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4DE0C7J067983 for ; Thu, 13 May 2010 14:00:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4DE0Cw0067982; Thu, 13 May 2010 14:00:12 GMT (envelope-from gnats) Date: Thu, 13 May 2010 14:00:12 GMT Message-Id: <201005131400.o4DE0Cw0067982@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Robert Noland Cc: Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Robert Noland List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 14:00:13 -0000 The following reply was made to PR bin/144214; it has been noted by GNATS. From: Robert Noland To: Andriy Gapon Cc: bug-followup@FreeBSD.org, c.kworr@gmail.com Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 Date: Thu, 13 May 2010 08:52:14 -0500 Andriy Gapon wrote: > It seems that I have been misunderstanding the problem. > "ZFS: gang block detected" won't even appear if boot code is too old. > > Having briefly glanced over the code and comparing it to the code in osol and in > zio_gang_tree_issue(), I think the following change is needed. > But I am not sure if it is a real fix for the issue at hand. > > If anyone can reproduce the problem, could you please test this change? > Thanks! This looks sane. I was never actually able to test it, since reproducing the issue is rather tricky. robert. > From owner-freebsd-fs@FreeBSD.ORG Thu May 13 21:18:10 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D6D81065675; Thu, 13 May 2010 21:18:10 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 6D9408FC1E; Thu, 13 May 2010 21:18:08 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 891C045E49; Thu, 13 May 2010 23:18:06 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 55DB745C8C; Thu, 13 May 2010 23:18:01 +0200 (CEST) Date: Thu, 13 May 2010 23:17:50 +0200 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20100513211750.GA2015@garage.freebsd.pl> References: <4BEB40EB.2030206@acm.poly.edu> <4BEBE634.4080102@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <4BEBE634.4080102@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and __FreeBSD_version X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 21:18:10 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 13, 2010 at 07:44:52AM -0400, John Baldwin wrote: > Boris Kochergin wrote: > >Hi. Can __FreeBSD_version be bumped if ZFS's userland API is ever=20 > >changed again? I got slightly bitten by the=20 > >state_to_name()-to-zpool_state_to_name() change from version 6 to=20 > >version 13 and would like a reliable way of keeping track of this type= =20 > >of stuff in the future. Thanks. >=20 > Yes, it should be bumped anytime the API changes. That is definitely a= =20 > bug that it wasn't done properly last time. I must disagree here. libzfs API is for ZFS internal use only and is subject to change at any time. This is true for OpenSolaris as well. We, of course, can bump __FreeBSD_version if it helps, but one shouldn't expect libzfs API being stable or there is any care taken to maintain backward compatibility. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvsa9UACgkQForvXbEpPzQsZgCghBidbPcVVPWeC+GECsWdr1SR DLkAnidG37lSqnktEgDwRouqsGqqBl6o =qvas -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-fs@FreeBSD.ORG Thu May 13 21:25:37 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5700C106567A for ; Thu, 13 May 2010 21:25:37 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id EA5CE8FC0A for ; Thu, 13 May 2010 21:25:36 +0000 (UTC) Received: (qmail 42837 invoked from network); 13 May 2010 21:25:36 -0000 Received: from unknown (HELO ?10.0.0.170?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 13 May 2010 21:25:36 -0000 Message-ID: <4BEC6E20.2080005@acm.poly.edu> Date: Thu, 13 May 2010 17:24:48 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.24 (X11/20100330) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4BEB40EB.2030206@acm.poly.edu> <4BEBE634.4080102@FreeBSD.org> <20100513211750.GA2015@garage.freebsd.pl> In-Reply-To: <20100513211750.GA2015@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, John Baldwin Subject: Re: ZFS and __FreeBSD_version X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 21:25:37 -0000 Pawel Jakub Dawidek wrote: > On Thu, May 13, 2010 at 07:44:52AM -0400, John Baldwin wrote: > >> Boris Kochergin wrote: >> >>> Hi. Can __FreeBSD_version be bumped if ZFS's userland API is ever >>> changed again? I got slightly bitten by the >>> state_to_name()-to-zpool_state_to_name() change from version 6 to >>> version 13 and would like a reliable way of keeping track of this type >>> of stuff in the future. Thanks. >>> >> Yes, it should be bumped anytime the API changes. That is definitely a >> bug that it wasn't done properly last time. >> > > I must disagree here. libzfs API is for ZFS internal use only and is > subject to change at any time. This is true for OpenSolaris as well. > We, of course, can bump __FreeBSD_version if it helps, but one shouldn't > expect libzfs API being stable or there is any care taken to maintain > backward compatibility Sure, I understand that it's unstable, but a different __FreeBSD_version for each time it changes (which isn't that often in FreeBSD) would allow my code to do the right thing to cope with it, at the preprocessor. -Boris From owner-freebsd-fs@FreeBSD.ORG Thu May 13 22:04:21 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B68671065677; Thu, 13 May 2010 22:04:21 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7C58FC12; Thu, 13 May 2010 22:04:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4DM4LbL096515; Thu, 13 May 2010 22:04:21 GMT (envelope-from pjd@freefall.freebsd.org) Received: (from pjd@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4DM4KIX096511; Thu, 13 May 2010 22:04:20 GMT (envelope-from pjd) Date: Thu, 13 May 2010 22:04:20 GMT Message-Id: <201005132204.o4DM4KIX096511@freefall.freebsd.org> To: bw@exodus.desync.com, pjd@FreeBSD.org, freebsd-fs@FreeBSD.org, pjd@FreeBSD.org From: pjd@FreeBSD.org Cc: Subject: Re: kern/145802: [zfs] page fault under load X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 22:04:21 -0000 Synopsis: [zfs] page fault under load State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: czw 13 maj 2010 22:03:07 UTC State-Changed-Why: Could you verify if the following patch fixes the problem: http://people.freebsd.org/~pjd/patches/vdev_geom.c.3.patch Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: czw 13 maj 2010 22:03:07 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=145802 From owner-freebsd-fs@FreeBSD.ORG Thu May 13 22:29:18 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2554106567A; Thu, 13 May 2010 22:29:18 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 898B58FC1A; Thu, 13 May 2010 22:29:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4DMTISx014340; Thu, 13 May 2010 22:29:18 GMT (envelope-from pjd@freefall.freebsd.org) Received: (from pjd@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4DMTIMH014336; Thu, 13 May 2010 22:29:18 GMT (envelope-from pjd) Date: Thu, 13 May 2010 22:29:18 GMT Message-Id: <201005132229.o4DMTIMH014336@freefall.freebsd.org> To: daniel.subs@internode.on.net, pjd@FreeBSD.org, freebsd-fs@FreeBSD.org From: pjd@FreeBSD.org Cc: Subject: Re: kern/145712: [zfs] cannot offline two drives in a raidz2 configuration (8.0-stable) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 22:29:18 -0000 Synopsis: [zfs] cannot offline two drives in a raidz2 configuration (8.0-stable) State-Changed-From-To: open->suspended State-Changed-By: pjd State-Changed-When: czw 13 maj 2010 22:26:48 UTC State-Changed-Why: This problem is fixed in recent ZFS, but the fix is too intrusive to back-port it. It has to wait for new ZFS import. BTW. This issue also exists for N-way mirrors where N > 2. http://www.freebsd.org/cgi/query-pr.cgi?pr=145712 From owner-freebsd-fs@FreeBSD.ORG Thu May 13 22:32:29 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5422B1065673; Thu, 13 May 2010 22:32:29 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2A7BC8FC15; Thu, 13 May 2010 22:32:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4DMWScv023516; Thu, 13 May 2010 22:32:28 GMT (envelope-from pjd@freefall.freebsd.org) Received: (from pjd@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4DMWSqO023512; Thu, 13 May 2010 22:32:28 GMT (envelope-from pjd) Date: Thu, 13 May 2010 22:32:28 GMT Message-Id: <201005132232.o4DMWSqO023512@freefall.freebsd.org> To: vermaden@interia.pl, pjd@FreeBSD.org, freebsd-fs@FreeBSD.org, pjd@FreeBSD.org From: pjd@FreeBSD.org Cc: Subject: Re: kern/145423: [zfs] ZFS/zpool status shows deleted/not present pools after scrub X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 22:32:29 -0000 Synopsis: [zfs] ZFS/zpool status shows deleted/not present pools after scrub State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: czw 13 maj 2010 22:31:19 UTC State-Changed-Why: Could you provide outup of: # zdb -l /dev/ada3s3 Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: czw 13 maj 2010 22:31:19 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=145423 From owner-freebsd-fs@FreeBSD.ORG Fri May 14 05:52:05 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36FC2106566B; Fri, 14 May 2010 05:52:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8AAE88FC0A; Fri, 14 May 2010 05:52:04 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o4E5qEYe047281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 08:52:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o4E5q0xS052743; Fri, 14 May 2010 08:52:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4E5q0UI052742; Fri, 14 May 2010 08:52:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 14 May 2010 08:52:00 +0300 From: Kostik Belousov To: Pawel Jakub Dawidek Message-ID: <20100514055200.GM83316@deviant.kiev.zoral.com.ua> References: <4BEB40EB.2030206@acm.poly.edu> <4BEBE634.4080102@FreeBSD.org> <20100513211750.GA2015@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TlDjLAx2PuPdVSSH" Content-Disposition: inline In-Reply-To: <20100513211750.GA2015@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and __FreeBSD_version X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 05:52:05 -0000 --TlDjLAx2PuPdVSSH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 13, 2010 at 11:17:50PM +0200, Pawel Jakub Dawidek wrote: > On Thu, May 13, 2010 at 07:44:52AM -0400, John Baldwin wrote: > > Boris Kochergin wrote: > > >Hi. Can __FreeBSD_version be bumped if ZFS's userland API is ever=20 > > >changed again? I got slightly bitten by the=20 > > >state_to_name()-to-zpool_state_to_name() change from version 6 to=20 > > >version 13 and would like a reliable way of keeping track of this type= =20 > > >of stuff in the future. Thanks. > >=20 > > Yes, it should be bumped anytime the API changes. That is definitely a= =20 > > bug that it wasn't done properly last time. >=20 > I must disagree here. libzfs API is for ZFS internal use only and is > subject to change at any time. This is true for OpenSolaris as well. > We, of course, can bump __FreeBSD_version if it helps, but one shouldn't > expect libzfs API being stable or there is any care taken to maintain > backward compatibility. I agree with you, but please note that the _library_ version bump on import would be right and useful thing, if not already done. --TlDjLAx2PuPdVSSH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvs5QAACgkQC3+MBN1Mb4jLiACeMUu52M5lKfn6HNHBzZwOvD5d ugsAoJBD4XWLR64+lzhR6AwlGHAkcmpB =09I5 -----END PGP SIGNATURE----- --TlDjLAx2PuPdVSSH-- From owner-freebsd-fs@FreeBSD.ORG Fri May 14 06:13:21 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94EA9106567C; Fri, 14 May 2010 06:13:21 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id D77448FC0A; Fri, 14 May 2010 06:13:20 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C96F445E6F; Fri, 14 May 2010 08:13:18 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8468845CAC; Fri, 14 May 2010 08:13:13 +0200 (CEST) Date: Fri, 14 May 2010 08:13:03 +0200 From: Pawel Jakub Dawidek To: Kostik Belousov Message-ID: <20100514061303.GB2015@garage.freebsd.pl> References: <4BEB40EB.2030206@acm.poly.edu> <4BEBE634.4080102@FreeBSD.org> <20100513211750.GA2015@garage.freebsd.pl> <20100514055200.GM83316@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gatW/ieO32f1wygP" Content-Disposition: inline In-Reply-To: <20100514055200.GM83316@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and __FreeBSD_version X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 06:13:21 -0000 --gatW/ieO32f1wygP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 14, 2010 at 08:52:00AM +0300, Kostik Belousov wrote: > On Thu, May 13, 2010 at 11:17:50PM +0200, Pawel Jakub Dawidek wrote: > > On Thu, May 13, 2010 at 07:44:52AM -0400, John Baldwin wrote: > > > Boris Kochergin wrote: > > > >Hi. Can __FreeBSD_version be bumped if ZFS's userland API is ever=20 > > > >changed again? I got slightly bitten by the=20 > > > >state_to_name()-to-zpool_state_to_name() change from version 6 to=20 > > > >version 13 and would like a reliable way of keeping track of this ty= pe=20 > > > >of stuff in the future. Thanks. > > >=20 > > > Yes, it should be bumped anytime the API changes. That is definitely= a=20 > > > bug that it wasn't done properly last time. > >=20 > > I must disagree here. libzfs API is for ZFS internal use only and is > > subject to change at any time. This is true for OpenSolaris as well. > > We, of course, can bump __FreeBSD_version if it helps, but one shouldn't > > expect libzfs API being stable or there is any care taken to maintain > > backward compatibility. >=20 > I agree with you, but please note that the _library_ version bump on impo= rt > would be right and useful thing, if not already done. No it wasn't done. It probably should be done to avoid confusion, although it is still unlikely that old libzfs.so left after upgrade will work with zfs.ko. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --gatW/ieO32f1wygP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvs6e8ACgkQForvXbEpPzT7wACdG6sfPOD07lbwKOQ2aaxQtxbK IEAAoLbkXplEsfuNV0zvu5MxObVTzHBI =tUmb -----END PGP SIGNATURE----- --gatW/ieO32f1wygP-- From owner-freebsd-fs@FreeBSD.ORG Fri May 14 08:21:22 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F395106566B for ; Fri, 14 May 2010 08:21:22 +0000 (UTC) (envelope-from shurik@zk.informjust.ua) Received: from lambent.informjust.ua (lambent.informjust.ua [193.111.173.22]) by mx1.freebsd.org (Postfix) with ESMTP id DA8288FC08 for ; Fri, 14 May 2010 08:21:21 +0000 (UTC) Received: from status.informjust.ua ([10.1.10.202]) by lambent.informjust.ua with esmtp (Exim 4.71) (envelope-from ) id L2EHSL-000FN8-RN for freebsd-fs@freebsd.org; Fri, 14 May 2010 11:19:35 +0300 Received: from [192.168.72.1] (helo=zk.informjust.ua) by status.informjust.ua with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OCq8k-000Kne-PR for freebsd-fs@freebsd.org; Fri, 14 May 2010 11:21:02 +0300 Received: from monstro.zk.informjust.ua ([10.2.113.96]) by zk.informjust.ua with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OCq8K-0009r8-26 for freebsd-fs@freebsd.org; Fri, 14 May 2010 11:20:36 +0300 Message-ID: <4BED0810.10508@zk.informjust.ua> Date: Fri, 14 May 2010 11:21:36 +0300 From: "Alexander V. Ribchansky" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru; rv:1.9.1.5) Gecko/20091217 Thunderbird/3.0 MIME-Version: 1.0 CC: freebsd-fs@freebsd.org References: <4BE95F1F.5090009@zk.informjust.ua> <20100511223813.GB3044@garage.freebsd.pl> In-Reply-To: <20100511223813.GB3044@garage.freebsd.pl> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Report: Spam detection software, running on the system "lambent.informjust.ua", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see root@localhost for details. Content preview: 12.05.2010 01:38, Pawel Jakub Dawidek пишет: > -skip- > Could you try the following patch without disabling UMA? > > http://people.freebsd.org/~pjd/patches/vfs_subr.c.7.patch > > It works quite well for me. > > Also we still don't have back-pressure mechanism when arc_meta_limit is > exceeded. OpenSolaris frees namecache entires then and we currently do > nothing. I'll experiment with a bit and let you know if the patch above > doesn't fix your problem still. > OOps, I do it again! ;) So after several hard days my STABLE gone away again. With your patch and UMA enabled. Wired constantly grow, last time I see it, it was about 940M As Wired grom, perfomance become terrible, buildworld take about 4 hours on Core2quadro.. So my wery IMHO (please don't kill me for it) that UMA allocation on i386 is unusable, correct me if I'm wrong. [...] Content analysis details: (-3.5 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP 1.3 MISSING_HEADERS Missing To: header -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.4 AWL AWL: From: address is in the auto white-list X-Spam-Score: -3.5 (---) Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 08:21:22 -0000 12.05.2010 01:38, Pawel Jakub Dawidek пишет: > -skip- > Could you try the following patch without disabling UMA? > > http://people.freebsd.org/~pjd/patches/vfs_subr.c.7.patch > > It works quite well for me. > > Also we still don't have back-pressure mechanism when arc_meta_limit is > exceeded. OpenSolaris frees namecache entires then and we currently do > nothing. I'll experiment with a bit and let you know if the patch above > doesn't fix your problem still. > OOps, I do it again! ;) So after several hard days my STABLE gone away again. With your patch and UMA enabled. Wired constantly grow, last time I see it, it was about 940M As Wired grom, perfomance become terrible, buildworld take about 4 hours on Core2quadro.. So my wery IMHO (please don't kill me for it) that UMA allocation on i386 is unusable, correct me if I'm wrong. -- AVR39-RIPE From owner-freebsd-fs@FreeBSD.ORG Fri May 14 11:53:24 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 465EF106567E; Fri, 14 May 2010 11:53:24 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1853C8FC26; Fri, 14 May 2010 11:53:24 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id BDC9446B86; Fri, 14 May 2010 07:53:23 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (localhost [IPv6:::1]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 88DB88A025; Fri, 14 May 2010 07:53:22 -0400 (EDT) Message-ID: <4BED346D.30905@FreeBSD.org> Date: Fri, 14 May 2010 07:30:53 -0400 From: John Baldwin User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4BEB40EB.2030206@acm.poly.edu> <4BEBE634.4080102@FreeBSD.org> <20100513211750.GA2015@garage.freebsd.pl> In-Reply-To: <20100513211750.GA2015@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 14 May 2010 07:53:22 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and __FreeBSD_version X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 11:53:24 -0000 Pawel Jakub Dawidek wrote: > On Thu, May 13, 2010 at 07:44:52AM -0400, John Baldwin wrote: >> Boris Kochergin wrote: >>> Hi. Can __FreeBSD_version be bumped if ZFS's userland API is ever >>> changed again? I got slightly bitten by the >>> state_to_name()-to-zpool_state_to_name() change from version 6 to >>> version 13 and would like a reliable way of keeping track of this type >>> of stuff in the future. Thanks. >> Yes, it should be bumped anytime the API changes. That is definitely a >> bug that it wasn't done properly last time. > > I must disagree here. libzfs API is for ZFS internal use only and is > subject to change at any time. This is true for OpenSolaris as well. > We, of course, can bump __FreeBSD_version if it helps, but one shouldn't > expect libzfs API being stable or there is any care taken to maintain > backward compatibility. Err, I did not say that the API should be stable, but if it is going to change we should bump __FreeBSD_version so that external software can cope via #ifdef's. Version bumps are cheap in stable branches. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Fri May 14 14:20:03 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0993E1065677 for ; Fri, 14 May 2010 14:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D3D238FC0C for ; Fri, 14 May 2010 14:20:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4EEK2Y7055130 for ; Fri, 14 May 2010 14:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4EEK27s055129; Fri, 14 May 2010 14:20:02 GMT (envelope-from gnats) Date: Fri, 14 May 2010 14:20:02 GMT Message-Id: <201005141420.o4EEK27s055129@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Volodymyr Kostyrko Cc: Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Volodymyr Kostyrko List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 14:20:03 -0000 The following reply was made to PR bin/144214; it has been noted by GNATS. From: Volodymyr Kostyrko To: Andriy Gapon Cc: bug-followup , Robert Noland Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 Date: Fri, 14 May 2010 17:12:23 +0300 2010/5/13 Andriy Gapon : > > It seems that I have been misunderstanding the problem. > "ZFS: gang block detected" won't even appear if boot code is too old. > > Having briefly glanced over the code and comparing it to the code in osol and in > zio_gang_tree_issue(), I think the following change is needed. > But I am not sure if it is a real fix for the issue at hand. > > If anyone can reproduce the problem, could you please test this change? > Thanks! Tested it. Same problem. 1. Rebuild and reinstall on i386. Filling disk up (600M free of 120G, 0.5%). 2. Immediately after starting boot screen bursts into psychic colors. Computer reboots. 3. Booted from ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201004/FreeBSD-8.0-STABLE-201004-i386-livefs.iso in VirtualBox i386. Boot code updated with dd. 4. Same as p2. in vBox i386 takes looong time to rotate dash then spits "ZFS: gang block detected" and hangs. 5. Booted from amd64 install, updated boot code with dd. 6. Booted on amd64. Immediately after starting boot spits out "ZFS: gang block detected" and hangs. 7. Booted from amd64 install. /boot transferred transferred to/from other disk. 8. Booted on amd64. Immediately after starting boot spits out "ZFS: gang block detected" and hangs. 9. Booted from amd64 install. Some files deleted (800M free, files were written contiguously). /boot transferred transferred to/from other disk. 10. Booted on amd64. Results: 1. Patch changes something. However zfsloader(?) still can't be read completely. 2. Bug can happen on amd64. More extreme conditions needed(?). 3. I'll post a follow-up on successfully booting on original i386 hardware. -- Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Fri May 14 16:06:27 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C05A3106564A for ; Fri, 14 May 2010 16:06:27 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 91B978FC1A for ; Fri, 14 May 2010 16:06:27 +0000 (UTC) Received: by pxi20 with SMTP id 20so1613347pxi.13 for ; Fri, 14 May 2010 09:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=R66uL7Z6KZ7FsUwGcmq0SEOqOVRvmT1+T8cePN/eZ30=; b=FWzRSvXLwqbNGYUF49CLLzpXldnswxr2vzEj4s4ZFpj7XNRgjgDRzOcOCGuqgcW39b pkuL8gw2Vh0IyMwJaRSK//pe8V98K+0FVYlHSb3GxnaAfCg1Rg64JDdTXx8ggyOrCnEs 95O5YSbj6uBj+SIJk590Sq/Uzvz3luAw6BeiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=WbAEcg2yJo2Im9vAVJZgO387SqeK1jkbvmHIDBYd6se/76/R3CF8w3vwdGx548ADqj mEwL34g+CTjlamGphOYSEk2JHIup8DlgPSwh6wgr/b9LDmQstb0hDiuB+WLG+2Zl2JEr mYgI6jRin1C+Fh28N8xEB63dVTSRegriW+EVU= MIME-Version: 1.0 Received: by 10.141.188.41 with SMTP id q41mr894637rvp.203.1273853186702; Fri, 14 May 2010 09:06:26 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.141.40.4 with HTTP; Fri, 14 May 2010 09:06:26 -0700 (PDT) In-Reply-To: <4BED0810.10508@zk.informjust.ua> References: <4BE95F1F.5090009@zk.informjust.ua> <20100511223813.GB3044@garage.freebsd.pl> <4BED0810.10508@zk.informjust.ua> Date: Fri, 14 May 2010 09:06:26 -0700 X-Google-Sender-Auth: 1cpHEQw664szJVBemy-m0C5n6Rs Message-ID: From: Artem Belevich To: "Alexander V. Ribchansky" Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 16:06:27 -0000 To think of it, UMA on i386 is not such a good idea until we fix ARC backpressure mechanism. Right now it's rather primitive and is pretty much controlled by arc_min. With UMA, it would appear to ZFS that we're constantly short on memory. If you're up for another experiment, try raising arc_min to the point where performance does not degrade much but not that high that it would cause map too small panic. --Artem 2010/5/14 Alexander V. Ribchansky : > 12.05.2010 01:38, Pawel Jakub Dawidek =D0=C9=DB=C5=D4: >> >> -skip- >> Could you try the following patch without disabling UMA? >> >> http://people.freebsd.org/~pjd/patches/vfs_subr.c.7.patch >> >> It works quite well for me. >> >> Also we still don't have back-pressure mechanism when arc_meta_limit is >> exceeded. OpenSolaris frees namecache entires then and we currently do >> nothing. I'll experiment with a bit and let you know if the patch above >> doesn't fix your problem still. >> > OOps, I do it again! ;) > So after several hard days my STABLE gone away again. With your patch and > UMA enabled. Wired constantly grow, last time I see it, it was about 940M > As Wired grom, perfomance become terrible, buildworld take about 4 hours = on > Core2quadro.. So my wery IMHO (please don't kill me for it) that UMA > allocation on i386 is unusable, correct me if I'm wrong. > > -- > =9A =9AAVR39-RIPE > _______________________________________________ > 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" > From owner-freebsd-fs@FreeBSD.ORG Fri May 14 18:20:08 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1678106566C for ; Fri, 14 May 2010 18:20:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 90C4C8FC19 for ; Fri, 14 May 2010 18:20:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4EIK8eq060777 for ; Fri, 14 May 2010 18:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4EIK8dm060776; Fri, 14 May 2010 18:20:08 GMT (envelope-from gnats) Date: Fri, 14 May 2010 18:20:08 GMT Message-Id: <201005141820.o4EIK8dm060776@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 18:20:08 -0000 The following reply was made to PR bin/144214; it has been noted by GNATS. From: Andriy Gapon To: Volodymyr Kostyrko Cc: bug-followup , Robert Noland Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 Date: Fri, 14 May 2010 21:15:31 +0300 on 14/05/2010 17:12 Volodymyr Kostyrko said the following: > 2010/5/13 Andriy Gapon : >> It seems that I have been misunderstanding the problem. >> "ZFS: gang block detected" won't even appear if boot code is too old. >> >> Having briefly glanced over the code and comparing it to the code in osol and in >> zio_gang_tree_issue(), I think the following change is needed. >> But I am not sure if it is a real fix for the issue at hand. >> >> If anyone can reproduce the problem, could you please test this change? >> Thanks! > > Tested it. Same problem. Sigh. I almost do not see any other obvious differences with other code that is supposed to support gang blocks. > 1. Rebuild and reinstall on i386. Filling disk up (600M free of 120G, 0.5%). > 2. Immediately after starting boot screen bursts into psychic colors. > Computer reboots. With unpatched boot code I presume? > 3. Booted from ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201004/FreeBSD-8.0-STABLE-201004-i386-livefs.iso > in VirtualBox i386. Boot code updated with dd. Have you updated both both part of zfsboot and loader? Are you sure that you used patched versions? (asking just in case) > 4. Same as p2. in vBox i386 takes looong time to rotate dash then > spits "ZFS: gang block detected" and hangs. Nothing else get printed? Asking because of this screenshot: http://danger.rulez.sk/dockdrop/144214.png > 5. Booted from amd64 install, updated boot code with dd. > 6. Booted on amd64. Immediately after starting boot spits out "ZFS: > gang block detected" and hangs. > 7. Booted from amd64 install. /boot transferred transferred to/from other disk. > 8. Booted on amd64. Immediately after starting boot spits out "ZFS: > gang block detected" and hangs. amd64 has exactly the same boot code that i386 has, perhaps some difference could arise during compilation, but even if so, it should not matter much in our case. > 9. Booted from amd64 install. Some files deleted (800M free, files > were written contiguously). /boot transferred transferred to/from > other disk. > 10. Booted on amd64. Not interested much in the workarounds - if they work, then OK, but mainly we are trying to fix the boot code. Only behavior of installed zfsboot and zfsloader are interesting to us. > Results: > 1. Patch changes something. However zfsloader(?) still can't be read completely. > 2. Bug can happen on amd64. More extreme conditions needed(?). > 3. I'll post a follow-up on successfully booting on original i386 hardware. Can you please also share output of 'zfs get all' for the boot filesystem? Thank you for your help! And one last thing that I could think of: --- a/sys/boot/zfs/zfsimpl.c +++ b/sys/boot/zfs/zfsimpl.c @@ -1001,7 +1001,7 @@ zio_read(spa_t *spa, const blkptr_t *bp, void *buf) if (DVA_GET_GANG(dva)) { printf("ZFS: gang block detected!\n"); if (zio_read_gang(spa, bp, dva, buf)) - return (EIO); + continue; } else { vdevid = DVA_GET_VDEV(dva); offset = DVA_GET_OFFSET(dva); This should be applied in addition to the previous patch. If this still doesn't work, the it would make sense to add printfs in various places of zio_read_gang() function to try to see what happens there. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sat May 15 00:20:13 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BFB0106564A; Sat, 15 May 2010 00:20:12 +0000 (UTC) (envelope-from rpp@ci.com.au) Received: from mippet.ci.com.au (mippet.ci.com.au [192.65.182.30]) by mx1.freebsd.org (Postfix) with ESMTP id 290278FC15; Sat, 15 May 2010 00:20:12 +0000 (UTC) Received: from mippet.ci.com.au (localhost [127.0.0.1]) by mippet.ci.com.au (8.14.4/8.14.3/CE070809/cml) with ESMTP id o4F0K9FG076405; Sat, 15 May 2010 10:20:10 +1000 (EST) (envelope-from rpp@mippet.ci.com.au) Received: (from rpp@localhost) by mippet.ci.com.au (8.14.4/8.14.3/Submit) id o4F0K9no076404; Sat, 15 May 2010 10:20:09 +1000 (EST) (envelope-from rpp) Date: Sat, 15 May 2010 10:20:09 +1000 From: Richard Perini To: Pawel Jakub Dawidek Message-ID: <20100515002009.GA71506@mippet.ci.com.au> References: <4BE95F1F.5090009@zk.informjust.ua> <20100511223813.GB3044@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100511223813.GB3044@garage.freebsd.pl> X-Scanned-By: MIMEDefang 2.67 on 192.65.182.30 Cc: freebsd-fs@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 00:20:13 -0000 On Wed, May 12, 2010 at 12:38:13AM +0200, Pawel Jakub Dawidek wrote: > On Tue, May 11, 2010 at 04:43:59PM +0300, Alexander V. Ribchansky wrote: > > As Artem advised, I comment out > > > > CFLAGS+=-DZIO_USE_UMA in sys/modules/zfs/Makefile > > > > and things like to be "back in USSR :)" if seriously - all become as good > > as before 18.04.2010 mega ZFS-MFC. Confirming that my stability problem reported a few days ago has also been solved by removing the above line. (i386). Regards -- Richard Perini Internet: rpp@ci.com.au Corinthian Engineering Pty Ltd PHONE: +61 2 9552 5500 Sydney, Australia FAX: +61 2 9552 5549 From owner-freebsd-fs@FreeBSD.ORG Sat May 15 02:11:09 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42CE4106564A; Sat, 15 May 2010 02:11:09 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D97218FC08; Sat, 15 May 2010 02:11:08 +0000 (UTC) Received: by pwi9 with SMTP id 9so1891189pwi.13 for ; Fri, 14 May 2010 19:11:08 -0700 (PDT) Received: by 10.141.23.15 with SMTP id a15mr1308236rvj.278.1273889468354; Fri, 14 May 2010 19:11:08 -0700 (PDT) Received: from [10.0.1.198] (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id b2sm1713335rvn.19.2010.05.14.19.11.06 (version=SSLv3 cipher=RC4-MD5); Fri, 14 May 2010 19:11:07 -0700 (PDT) Date: Fri, 14 May 2010 16:11:04 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Mikolaj Golub In-Reply-To: <86r5lr5qfi.fsf@kopusha.onet> Message-ID: References: <86bpcwluev.fsf@kopusha.onet> <86r5lr5qfi.fsf@kopusha.onet> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org, Jeff Roberson Subject: Re: SUJ: fsck_ufs: Sparse journal inode X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 02:11:09 -0000 On Wed, 5 May 2010, Mikolaj Golub wrote: > On Mon, 03 May 2010 21:19:52 +0300 Mikolaj Golub wrote: > >> Hi, >> >> Experimenting with journaled soft-updates on HAST I observed the error when >> fscking fs on the secondary after primary "crash": >> >> # fsck -y -t ufs /dev/hast/tank >> ** /dev/hast/tank >> >> USE JOURNAL?? yes >> >> ** SU+J Recovering /dev/hast/tank >> ** Reading 33554384 byte journal from inode 4. >> fsck_ufs: Sparse journal inode 4 (blocks = 16376, numfrags = 16383). >> >> (The text between the parentheses is a local modification to the fsck code to >> output some useful values). >> >> So to recover I needed to run fsck and type "no" when prompted "USE >> JOURNAL?". But I am looking for a way to script automatic recovering from this >> situation. Currently the only way I have found is to disable journal, run >> fsck, mount fs somewhere temporary, remove .sujournal, unmount, enable >> journal. Is this really so complicated or may I just miss something? I will add an option to skip the journal. >> >> BTW, I used to observe this error on every "crash" test. And "blocks" value was >> always the same: 16376. So I changed journal size to 16376 * 2048 = 33538048. >> It looks like after this the issue has gone. > > Actually, this is tunefs who creates a sparse journal :-) > > When creating a journal tunefs allocates size/fs_bsize blocks > (journal_alloc(size)). But if the journal size is not multiple of fs_bsize a > block for tail fragments is not allocated and we have sparse file. You are absolutely right. This only happens on filesystems smaller than 16GB when we hit the max journal size. I will resolve it immediately. Thanks, Jeff > > Steps to reproduce: > > Choose a journal size: (blocksize * N) + fragsize + something. E.g. 4198400 > (2048*2048 + 2*2048). > > [root@hasta ~]# newfs /dev/$dev > /dev/md0: 10.0MB (20480 sectors) block size 16384, fragment size 2048 > using 4 cylinder groups of 2.52MB, 161 blks, 384 inodes. > super-block backups (for fsck -b #) at: > 160, 5312, 10464, 15616 > [root@hasta ~]# tunefs -j enable -S 4198400 /dev/$dev > Using inode 4 in cg 0 for 4198400 byte journal > tunefs: soft updates journaling set > [root@hasta ~]# fsck -f -t ufs /dev/$dev > ** /dev/md0 > > USE JOURNAL?? [yn] y > > ** SU+J Recovering /dev/md0 > ** Reading 4198400 byte journal from inode 4. > fsck_ufs: Sparse journal inode 4. > > Note, the size should be so that tail has at least one full fragment, because > in the code we have: > > blocks = ino_visit(jip, sujino, suj_add_block, 0); > if (blocks != numfrags(fs, DIP(jip, di_size))) > errx(1, "Sparse journal inode %d.\n", sujino); > > with only one non-full fragment numfrags() will return the value equal to > blocks. > > BTW, I am not sure this check would be correct even if tunefs allocated tail > fragments. As I see in indir_visit() for every found block it adds: > > (*frags) += fs->fs_frag; > > so the same would be for the tail block, and ino_visit() in the code above > would return more then numfrags(). > > -- > Mikolaj Golub > _______________________________________________ > 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" > From owner-freebsd-fs@FreeBSD.ORG Sat May 15 15:15:46 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E3B3106566C; Sat, 15 May 2010 15:15:46 +0000 (UTC) (envelope-from jilles@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 468928FC08; Sat, 15 May 2010 15:15:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4FFFkuT076655; Sat, 15 May 2010 15:15:46 GMT (envelope-from jilles@freefall.freebsd.org) Received: (from jilles@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4FFFk2L076651; Sat, 15 May 2010 15:15:46 GMT (envelope-from jilles) Date: Sat, 15 May 2010 15:15:46 GMT Message-Id: <201005151515.o4FFFk2L076651@freefall.freebsd.org> To: jilles@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: jilles@FreeBSD.org Cc: Subject: Re: kern/146502: [nfs] FreeBSD 8 NFS Client Connection to Server X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 15:15:46 -0000 Old Synopsis: FreeBSD 8 NFS Client Connection to Server New Synopsis: [nfs] FreeBSD 8 NFS Client Connection to Server Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: jilles Responsible-Changed-When: Sat May 15 15:15:03 UTC 2010 Responsible-Changed-Why: Correct category. http://www.freebsd.org/cgi/query-pr.cgi?pr=146502 From owner-freebsd-fs@FreeBSD.ORG Sat May 15 17:50:01 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 251DB106567A for ; Sat, 15 May 2010 17:50:01 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from web.nitronet.pl (web.nitronet.pl [195.90.106.5]) by mx1.freebsd.org (Postfix) with ESMTP id 2E1308FC13 for ; Sat, 15 May 2010 17:49:59 +0000 (UTC) Received: from mailnull by web.nitronet.pl with virscan (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ODLBw-0003aO-PY for freebsd-fs@freebsd.org; Sat, 15 May 2010 19:30:24 +0200 Date: Sat, 15 May 2010 19:30:24 +0200 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <598841171.20100515193024@nitronet.pl> To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on web.nitronet.pl); SAEximRunCond expanded to false Subject: Root mount from ZFS takes forever...literally. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 17:50:01 -0000 Hi list, Has this happened to anyone? Boot process "hangs" on Trying to mount root from zfs:tank/root - I can import the pool from alternate boot source (PXE), and access files fine, but I can't finish booting the system from ZFS. It's a recent 8-STABLE, it happened after upgrading from older 8-STABLE, but reverting to older kernel and modules doesn't solve this, so maybe it's unrelated. Cheers. From owner-freebsd-fs@FreeBSD.ORG Sat May 15 23:35:10 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B64C106564A for ; Sat, 15 May 2010 23:35:10 +0000 (UTC) (envelope-from SamanKaya@netscape.net) Received: from imr-ma06.mx.aol.com (imr-ma06.mx.aol.com [64.12.78.142]) by mx1.freebsd.org (Postfix) with ESMTP id D4CE48FC13 for ; Sat, 15 May 2010 23:35:09 +0000 (UTC) Received: from mtaout-mb03.r1000.mx.aol.com (mtaout-mb03.r1000.mx.aol.com [172.29.41.67]) by imr-ma06.mx.aol.com (8.14.1/8.14.1) with ESMTP id o4FNYuLN020125 for ; Sat, 15 May 2010 19:34:56 -0400 Received: from [172.16.0.66] (unknown [212.156.209.87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 775ABE000095 for ; Sat, 15 May 2010 19:34:56 -0400 (EDT) Message-ID: <4BEF2F9C.7080409@netscape.net> Date: Sun, 16 May 2010 02:34:52 +0300 From: Kaya Saman User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:394215616:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29434bef2fa01a8b X-AOL-IP: 212.156.209.87 Subject: Quick ZFS mirroring question for non-mirrored pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 23:35:10 -0000 Hi, I'm just exploring ZFS commands currently as I haven't used much of ZFS even though I deal with BSD and Solaris/OpenSolaris on a daily basis..... Basically what I am about to do is build a new server using FreeBSD 8.0 x64 on a Mini-ITX system and unfortunately due to budget I won't be able to get the extra 2 disks that I need so out of 4 disks overall is 2. I just really wanted to ask after using these tutorials: http://wiki.freebsd.org/ZFSQuickStartGuide http://blog.thefrog.net/2008/04/zfs-on-freebsd.html http://flux.org.uk/howto/solaris/zfs_tutorial_01 if it's possible to add a mirror to a non-mirrored pool?? It's a bit hard to explain but taken from the last URL: I created 4 files using mkfile in /mnt called file1...4 Now I added the first 2 to a pool: zpool create zpool1 /mnt/disk1 /mnt/disk2 and checked the status: zpool status zpool1 pool: zpool1 state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM zpool1 ONLINE 0 0 0 /mnt/disk1 ONLINE 0 0 0 /mnt/disk2 ONLINE 0 0 0 errors: No known data errors What I would like to do over time is add 2 more disks to this pool (in real life, however for my demo they will be /mnt/disk3 and /mnt/disk4). The real catch is that I would like disks 3 + 4 to be a mirror of the first 2 disks..... Is this possible to start with without loosing any data and destroying the pool? Or do I need to create another pool say zpool2 and mirror the pools?? So in RAID terms I guess would be something like disk1 and 2 in RAID 0 with disks 3 + 4 in RAID 0 however, RAID0(1) in RAID 1 array with RAID0(2)..... Perhaps is RAID 1+ 0 which I'm trying to achieve I don't know but currently I'm not really getting anywhere with what I've tried and managed to crash the kernel and make the system reboot already. From scratch it would be so easy as I could just use: zpool create zpool1 mirror /mnt/disk1 /mnt/disk2 mirror /mnt/disk3 /mnt/disk4. Can anyone give me any advice?? Many thanks, Kaya From owner-freebsd-fs@FreeBSD.ORG Sat May 15 23:41:53 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F14481065673 for ; Sat, 15 May 2010 23:41:52 +0000 (UTC) (envelope-from SamanKaya@netscape.net) Received: from imr-da06.mx.aol.com (imr-da06.mx.aol.com [205.188.169.203]) by mx1.freebsd.org (Postfix) with ESMTP id B4C808FC14 for ; Sat, 15 May 2010 23:41:52 +0000 (UTC) Received: from mtaout-da02.r1000.mx.aol.com (mtaout-da02.r1000.mx.aol.com [172.29.51.130]) by imr-da06.mx.aol.com (8.14.1/8.14.1) with ESMTP id o4FNflcP025244 for ; Sat, 15 May 2010 19:41:47 -0400 Received: from [172.16.0.66] (unknown [212.156.209.87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id EA2C7E000121 for ; Sat, 15 May 2010 19:41:46 -0400 (EDT) Message-ID: <4BEF3137.4080203@netscape.net> Date: Sun, 16 May 2010 02:41:43 +0300 From: Kaya Saman User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4BEF2F9C.7080409@netscape.net> In-Reply-To: <4BEF2F9C.7080409@netscape.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:465608704:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33824bef313a05ff X-AOL-IP: 212.156.209.87 Subject: Re: Quick ZFS mirroring question for non-mirrored pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 23:41:53 -0000 Ok I think I've got what I want by using the 'attach' command: from here: http://prefetch.net/blog/index.php/2007/01/04/adding-a-mirror-to-a-device-in-a-zfs-pool/ rd1# zpool attach zpool1 /mnt/disk1 /mnt/disk3 rd1# zpool attach zpool1 /mnt/disk2 /mnt/disk4 rd1# zpool status zpool1 pool: zpool1 state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Sun May 16 02:36:58 2010 config: NAME STATE READ WRITE CKSUM zpool1 ONLINE 0 0 0 mirror ONLINE 0 0 0 /mnt/disk1 ONLINE 0 0 0 /mnt/disk3 ONLINE 0 0 0 mirror ONLINE 0 0 0 /mnt/disk2 ONLINE 0 0 0 96.5K resilvered /mnt/disk4 ONLINE 0 0 0 15.3M resilvered errors: No known data errors which seems to be ok as data is still there post attachement: rd1# ls /zpool1 file.test and also space is ok being ~256MB: rd1# zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT zpool1 246M 32.2M 214M 13% ONLINE - although not sure where 10MB went as all files in this pool are 128MB so I should get 256MB no?? On 05/16/2010 02:34 AM, Kaya Saman wrote: > Hi, > > I'm just exploring ZFS commands currently as I haven't used much of > ZFS even though I deal with BSD and Solaris/OpenSolaris on a daily > basis..... > > Basically what I am about to do is build a new server using FreeBSD > 8.0 x64 on a Mini-ITX system and unfortunately due to budget I won't > be able to get the extra 2 disks that I need so out of 4 disks overall > is 2. > > I just really wanted to ask after using these tutorials: > > http://wiki.freebsd.org/ZFSQuickStartGuide > > http://blog.thefrog.net/2008/04/zfs-on-freebsd.html > > http://flux.org.uk/howto/solaris/zfs_tutorial_01 > > if it's possible to add a mirror to a non-mirrored pool?? > > It's a bit hard to explain but taken from the last URL: > > I created 4 files using mkfile in /mnt called file1...4 > > Now I added the first 2 to a pool: zpool create zpool1 /mnt/disk1 > /mnt/disk2 > > and checked the status: > > zpool status zpool1 > pool: zpool1 > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > zpool1 ONLINE 0 0 0 > /mnt/disk1 ONLINE 0 0 0 > /mnt/disk2 ONLINE 0 0 0 > > errors: No known data errors > > > What I would like to do over time is add 2 more disks to this pool (in > real life, however for my demo they will be /mnt/disk3 and > /mnt/disk4). The real catch is that I would like disks 3 + 4 to be a > mirror of the first 2 disks..... > > Is this possible to start with without loosing any data and destroying > the pool? > > Or do I need to create another pool say zpool2 and mirror the pools?? > > So in RAID terms I guess would be something like disk1 and 2 in RAID 0 > with disks 3 + 4 in RAID 0 however, RAID0(1) in RAID 1 array with > RAID0(2)..... > > Perhaps is RAID 1+ 0 which I'm trying to achieve I don't know but > currently I'm not really getting anywhere with what I've tried and > managed to crash the kernel and make the system reboot already. > > From scratch it would be so easy as I could just use: zpool create > zpool1 mirror /mnt/disk1 /mnt/disk2 mirror /mnt/disk3 /mnt/disk4. > > Can anyone give me any advice?? > > Many thanks, > > Kaya > > _______________________________________________ > 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" From owner-freebsd-fs@FreeBSD.ORG Sat May 15 23:44:25 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63A3C1065672 for ; Sat, 15 May 2010 23:44:25 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1D38FC17 for ; Sat, 15 May 2010 23:44:24 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.13.8+Sun/8.13.8) with ESMTP id o4FNiO6L019624; Sat, 15 May 2010 18:44:24 -0500 (CDT) Date: Sat, 15 May 2010 18:44:24 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Kaya Saman In-Reply-To: <4BEF2F9C.7080409@netscape.net> Message-ID: References: <4BEF2F9C.7080409@netscape.net> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Sat, 15 May 2010 18:44:24 -0500 (CDT) Cc: freebsd-fs@freebsd.org Subject: Re: Quick ZFS mirroring question for non-mirrored pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 23:44:25 -0000 On Sun, 16 May 2010, Kaya Saman wrote: > > if it's possible to add a mirror to a non-mirrored pool?? Yes. In a simple load-shared pool, individual disk vdevs on the pool can easily be turned into mirror vdevs. Later you can convert back to simplex if you like. This means that you can create the simple load-shared pool and add redundancy later. I have done this before. Just make sure to read the documentation so that you add the mirror disk correctly. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Sat May 15 23:58:07 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E86B1065674 for ; Sat, 15 May 2010 23:58:07 +0000 (UTC) (envelope-from SamanKaya@netscape.net) Received: from imr-da06.mx.aol.com (imr-da06.mx.aol.com [205.188.169.203]) by mx1.freebsd.org (Postfix) with ESMTP id D54088FC21 for ; Sat, 15 May 2010 23:58:06 +0000 (UTC) Received: from mtaout-ma01.r1000.mx.aol.com (mtaout-ma01.r1000.mx.aol.com [172.29.41.1]) by imr-da06.mx.aol.com (8.14.1/8.14.1) with ESMTP id o4FNw1YH009781 for ; Sat, 15 May 2010 19:58:01 -0400 Received: from [172.16.0.66] (unknown [212.156.209.87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma01.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id BEA74E0000B4 for ; Sat, 15 May 2010 19:58:00 -0400 (EDT) Message-ID: <4BEF3506.1000109@netscape.net> Date: Sun, 16 May 2010 02:57:58 +0300 From: Kaya Saman User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4BEF2F9C.7080409@netscape.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:452495616:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29014bef350805e0 X-AOL-IP: 212.156.209.87 Subject: Re: Quick ZFS mirroring question for non-mirrored pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 23:58:07 -0000 Many thanks for the response! :-) I'm quite sure that this is going to be more stable and less error-prone then any other file system.... Although currently I find the UFS v1 and v2 file systems the best outside of ZFS which is by default enabled on OpenSolaris. Yeah.... this should be cool! On 05/16/2010 02:44 AM, Bob Friesenhahn wrote: > On Sun, 16 May 2010, Kaya Saman wrote: >> >> if it's possible to add a mirror to a non-mirrored pool?? > > Yes. In a simple load-shared pool, individual disk vdevs on the pool > can easily be turned into mirror vdevs. Later you can convert back to > simplex if you like. This means that you can create the simple > load-shared pool and add redundancy later. I have done this before. > > Just make sure to read the documentation so that you add the mirror > disk correctly. > > Bob