From owner-freebsd-fs@FreeBSD.ORG Sun Apr 8 01:56:10 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 6C83D16A481; Sun, 8 Apr 2007 01:56:10 +0000 (UTC) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (www.creo.hu [217.113.62.14]) by mx1.freebsd.org (Postfix) with ESMTP id C006313C4BE; Sun, 8 Apr 2007 01:56:09 +0000 (UTC) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (localhost [127.0.0.1]) by beastie.creo.hu (8.13.4/8.13.4) with ESMTP id l381gZY2096875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Apr 2007 03:42:35 +0200 (CEST) (envelope-from csaba@beastie.creo.hu) Received: (from csaba@localhost) by beastie.creo.hu (8.13.4/8.13.4/Submit) id l381gYb1096874; Sun, 8 Apr 2007 03:42:34 +0200 (CEST) (envelope-from csaba) Date: Sun, 8 Apr 2007 03:42:34 +0200 From: Csaba Henk To: "Marc G. Fournier" Message-ID: <20070408014234.GP79199@beastie.creo.hu> References: <4746DA006C148BC0FF1241C6@ganymede.hub.org> <45CCECCB7ECB612F504211F3@ganymede.hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (beastie.creo.hu [127.0.0.1]); Sun, 08 Apr 2007 03:42:35 +0200 (CEST) Cc: Csaba Henk , freebsd-fs@freebsd.org Subject: Re: TDFS ... or other distributed file system technologies for FreeBSD? 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, 08 Apr 2007 01:56:10 -0000 On Fri, Apr 06, 2007 at 01:21:25PM -0300, Marc G. Fournier wrote: > - --On Thursday, March 29, 2007 13:49:43 +0000 Csaba Henk > wrote: > > > So, whom to pester about getting fuse4bsd merged?... > > My question ... if this was added to the core system (or, rather, the > BSD/kernel module), if it something that you are willing/able to support if > there are any problems and/or ensure that bit rot doesn't set in? > > Basically, if it gets added, will it just have to be removed within a release > or two because it doesn't build/work anymore? :( I didn't mean I won't maintain (keep code in sync with the rest of the kernel, fix bugs, etc.). I just said I can't work on new features ATM. Csaba From owner-freebsd-fs@FreeBSD.ORG Sun Apr 8 06:03:13 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 9F59016A401; Sun, 8 Apr 2007 06:03:13 +0000 (UTC) (envelope-from freebsd.ruomad@free.fr) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.freebsd.org (Postfix) with ESMTP id 4166313C43E; Sun, 8 Apr 2007 06:03:13 +0000 (UTC) (envelope-from freebsd.ruomad@free.fr) Received: from [192.168.0.100] (vln78-1-82-238-160-33.fbx.proxad.net [82.238.160.33]) by smtp2-g19.free.fr (Postfix) with ESMTP id 160E48C510; Sun, 8 Apr 2007 08:03:11 +0200 (CEST) Message-ID: <4618859F.3010603@free.fr> Date: Sun, 08 Apr 2007 08:03:11 +0200 From: Bruno Damour User-Agent: Thunderbird 1.5.0.10 (X11/20070309) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> In-Reply-To: <20070406025700.GB98545@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. 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, 08 Apr 2007 06:03:13 -0000 hello, After csup, buildworld fails for me in libumem. Is this due to zfs import ? Or my config ? Thanks for any clue, i'm dying to try your brand new zfs on amd64 !! Bruno FreeBSD vil1.ruomad.net 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Fri Mar 23 07:33:56 CET 2007 root@vil1.ruomad.net:/usr/obj/usr/src/sys/VIL1 amd64 make buildworld: ===> cddl/lib/libumem (all) cc -O2 -fno-strict-aliasing -pipe -march=nocona -I/usr/src/cddl/lib/libumem/../../../compat/opensolaris/lib/libumem -D_SOLARIS_C_SOURCE -c /usr/src/cddl/lib/libumem/umem.c /usr/src/cddl/lib/libumem/umem.c:197: error: redefinition of 'nofail_cb' /usr/src/cddl/lib/libumem/umem.c:30: error: previous definition of 'nofail_cb' was here /usr/src/cddl/lib/libumem/umem.c:199: error: redefinition of `struct umem_cache' /usr/src/cddl/lib/libumem/umem.c:210: error: redefinition of 'umem_alloc' /usr/src/cddl/lib/libumem/umem.c:43: error: previous definition of 'umem_alloc' was here /usr/src/cddl/lib/libumem/umem.c:233: error: redefinition of 'umem_zalloc' /usr/src/cddl/lib/libumem/umem.c:66: error: previous definition of 'umem_zalloc' was here /usr/src/cddl/lib/libumem/umem.c:256: error: redefinition of 'umem_free' /usr/src/cddl/lib/libumem/umem.c:89: error: previous definition of 'umem_free' was here /usr/src/cddl/lib/libumem/umem.c:264: error: redefinition of 'umem_nofail_callback' /usr/src/cddl/lib/libumem/umem.c:97: error: previous definition of 'umem_nofail_callback' was here /usr/src/cddl/lib/libumem/umem.c:272: error: redefinition of 'umem_cache_create' /usr/src/cddl/lib/libumem/umem.c:105: error: previous definition of 'umem_cache_create' was here /usr/src/cddl/lib/libumem/umem.c:291: error: redefinition of 'umem_cache_alloc' /usr/src/cddl/lib/libumem/umem.c:124: error: previous definition of 'umem_cache_alloc' was here /usr/src/cddl/lib/libumem/umem.c:321: error: redefinition of 'umem_cache_free' /usr/src/cddl/lib/libumem/umem.c:154: error: previous definition of 'umem_cache_free' was here /usr/src/cddl/lib/libumem/umem.c:332: error: redefinition of 'umem_cache_destroy' /usr/src/cddl/lib/libumem/umem.c:165: error: previous definition of 'umem_cache_destroy' was here /usr/src/cddl/lib/libumem/umem.c:364: error: redefinition of 'nofail_cb' /usr/src/cddl/lib/libumem/umem.c:197: error: previous definition of 'nofail_cb' was here /usr/src/cddl/lib/libumem/umem.c:364: error: redefinition of 'nofail_cb' /usr/src/cddl/lib/libumem/umem.c:197: error: previous definition of 'nofail_cb' was here /usr/src/cddl/lib/libumem/umem.c:366: error: redefinition of `struct umem_cache' /usr/src/cddl/lib/libumem/umem.c:377: error: redefinition of 'umem_alloc' /usr/src/cddl/lib/libumem/umem.c:210: error: previous definition of 'umem_alloc' was here /usr/src/cddl/lib/libumem/umem.c:377: error: redefinition of 'umem_alloc' /usr/src/cddl/lib/libumem/umem.c:210: error: previous definition of 'umem_alloc' was here /usr/src/cddl/lib/libumem/umem.c:400: error: redefinition of 'umem_zalloc' /usr/src/cddl/lib/libumem/umem.c:233: error: previous definition of 'umem_zalloc' was here /usr/src/cddl/lib/libumem/umem.c:400: error: redefinition of 'umem_zalloc' /usr/src/cddl/lib/libumem/umem.c:233: error: previous definition of 'umem_zalloc' was here /usr/src/cddl/lib/libumem/umem.c:423: error: redefinition of 'umem_free' /usr/src/cddl/lib/libumem/umem.c:256: error: previous definition of 'umem_free' was here /usr/src/cddl/lib/libumem/umem.c:423: error: redefinition of 'umem_free' /usr/src/cddl/lib/libumem/umem.c:256: error: previous definition of 'umem_free' was here /usr/src/cddl/lib/libumem/umem.c:431: error: redefinition of 'umem_nofail_callback' /usr/src/cddl/lib/libumem/umem.c:264: error: previous definition of 'umem_nofail_callback' was here /usr/src/cddl/lib/libumem/umem.c:431: error: redefinition of 'umem_nofail_callback' /usr/src/cddl/lib/libumem/umem.c:264: error: previous definition of 'umem_nofail_callback' was here /usr/src/cddl/lib/libumem/umem.c:439: error: redefinition of 'umem_cache_create' /usr/src/cddl/lib/libumem/umem.c:272: error: previous definition of 'umem_cache_create' was here /usr/src/cddl/lib/libumem/umem.c:439: error: redefinition of 'umem_cache_create' /usr/src/cddl/lib/libumem/umem.c:272: error: previous definition of 'umem_cache_create' was here /usr/src/cddl/lib/libumem/umem.c:458: error: redefinition of 'umem_cache_alloc' /usr/src/cddl/lib/libumem/umem.c:291: error: previous definition of 'umem_cache_alloc' was here /usr/src/cddl/lib/libumem/umem.c:458: error: redefinition of 'umem_cache_alloc' /usr/src/cddl/lib/libumem/umem.c:291: error: previous definition of 'umem_cache_alloc' was here /usr/src/cddl/lib/libumem/umem.c:488: error: redefinition of 'umem_cache_free' /usr/src/cddl/lib/libumem/umem.c:321: error: previous definition of 'umem_cache_free' was here /usr/src/cddl/lib/libumem/umem.c:488: error: redefinition of 'umem_cache_free' /usr/src/cddl/lib/libumem/umem.c:321: error: previous definition of 'umem_cache_free' was here /usr/src/cddl/lib/libumem/umem.c:499: error: redefinition of 'umem_cache_destroy' /usr/src/cddl/lib/libumem/umem.c:332: error: previous definition of 'umem_cache_destroy' was here /usr/src/cddl/lib/libumem/umem.c:499: error: redefinition of 'umem_cache_destroy' /usr/src/cddl/lib/libumem/umem.c:332: error: previous definition of 'umem_cache_destroy' was here *** Error code 1 Stop in /usr/src/cddl/lib/libumem. *** Error code 1 Stop in /usr/src/cddl/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From owner-freebsd-fs@FreeBSD.ORG Sun Apr 8 09:50:00 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 8A6D616A401; Sun, 8 Apr 2007 09:50:00 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id EE2A213C465; Sun, 8 Apr 2007 09:49:59 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 77FC6487F0; Sun, 8 Apr 2007 11:49:57 +0200 (CEST) Received: from localhost (cvl74.internetdsl.tpnet.pl [83.19.93.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 90E7045684; Sun, 8 Apr 2007 11:49:46 +0200 (CEST) Date: Sun, 8 Apr 2007 11:49:31 +0200 From: Pawel Jakub Dawidek To: Bruno Damour Message-ID: <20070408094931.GW63916@garage.freebsd.pl> References: <20070406025700.GB98545@garage.freebsd.pl> <4618859F.3010603@free.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l4GQ7sizse6iPvDe" Content-Disposition: inline In-Reply-To: <4618859F.3010603@free.fr> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. 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, 08 Apr 2007 09:50:00 -0000 --l4GQ7sizse6iPvDe Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 08, 2007 at 08:03:11AM +0200, Bruno Damour wrote: > hello, >=20 > After csup, buildworld fails for me in libumem. > Is this due to zfs import ? > Or my config ? >=20 > Thanks for any clue, i'm dying to try your brand new zfs on amd64 !! >=20 > Bruno >=20 > FreeBSD vil1.ruomad.net 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Fri Mar 23 07= :33:56 CET 2007 root@vil1.ruomad.net:/usr/obj/usr/src/sys/VIL1 amd64 >=20 > make buildworld: >=20 > =3D=3D=3D> cddl/lib/libumem (all) > cc -O2 -fno-strict-aliasing -pipe -march=3Dnocona -I/usr/src/cddl/lib/lib= umem/../../../compat/opensolaris/lib/libumem -D_SOLARIS_C_SOURCE -c /usr/s= rc/cddl/lib/libumem/umem.c > /usr/src/cddl/lib/libumem/umem.c:197: error: redefinition of 'nofail_cb' > /usr/src/cddl/lib/libumem/umem.c:30: error: previous definition of 'nofai= l_cb' was here > /usr/src/cddl/lib/libumem/umem.c:199: error: redefinition of `struct umem= _cache' > /usr/src/cddl/lib/libumem/umem.c:210: error: redefinition of 'umem_alloc' > /usr/src/cddl/lib/libumem/umem.c:43: error: previous definition of 'umem_= alloc' was here Did you use my previous patches? There is no cddl/lib/libumem/umem.c is HEAD, it was it's old location and it was moved to compat/opensolaris/lib/libumem/. Delete your entire cddl/ directory and recsup. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --l4GQ7sizse6iPvDe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGGLqrForvXbEpPzQRAv0kAKDYfwC82IofFAzHSfrMoAtyE9noNQCg2/aZ nFmUmfK6E6Iymm/Xff9wEDA= =p6Qv -----END PGP SIGNATURE----- --l4GQ7sizse6iPvDe-- From owner-freebsd-fs@FreeBSD.ORG Sun Apr 8 17:23:08 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 8FBEF16A402 for ; Sun, 8 Apr 2007 17:23:08 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id E85D913C480 for ; Sun, 8 Apr 2007 17:23:07 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.29.9] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1HaauK1eIz-00046y; Sun, 08 Apr 2007 19:10:29 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Sun, 8 Apr 2007 19:10:36 +0200 User-Agent: KMail/1.9.5 References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> In-Reply-To: <86k5wo55s0.fsf@dwp.des.no> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5655571.IUblBEjXgS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704081910.42852.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19tLKjhAPo4pwjrhrYjuRgFK6YKV6Cz6i3G3db YvBryZfw2xTgJ0Ntw5BUpOi/5AnH0iNuuVKA5UqgEFp8dBmjTq 1EshXptj9X0uOPxak+5nQ== Cc: freebsd-fs@freebsd.org, Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. 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, 08 Apr 2007 17:23:08 -0000 --nextPart5655571.IUblBEjXgS Content-Type: multipart/mixed; boundary="Boundary-01=_NISGGyaMHdg/POM" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_NISGGyaMHdg/POM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 07 April 2007 21:43, Dag-Erling Sm=F8rgrav wrote: > Pawel Jakub Dawidek writes: > > Limitations. > > > > Currently ZFS is only compiled as kernel module and is only > > available for i386 architecture. Amd64 should be available very soon, > > the other archs will come later, as we implement needed atomic > > operations. > > ZFS is now also available on pc98 and amd64. panic: lock "zfs:&zap->zap_f.zap_num_entries_mtx" 0xffffff006582c260=20 already initialized While dump/restoreing /usr to zfs. kgdb trace attached. Let me know if=20 you need further information. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_NISGGyaMHdg/POM Content-Type: text/plain; charset="iso-8859-1"; name="log.dump_panic" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="log.dump_panic" Script started on Sun Apr 8 19:03:59 2007 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: /jpda <118>Make node ./local/diablo-jdk1.5.0/include <118>Make node ./local/diablo-jdk1.5.0/include/freebsd <118>Make node ./local/diablo-jdk1.5.0/jre <118>Make node ./local/diablo-jdk1.5.0/jre/bin <118>Make node ./local/diablo-jdk1.5.0/jre/lib <118>Make node ./local/diablo-jdk1.5.0/jre/lib/applet <118>Make node ./local/diablo-jdk1.5.0/jre/lib/amd64 <118>Make node ./local/diablo-jdk1.5.0/jre/lib/amd64/native_threads <118>Make node ./local/diablo-jdk1.5.0/jre/lib/amd64/server <118>Make node ./local/diablo-jdk1.5.0/jre/lib/amd64/xawt <118>Make node ./local/diablo-jdk1.5.0/jre/lib/amd64/motif21 <118>Make node ./local/diablo-jdk1.5.0/jre/lib/amd64/headless <118>Make node ./local/diablo-jdk1.5.0/jre/lib/ext <118>Make node ./local/diablo-jdk1.5.0/jre/lib/security <118>Make node ./local/diablo-jdk1.5.0/jre/lib/fonts <118>Make node ./local/diablo-jdk1.5.0/jre/lib/oblique-fonts <118>Make node ./local/diablo-jdk1.5.0/jre/lib/images <118>Make node ./local/diablo-jdk1.5.0/jre/lib/images/cursors <118>Make node ./local/diablo-jdk1.5.0/jre/lib/audio <118>Make node ./local/diablo-jdk1.5.0/jre/lib/zi <118>Make node ./local/diablo-jdk1.5.0/jre/lib/zi/Africa <118>Make node ./local/diablo-jdk1.5.0/jre/lib/zi/Atlantic <118>Make node ./local/diablo-jdk1.5.0/jre/lib/zi/Asia <118>Make node ./local/diablo-jdk1.5.0/jre/lib/zi/Antarctica <118>Make node ./local/diablo-jdk1.5.0/jre/lib/zi/America <118>Make node ./local/diablo-jdk1.5.0/jre/lib/zi/America/Kentucky <118>Make node ./local/diablo-jdk1.5.0/jre/lib/zi/America/Argentina <118>Make node ./local/diablo-jdk1.5.0/jre/lib/zi/America/Indiana <118>Make node ./local/diablo-jdk1.5.0/jre/lib/zi/America/North_Dakota <118>Make node ./local/diablo-jdk1.5.0/jre/lib/zi/Australia <118>Make node ./local/diablo-jdk1.5.0/jre/lib/zi/Europe <118>Make node ./local/diablo-jdk1.5.0/jre/lib/zi/Etc <118>Make node ./local/diablo-jdk1.5.0/jre/lib/zi/Indian <118>Make node ./local/diablo-jdk1.5.0/jre/lib/zi/Pacific <118>Make node ./local/diablo-jdk1.5.0/jre/lib/cmm <118>Make node ./local/diablo-jdk1.5.0/jre/lib/im <118>Make node ./local/diablo-jdk1.5.0/jre/lib/management <118>Make node ./local/diablo-jdk1.5.0/lib <118>Make node ./local/diablo-jdk1.5.0/man <118>Make node ./local/diablo-jdk1.5.0/man/man1 <118>Make node ./local/diablo-jdk1.5.0/man/ja_JP.eucJP <118>Make node ./local/diablo-jdk1.5.0/man/ja_JP.eucJP/man1 <118>Make node ./local/diablo-jdk1.5.0/sample <118>Make node ./local/diablo-jdk1.5.0/sample/nio <118>Make node ./local/diablo-jdk1.5.0/sample/nio/server <118>Make node ./local/live <118>Make node ./local/live/groupsock <118>Make node ./local/live/groupsock/include <118>Make node ./local/live/liveMedia <118>Make node ./local/live/liveMedia/include <118>Make node ./local/live/UsageEnvironment <118>Make node ./local/live/UsageEnvironment/include <118>Make node ./local/live/BasicUsageEnvironment <118>Make node ./local/live/BasicUsageEnvironment/include <118>Make node ./local/lib32 <118>Make node ./local/lib32/compat <118>Make node ./local/perforce <118>Make node ./local/perforce/logs <118>Make node ./local/perforce/root <118>Make node ./local/eclipse <118>Make node ./local/eclipse/configuration <118>Make node ./local/eclipse/configuration/org.eclipse.osgi <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/.manager <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/manifests <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/40 <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/40/1 <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/40/1/.cp <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/47 <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/47/1 <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/47/1/.cp <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/47/1/.cp/intro <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/47/1/.cp/intro/css <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/47/1/.cp/intro/css/graphics <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/47/1/.cp/intro/css/graphics/obj_48 <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/91 <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/91/1 <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/91/1/.cp <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/91/1/.cp/intro <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/91/1/.cp/intro/css <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/91/1/.cp/intro/css/graphics <118>Make node ./local/eclipse/configuration/org.eclipse.osgi/bundles/91/1/.cp/intro/css/graphics/obj_48 <118>Make node ./local/eclipse/configuration/org.eclipse.update <118>Make node ./local/eclipse/configuration/org.eclipse.update/history <118>Make node ./local/eclipse/configuration/org.eclipse.core.runtime <118>Make node ./local/eclipse/configuration/org.eclipse.core.runtime/.manager <118>Make node ./local/eclipse/configuration/.settings <118>Make node ./local/eclipse/features panic: lock "zfs:&zap->zap_f.zap_num_entries_mtx" 0xffffff006582c260 already initialized cpuid = 0 KDB: enter: panic panic: from debugger cpuid = 0 Uptime: 6m52s Physical memory: 2038 MB Dumping 209 MB: 194 178 162 146 130 114 98 82 66 50 34 18 2 #0 doadump () at pcpu.h:171 171 pcpu.h: No such file or directory. in pcpu.h (kgdb) add-symbol-file /boot/kernel/zfs.ko 0xffffffff807ad000 add symbol table from file "/boot/kernel/zfs.ko" at .text_addr = 0xffffffff807ad000 (y or n) y Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. (kgdb) where #0 doadump () at pcpu.h:171 #1 0xffffffff80295c79 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xffffffff80295707 in panic (fmt=0xffffffff8045a288 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xffffffff801896c7 in db_panic (addr=0, have_addr=0, count=0, modif=0x0) at /usr/src/sys/ddb/db_command.c:433 #4 0xffffffff80189b69 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 #5 0xffffffff8018ba73 in db_trap (type=-1360305152, code=0) at /usr/src/sys/ddb/db_main.c:222 #6 0xffffffff802bd0d8 in kdb_trap (type=3, code=0, tf=0xffffffffaeeb6590) at /usr/src/sys/kern/subr_kdb.c:502 #7 0xffffffff8041a5a0 in trap (frame=0xffffffffaeeb6590) at /usr/src/sys/amd64/amd64/trap.c:472 #8 0xffffffff80401ebe in calltrap () at /usr/src/sys/amd64/amd64/exception.S:169 #9 0xffffffff802bcb7f in kdb_enter (msg=0x0) at cpufunc.h:63 #10 0xffffffff80295755 in panic (fmt=0xffffffff80481bc0 "lock \"%s\" %p already initialized") at /usr/src/sys/kern/kern_shutdown.c:547 #11 0xffffffff802bd72e in lock_init (lock=0x0, class=0xffffffff80a11000, name=0xa
, type=0x1b1196
, flags=1048064) at /usr/src/sys/kern/subr_lock.c:201 #12 0xffffffff807f092a in fzap_upgrade (zap=0xffffff006582c200, tx=0xffffff006591dd00) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zap.c:87 #13 0xffffffff807f42d3 in mzap_upgrade (zap=0xffffff006582c200, tx=0xffffff006591dd00) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:361 #14 0xffffffff807f4cd4 in zap_add (os=0x0, zapobj=18446744071572623360, name=0xffffff00060ebc19 "org.eclipse.jdt_3.2.1.r321_v20060905-R4CM1Znkvre9wC-", integer_size=8, num_integers=1, val=0xffffffffaeeb6860, tx=0xffffff006591dd00) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:622 #15 0xffffffff80802d06 in zfs_link_create (dl=0xffffff0065554140, zp=0xffffff005ccfac08, tx=0xffffff006591dd00, flag=1) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:564 #16 0xffffffff8080c01c in zfs_mkdir (ap=0xffffffffaeeb6960) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1474 #17 0xffffffff804490f9 in VOP_MKDIR_APV (vop=0x12, a=0xffffffffaeeb6960) at vnode_if.c:1234 #18 0xffffffff80316195 in kern_mkdir (td=0xffffff000105e000, path=0x5149d1
, segflg=15549312, mode=511) at vnode_if.h:653 #19 0xffffffff8041abd0 in syscall (frame=0xffffffffaeeb6c70) at /usr/src/sys/amd64/amd64/trap.c:825 #20 0xffffffff8040206b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:272 #21 0x000000080071969c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) f 12 #12 0xffffffff807f092a in fzap_upgrade (zap=0xffffff006582c200, tx=0xffffff006591dd00) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zap.c:87 87 mutex_init(&zap->zap_f.zap_num_entries_mtx, NULL, MUTEX_DEFAULT, 0); (kgdb) p zap $1 = (zap_t *) 0xffffff006582c200 (kgdb) p *zap $2 = {zap_objset = 0xffffff0001406410, zap_object = 12660, zap_dbuf = 0xffffff005ce892d0, zap_rwlock = {lock_object = { lo_name = 0xffffffff8081b416 "zfs:&zap->zap_rwlock", lo_type = 0xffffffff8081b416 "zfs:&zap->zap_rwlock", lo_flags = 41615360, lo_witness_data = { lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, sx_lock = 18446742974215086080, sx_recurse = 0}, zap_ismicro = 0, zap_salt = 965910969, zap_u = {zap_fat = {zap_phys = 0xffffffff81670000, zap_num_entries_mtx = {lock_object = {lo_name = 0x70000
, lo_type = 0x0, lo_flags = 2155822976, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, sx_lock = 1, sx_recurse = 0}, zap_block_shift = 0}, zap_micro = {zap_phys = 0xffffffff81670000, zap_num_entries = 0, zap_num_chunks = 7, zap_alloc_next = 0, zap_avl = { avl_root = 0x0, avl_compar = 0xffffffff807f3f80 , avl_offset = 0, avl_numnodes = 1, avl_size = 0}}}} (kgdb) q Script done on Sun Apr 8 19:06:29 2007 --Boundary-01=_NISGGyaMHdg/POM-- --nextPart5655571.IUblBEjXgS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGGSISXyyEoT62BG0RAttuAJ4sDZTws5ITtvSREutuFN4RYxL+SQCffJTE PjvtSxCx0GCb3euzHwFpU0Q= =pDsn -----END PGP SIGNATURE----- --nextPart5655571.IUblBEjXgS-- From owner-freebsd-fs@FreeBSD.ORG Sun Apr 8 18:14:16 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 2814116A403; Sun, 8 Apr 2007 18:14:16 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id AA83513C4BA; Sun, 8 Apr 2007 18:14:15 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.29.9] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1HabtY0ntw-0000hb; Sun, 08 Apr 2007 20:13:44 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Sun, 8 Apr 2007 20:13:59 +0200 User-Agent: KMail/1.9.5 References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <200704081910.42852.max@love2party.net> In-Reply-To: <200704081910.42852.max@love2party.net> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1730977.T05y8ciJiq"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704082014.06848.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/TsmNzCiILKoCY26DftHjk2dvCi6F3BxAm1aA TccsrXnIWkNy7Vu3yUiNO3IT8PYE+CyHpMcX31v23uXYeVoxSa i/4RB558CIX7O2tVlnexg== Cc: freebsd-fs@freebsd.org, Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. 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, 08 Apr 2007 18:14:16 -0000 --nextPart1730977.T05y8ciJiq Content-Type: multipart/mixed; boundary="Boundary-01=_pDTGGLUrWjPd/IY" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_pDTGGLUrWjPd/IY Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 08 April 2007 19:10, Max Laier wrote: > On Saturday 07 April 2007 21:43, Dag-Erling Sm=F8rgrav wrote: > > Pawel Jakub Dawidek writes: > > > Limitations. > > > > > > Currently ZFS is only compiled as kernel module and is only > > > available for i386 architecture. Amd64 should be available very > > > soon, the other archs will come later, as we implement needed > > > atomic operations. > > > > ZFS is now also available on pc98 and amd64. > > panic: lock "zfs:&zap->zap_f.zap_num_entries_mtx" 0xffffff006582c260 > already initialized > > While dump/restoreing /usr to zfs. kgdb trace attached. Let me know > if you need further information. The attached diff lets me survive the dump/restore. Not sure if this is=20 the right fix, but seems like the union messes with mutex initialization. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_pDTGGLUrWjPd/IY Content-Type: text/x-diff; charset="iso-8859-6"; name="zfs.dump.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zfs.dump.diff" Index: zap.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/opensolaris/uts/common/fs/= zfs/zap.c,v retrieving revision 1.1 diff -u -r1.1 zap.c =2D-- zap.c 6 Apr 2007 01:09:02 -0000 1.1 +++ zap.c 8 Apr 2007 17:48:07 -0000 @@ -84,6 +84,9 @@ (void) dmu_buf_update_user(zap->zap_dbuf, zap, zap, &zap->zap_f.zap_phys, zap_evict); =20 +#ifdef _KERNEL + memset(&zap->zap_f.zap_num_entries_mtx, 0, sizeof(struct mtx)); +#endif mutex_init(&zap->zap_f.zap_num_entries_mtx, NULL, MUTEX_DEFAULT, 0); zap->zap_f.zap_block_shift =3D highbit(zap->zap_dbuf->db_size) - 1; =20 --Boundary-01=_pDTGGLUrWjPd/IY-- --nextPart1730977.T05y8ciJiq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGGTDuXyyEoT62BG0RAjxkAJ9K1rP5fze+6TvKCSpiDtEJ/Ob7QgCeN0nm 2IlZdXUnKaAV7JG4Ya4a3IY= =IuYE -----END PGP SIGNATURE----- --nextPart1730977.T05y8ciJiq-- From owner-freebsd-fs@FreeBSD.ORG Sun Apr 8 18:20:48 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 DE5D916A405; Sun, 8 Apr 2007 18:20:48 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 98EF213C4BF; Sun, 8 Apr 2007 18:20:48 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 2293D20A3; Sun, 8 Apr 2007 20:20:45 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 10C7920A2; Sun, 8 Apr 2007 20:20:45 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id F07FCA10A5; Sun, 8 Apr 2007 20:20:44 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Max Laier References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <200704081910.42852.max@love2party.net> <200704082014.06848.max@love2party.net> Date: Sun, 08 Apr 2007 20:20:44 +0200 In-Reply-To: <200704082014.06848.max@love2party.net> (Max Laier's message of "Sun, 8 Apr 2007 20:13:59 +0200") Message-ID: <86fy7au3r7.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. 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, 08 Apr 2007 18:20:49 -0000 Max Laier writes: > The attached diff lets me survive the dump/restore. Not sure if > this is the right fix, but seems like the union messes with mutex > initialization. You need to track down where memory for the mutex (or rather zap) was actually allocated, and stick the memset there. I suspect it originates on the stack somewhere. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Sun Apr 8 18:43:11 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 0C03C16A400; Sun, 8 Apr 2007 18:43:11 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 9099113C44B; Sun, 8 Apr 2007 18:43:10 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.29.9] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1HacM10MvN-0001I9; Sun, 08 Apr 2007 20:43:09 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Sun, 8 Apr 2007 20:43:13 +0200 User-Agent: KMail/1.9.5 References: <20070406025700.GB98545@garage.freebsd.pl> <200704082014.06848.max@love2party.net> <86fy7au3r7.fsf@dwp.des.no> In-Reply-To: <86fy7au3r7.fsf@dwp.des.no> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2124331.bhX3V1GLuj"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704082043.22218.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/ot0D/UDyw1zJ/3P4L0Zx3GTI2iVGv4V+mV5T JPmJDxI/zQ1Z0BYSObJ0glh7r0IE4JcXXOqXX8zeWhjiZi222Q 7DgjGYJROyCWJ8a5DZj3g== Cc: freebsd-fs@freebsd.org, Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. 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, 08 Apr 2007 18:43:11 -0000 --nextPart2124331.bhX3V1GLuj Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 08 April 2007 20:20, Dag-Erling Sm=F8rgrav wrote: > Max Laier writes: > > The attached diff lets me survive the dump/restore. Not sure if > > this is the right fix, but seems like the union messes with mutex > > initialization. > > You need to track down where memory for the mutex (or rather zap) was > actually allocated, and stick the memset there. I suspect it > originates on the stack somewhere. Well, I assume it is zeroed already, but on the way the other union=20 members are used which messes up the storage for the mutex. At least=20 looking at the contents gives me that impression: > $2 =3D {zap_objset =3D 0xffffff0001406410, zap_object =3D 12660, zap_dbuf= =3D > 0xffffff005ce892d0, zap_rwlock =3D {lock_object =3D { lo_name =3D > 0xffffffff8081b416 "zfs:&zap->zap_rwlock", lo_type =3D 0xffffffff8081b416 > "zfs:&zap->zap_rwlock", lo_flags =3D 41615360, lo_witness_data =3D { > lod_list =3D {stqe_next =3D 0x0}, lod_witness =3D 0x0}}, sx_lock =3D > 18446742974215086080, sx_recurse =3D 0}, zap_ismicro =3D 0, zap_salt =3D > 965910969, zap_u =3D {zap_fat =3D {zap_phys =3D 0xffffffff81670000, > zap_num_entries_mtx =3D {lock_object =3D {lo_name =3D 0x70000
0x70000 out of bounds>, lo_type =3D 0x0, lo_flags =3D 2155822976, > lo_witness_data =3D {lod_list =3D {stqe_next =3D 0x0}, lod_witness =3D 0x= 0}}, > sx_lock =3D 1, sx_recurse =3D 0}, zap_block_shift =3D 0}, zap_micro =3D > {zap_phys =3D 0xffffffff81670000, zap_num_entries =3D 0, zap_num_chunks = =3D > 7, zap_alloc_next =3D 0, zap_avl =3D { avl_root =3D 0x0, avl_compar =3D > 0xffffffff807f3f80 , avl_offset =3D 0, avl_numnodes =3D 1, > avl_size =3D 0}}}} =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2124331.bhX3V1GLuj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGGTfKXyyEoT62BG0RAjPoAJ9qouEbfMAM0Pi8l8jTWfXWMwQwjACfSKgv /VqgosheeIfA/IQoBV9h6Fs= =piw2 -----END PGP SIGNATURE----- --nextPart2124331.bhX3V1GLuj-- From owner-freebsd-fs@FreeBSD.ORG Sun Apr 8 18:48:47 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 2B5EA16A401; Sun, 8 Apr 2007 18:48:47 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id EB2FA13C44B; Sun, 8 Apr 2007 18:48:46 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.8/8.13.7) with ESMTP id l38IcEr0001895; Sun, 8 Apr 2007 11:38:14 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.8/8.13.4/Submit) id l38IcEfq001894; Sun, 8 Apr 2007 11:38:14 -0700 (PDT) Date: Sun, 8 Apr 2007 11:38:14 -0700 (PDT) From: Matthew Dillon Message-Id: <200704081838.l38IcEfq001894@apollo.backplane.com> To: Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> Cc: freebsd-fs@freebsd.org, zfs-discuss@opensolaris.org, freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. 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, 08 Apr 2007 18:48:47 -0000 :Hi. : :I'm happy to inform that the ZFS file system is now part of the FreeBSD :operating system. ZFS is available in the HEAD branch and will be :available in FreeBSD 7.0-RELEASE as an experimental feature. Congratulations on your excellent work, Pawel! -Matt From owner-freebsd-fs@FreeBSD.ORG Sun Apr 8 18:53:51 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 060A516A402; Sun, 8 Apr 2007 18:53:51 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 186D513C458; Sun, 8 Apr 2007 18:53:49 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4AA22487FB; Sun, 8 Apr 2007 20:53:48 +0200 (CEST) Received: from localhost (cvl74.internetdsl.tpnet.pl [83.19.93.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 2FD9F45B26; Sun, 8 Apr 2007 20:53:32 +0200 (CEST) Date: Sun, 8 Apr 2007 20:53:12 +0200 From: Pawel Jakub Dawidek To: Max Laier Message-ID: <20070408185312.GY63916@garage.freebsd.pl> References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <200704081910.42852.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TXtETX/xrt1zdi6e" Content-Disposition: inline In-Reply-To: <200704081910.42852.max@love2party.net> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org, Dag-Erling Sm?rgrav , freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. 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, 08 Apr 2007 18:53:51 -0000 --TXtETX/xrt1zdi6e Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 08, 2007 at 07:10:36PM +0200, Max Laier wrote: > On Saturday 07 April 2007 21:43, Dag-Erling Sm?rgrav wrote: > > Pawel Jakub Dawidek writes: > > > Limitations. > > > > > > Currently ZFS is only compiled as kernel module and is only > > > available for i386 architecture. Amd64 should be available very soon, > > > the other archs will come later, as we implement needed atomic > > > operations. > > > > ZFS is now also available on pc98 and amd64. >=20 > panic: lock "zfs:&zap->zap_f.zap_num_entries_mtx" 0xffffff006582c260=20 > already initialized >=20 > While dump/restoreing /usr to zfs. kgdb trace attached. Let me know if= =20 > you need further information. [...] > #10 0xffffffff80295755 in panic (fmt=3D0xffffffff80481bc0 "lock \"%s\" %p= already initialized") at /usr/src/sys/kern/kern_shutdown.c:547 > #11 0xffffffff802bd72e in lock_init (lock=3D0x0, class=3D0xffffffff80a110= 00, name=3D0xa
, > type=3D0x1b1196
, flags=3D1048064) at= /usr/src/sys/kern/subr_lock.c:201 > #12 0xffffffff807f092a in fzap_upgrade (zap=3D0xffffff006582c200, tx=3D0x= ffffff006591dd00) > at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/z= fs/zap.c:87 > #13 0xffffffff807f42d3 in mzap_upgrade (zap=3D0xffffff006582c200, tx=3D0x= ffffff006591dd00) > at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/z= fs/zap_micro.c:361 > #14 0xffffffff807f4cd4 in zap_add (os=3D0x0, zapobj=3D1844674407157262336= 0, name=3D0xffffff00060ebc19 "org.eclipse.jdt_3.2.1.r321_v20060905-R4CM1Znk= vre9wC-", > integer_size=3D8, num_integers=3D1, val=3D0xffffffffaeeb6860, tx=3D0x= ffffff006591dd00) > at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/z= fs/zap_micro.c:622 > #15 0xffffffff80802d06 in zfs_link_create (dl=3D0xffffff0065554140, zp=3D= 0xffffff005ccfac08, tx=3D0xffffff006591dd00, flag=3D1) > at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/z= fs/zfs_dir.c:564 > #16 0xffffffff8080c01c in zfs_mkdir (ap=3D0xffffffffaeeb6960) at /usr/src= /sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:14= 74 > #17 0xffffffff804490f9 in VOP_MKDIR_APV (vop=3D0x12, a=3D0xffffffffaeeb69= 60) at vnode_if.c:1234 > #18 0xffffffff80316195 in kern_mkdir (td=3D0xffffff000105e000, path=3D0x5= 149d1
, segflg=3D15549312, mode=3D511) at v= node_if.h:653 > #19 0xffffffff8041abd0 in syscall (frame=3D0xffffffffaeeb6c70) at /usr/sr= c/sys/amd64/amd64/trap.c:825 > #20 0xffffffff8040206b in Xfast_syscall () at /usr/src/sys/amd64/amd64/ex= ception.S:272 > #21 0x000000080071969c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) f 12 > #12 0xffffffff807f092a in fzap_upgrade (zap=3D0xffffff006582c200, tx=3D0x= ffffff006591dd00) > at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/z= fs/zap.c:87 > 87 mutex_init(&zap->zap_f.zap_num_entries_mtx, NULL, MUTEX_DEFAULT, 0); > (kgdb) p zap > $1 =3D (zap_t *) 0xffffff006582c200 > (kgdb) p *zap > $2 =3D {zap_objset =3D 0xffffff0001406410, zap_object =3D 12660, zap_dbuf= =3D 0xffffff005ce892d0, zap_rwlock =3D {lock_object =3D { > lo_name =3D 0xffffffff8081b416 "zfs:&zap->zap_rwlock", lo_type =3D = 0xffffffff8081b416 "zfs:&zap->zap_rwlock", lo_flags =3D 41615360, lo_witnes= s_data =3D { > lod_list =3D {stqe_next =3D 0x0}, lod_witness =3D 0x0}}, sx_lock =3D 184= 46742974215086080, sx_recurse =3D 0}, zap_ismicro =3D 0, zap_salt =3D 96591= 0969, > zap_u =3D {zap_fat =3D {zap_phys =3D 0xffffffff81670000, zap_num_entrie= s_mtx =3D {lock_object =3D {lo_name =3D 0x70000
, > lo_type =3D 0x0, lo_flags =3D 2155822976, lo_witness_data =3D {lod_lis= t =3D {stqe_next =3D 0x0}, lod_witness =3D 0x0}}, sx_lock =3D 1, sx_recurse= =3D 0}, > zap_block_shift =3D 0}, zap_micro =3D {zap_phys =3D 0xffffffff81670= 000, zap_num_entries =3D 0, zap_num_chunks =3D 7, zap_alloc_next =3D 0, zap= _avl =3D { > avl_root =3D 0x0, avl_compar =3D 0xffffffff807f3f80 , avl_o= ffset =3D 0, avl_numnodes =3D 1, avl_size =3D 0}}}} fzap_upgrade() changes type from 'zap_micro' to 'zap_fat' and union is used for this (see sys/contrib/opensolaris/uts/common/fs/zfs/sys/zap_impl.h), that's why we see this trash: zap_num_entries_mtx =3D {lock_object =3D {lo_name =3D 0x70000
, lo_type =3D 0x0, lo_flags =3D 2155822976, lo_witness_data =3D {lod_list =3D= {stqe_next =3D 0x0}, lod_witness =3D 0x0}}, sx_lock =3D 1, sx_recurse =3D 0}, I already use kmem_zalloc() (note _z_) for zap allocation in zap_micro.c, so Max is right, that we have to clear this structure here. I'm quite tired of tracking such problems, because our mechanism for detecting already initialized locks is too simple (based on one bit), so I'd prefer to improve it, or just add bzero() to mutex_init(). --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --TXtETX/xrt1zdi6e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGGToYForvXbEpPzQRAgAnAJ40zrRTU/4AcIe9xZDGxsJH69RUDACfYitt rnhzBOwWqBWTJNSftIX7H70= =AD9U -----END PGP SIGNATURE----- --TXtETX/xrt1zdi6e-- From owner-freebsd-fs@FreeBSD.ORG Sun Apr 8 21:41:01 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 9E24B16A404 for ; Sun, 8 Apr 2007 21:41:01 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailhub.cs.uoguelph.ca (mailhub.cs.uoguelph.ca [131.104.94.205]) by mx1.freebsd.org (Postfix) with ESMTP id 4688813C455 for ; Sun, 8 Apr 2007 21:41:01 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.96.170]) by mailhub.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id l38Lex01015179; Sun, 8 Apr 2007 17:40:59 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id l38Lf4m24844; Sun, 8 Apr 2007 17:41:05 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sun, 8 Apr 2007 17:41:04 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher To: Pawel Jakub Dawidek In-Reply-To: <20070407005705.GA63050@garage.freebsd.pl> Message-ID: References: <20070406025700.GB98545@garage.freebsd.pl> <4616CC12.8040107@ruomad.net> <20070407005705.GA63050@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 131.104.94.205 Cc: freebsd-fs@freebsd.org, Bruno Damour , freebsd-current@freebsd.org, zfs-discuss@opensolaris.org Subject: Re: ZFS committed to the FreeBSD base. 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, 08 Apr 2007 21:41:01 -0000 On Sat, 7 Apr 2007, Pawel Jakub Dawidek wrote: >>> - There is no support for ACLs and extended attributes. >>> >> Is this planned ? Does that means I cannot use it as a basis for a full-featured samba share ? > > It is planned, but it's not trivial. Does samba support NFSv4-style > ACLs? I don't know about samba, but my NFSv4 server can certainly use them. I'll add my congratulations and thanks for the good work, to the list. (Currently I know diddly about ZFS, but I'll try it someday.) Good luck with it, rick From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 01:07:19 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 442DB16A402; Mon, 9 Apr 2007 01:07:19 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id D7A5313C458; Mon, 9 Apr 2007 01:07:18 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id B2676487FB; Mon, 9 Apr 2007 03:07:16 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1D4E5487F0; Mon, 9 Apr 2007 03:07:11 +0200 (CEST) Date: Mon, 9 Apr 2007 03:07:03 +0200 From: Pawel Jakub Dawidek To: Max Laier Message-ID: <20070409010703.GA74547@garage.freebsd.pl> References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <200704081910.42852.max@love2party.net> <20070408185312.GY63916@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <20070408185312.GY63916@garage.freebsd.pl> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org, Dag-Erling Sm?rgrav , freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. 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, 09 Apr 2007 01:07:19 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 08, 2007 at 08:53:12PM +0200, Pawel Jakub Dawidek wrote: > fzap_upgrade() changes type from 'zap_micro' to 'zap_fat' and union is > used for this (see > sys/contrib/opensolaris/uts/common/fs/zfs/sys/zap_impl.h), that's why we > see this trash: >=20 > zap_num_entries_mtx =3D {lock_object =3D {lo_name =3D 0x70000
, > lo_type =3D 0x0, lo_flags =3D 2155822976, lo_witness_data =3D {lod_list = =3D {stqe_next =3D 0x0}, > lod_witness =3D 0x0}}, sx_lock =3D 1, sx_recurse =3D 0}, >=20 > I already use kmem_zalloc() (note _z_) for zap allocation in > zap_micro.c, so Max is right, that we have to clear this structure here. >=20 > I'm quite tired of tracking such problems, because our mechanism for > detecting already initialized locks is too simple (based on one bit), so > I'd prefer to improve it, or just add bzero() to mutex_init(). I just committed a fix. Now I do 13 bits check for already initialized locks detection instead of standard 1 bit check. Could you repeat your test? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGGZG3ForvXbEpPzQRAkuzAJ9B0hzoFOn1hi/obdoxJDmh7vKZlwCg796x J97euQ4Nk4LEW9Qv1Z/mQsw= =qgao -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 01:17:37 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 D198D16A401; Mon, 9 Apr 2007 01:17:37 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 73E0913C465; Mon, 9 Apr 2007 01:17:37 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4DC40487FF; Mon, 9 Apr 2007 03:17:36 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4A3C145681; Mon, 9 Apr 2007 03:17:30 +0200 (CEST) Date: Mon, 9 Apr 2007 03:17:23 +0200 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20070409011723.GB74547@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R3G7APHDIzY6R/pk" Content-Disposition: inline X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org Subject: ZFS: amd64, devd, root file system. 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, 09 Apr 2007 01:17:38 -0000 --R3G7APHDIzY6R/pk Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. Just a quick summary on recently committed changes: 1. ZFS can now be used on amd64. Thanks goes to des and kan for testing. 2. I added sample entries to devd.conf, which show how to handle problems reported by ZFS, like I/O failures, VDEV failures, checksum mismatches, etc. 3. It is now possible to have root file system on ZFS. You would still need UFS for your /boot/ file system. Location of zpool.cache file has changed from /etc/zfs/ to /boot/zfs/. To avoid any troubles you should: # zpool export # kldunload zfs # mv /etc/zfs/zpool.cache /boot/zfs/ # make kernel # kldload zfs # zpool import If you won't do it, /etc/rc.d/zfs most likely won't mount your file systems and you would need to do: # zpool import -f by hand once. Don't forget to remove /etc/zfs/zpool.cache - it will no longer be needed. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --R3G7APHDIzY6R/pk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGGZQjForvXbEpPzQRAnskAKCo9mgQd7zpnbE3I+VXM+KKqfQKcACdEx3n s9GzCn/ugy7lffvZWgiILlM= =KkW2 -----END PGP SIGNATURE----- --R3G7APHDIzY6R/pk-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 02:01:29 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 7FD5516A404; Mon, 9 Apr 2007 02:01:29 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id 11ED913C44C; Mon, 9 Apr 2007 02:01:28 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.185.1] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1HajAJ0gKK-0001FJ; Mon, 09 Apr 2007 03:59:37 +0200 From: Max Laier Organization: FreeBSD To: Pawel Jakub Dawidek Date: Mon, 9 Apr 2007 03:59:24 +0200 User-Agent: KMail/1.9.5 References: <20070406025700.GB98545@garage.freebsd.pl> <20070408185312.GY63916@garage.freebsd.pl> <20070409010703.GA74547@garage.freebsd.pl> In-Reply-To: <20070409010703.GA74547@garage.freebsd.pl> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1808063.uHuXMkA1X8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704090359.30493.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/9fLfBsAYjFFP8e91Uj30pyb551m14aryQZUR ModI031CAqcUbC7lB6G6yXlMcpEvWfAqPiMHt+wSk/tmW/EaYM 0V4JBSAr6uZCu33xl8CwQ== Cc: freebsd-fs@freebsd.org, Dag-Erling Sm?rgrav , freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. 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, 09 Apr 2007 02:01:29 -0000 --nextPart1808063.uHuXMkA1X8 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 09 April 2007 03:07, Pawel Jakub Dawidek wrote: > On Sun, Apr 08, 2007 at 08:53:12PM +0200, Pawel Jakub Dawidek wrote: > > fzap_upgrade() changes type from 'zap_micro' to 'zap_fat' and union > > is used for this (see > > sys/contrib/opensolaris/uts/common/fs/zfs/sys/zap_impl.h), that's why > > we see this trash: > > > > zap_num_entries_mtx =3D {lock_object =3D {lo_name =3D 0x70000
> 0x70000 out of bounds>, lo_type =3D 0x0, lo_flags =3D 2155822976, > > lo_witness_data =3D {lod_list =3D {stqe_next =3D 0x0}, lod_witness =3D = 0x0}}, > > sx_lock =3D 1, sx_recurse =3D 0}, > > > > I already use kmem_zalloc() (note _z_) for zap allocation in > > zap_micro.c, so Max is right, that we have to clear this structure > > here. > > > > I'm quite tired of tracking such problems, because our mechanism for > > detecting already initialized locks is too simple (based on one bit), > > so I'd prefer to improve it, or just add bzero() to mutex_init(). > > I just committed a fix. Now I do 13 bits check for already initialized > locks detection instead of standard 1 bit check. Could you repeat your > test? Will do tomorrow. Thanks. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1808063.uHuXMkA1X8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGGZ4CXyyEoT62BG0RAsrPAJ4wzq6erlw5IQRpsViAS3uqDm9nKwCfRBvT hmrRGWrdDA2eCrEF8WeBIzE= =ujZh -----END PGP SIGNATURE----- --nextPart1808063.uHuXMkA1X8-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 02:09:44 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 D0F8A16A405 for ; Mon, 9 Apr 2007 02:09:44 +0000 (UTC) (envelope-from juhasaarinen@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.228]) by mx1.freebsd.org (Postfix) with ESMTP id 8844E13C457 for ; Mon, 9 Apr 2007 02:09:44 +0000 (UTC) (envelope-from juhasaarinen@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so973257nza for ; Sun, 08 Apr 2007 19:09:44 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DuB4bnLbBUWAgI4VHDA/9ThCQ3k+7GYklc2M/3yxS9BS7O8rAD/k1cfH3T6mO25a2NE6s1mmdGJb7serCsj5kiZY6mWKUf+qrH/PrzzZqsb3SOrZibmt+HNcv+QLHtYcLIoaqgksx3QZHsoGkUVBe0ldP8itAXI4FiKINCyHo8k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uoKGc1IN/wanN8vvQjZg3sZbdMF/R15mmgGPh6zPdpgN5+55548pB7vHWIqQh9F0RlzyDlkVZT/1NG/N9EoHOFzrF+wVDjNvCmR/R8woonid2HCy8S3Yys0eQedfZ6eA60byBT03AUt1Yiuq0rdOG88BdGw5LQSeE2tSDSGPBcg= Received: by 10.115.78.1 with SMTP id f1mr2099033wal.1176084583391; Sun, 08 Apr 2007 19:09:43 -0700 (PDT) Received: by 10.115.95.19 with HTTP; Sun, 8 Apr 2007 19:09:43 -0700 (PDT) Message-ID: Date: Mon, 9 Apr 2007 14:09:43 +1200 From: "Juha Saarinen" To: "Pawel Jakub Dawidek" In-Reply-To: <20070409011723.GB74547@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070409011723.GB74547@garage.freebsd.pl> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS: amd64, devd, root file system. 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, 09 Apr 2007 02:09:44 -0000 On 4/9/07, Pawel Jakub Dawidek wrote: > 3. It is now possible to have root file system on ZFS. You would still > need UFS for your /boot/ file system. Stupid question perhaps, but I couldn't find the answer through searching... why is it not possible to boot directly from ZFS, only from UFS? -- Juha http://www.geekzone.co.nz/juha From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 02:14:25 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 3FD2B16A402; Mon, 9 Apr 2007 02:14:25 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2A8B113C457; Mon, 9 Apr 2007 02:14:25 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 573811A3C19; Sun, 8 Apr 2007 19:14:28 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id DB0CE514C3; Sun, 8 Apr 2007 22:14:23 -0400 (EDT) Date: Sun, 8 Apr 2007 22:14:23 -0400 From: Kris Kennaway To: Juha Saarinen Message-ID: <20070409021423.GA90766@xor.obsecurity.org> References: <20070409011723.GB74547@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: ZFS: amd64, devd, root file system. 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, 09 Apr 2007 02:14:25 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2007 at 02:09:43PM +1200, Juha Saarinen wrote: > On 4/9/07, Pawel Jakub Dawidek wrote: > >3. It is now possible to have root file system on ZFS. You would still > > need UFS for your /boot/ file system. >=20 > Stupid question perhaps, but I couldn't find the answer through > searching... why is it not possible to boot directly from ZFS, only > from UFS? The boot blocks need to read the loader from the filesystem, which in turns needs to load the kernel from the filesystem. This involves parsing the filesystem. Kris --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGGaF/Wry0BWjoQKURApGsAKDyJDBHFWudhYwfud01p23Do/HTNgCgs0z+ xX7Fcq7C5GuDoKghPzCR6Ck= =1Z0i -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 03:39:24 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 B672F16A400; Mon, 9 Apr 2007 03:39:24 +0000 (UTC) (envelope-from bland@FreeBSD.org) Received: from smtp1.jp.viruscheck.net (smtp1.jp.viruscheck.net [154.33.69.52]) by mx1.freebsd.org (Postfix) with ESMTP id 8073713C448; Mon, 9 Apr 2007 03:39:24 +0000 (UTC) (envelope-from bland@FreeBSD.org) Received: from (mail1.jp.viruscheck.net) [154.33.69.39]:13243 by smtp1.jp.viruscheck.net with esmtp id 1HakFw-0006cn-3h ; Mon, 09 Apr 2007 12:09:24 +0900 Received: from (noc.orchid.orchidtechnology.com) [125.206.34.113]:35626 by mail1.jp.viruscheck.net with esmtp id 1HakFv-0000nk-IJ ; Mon, 09 Apr 2007 12:09:23 +0900 Received: from [89.60.200.25] ([89.60.200.25]) by noc.orchid.orchidtechnology.com (8.13.4/8.13.4) with ESMTP id l3939M0O065291; Mon, 9 Apr 2007 12:09:22 +0900 (JST) (envelope-from bland@FreeBSD.org) Message-ID: <4619AE5C.7000902@FreeBSD.org> Date: Mon, 09 Apr 2007 12:09:16 +0900 From: Alexander Nedotsukov User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406214325.GB61039@garage.freebsd.pl> In-Reply-To: <20070406214325.GB61039@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS - quick start. 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, 09 Apr 2007 03:39:24 -0000 Pawel, Quick question. Is it typical to ZFS to run over 100 kthreads? I see a lot of spa_*s in ps output. Other bits are: bland@nest:~$zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 4,19G 295M 3,90G 6% ONLINE - bland@nest:~$zfs list NAME USED AVAIL REFER MOUNTPOINT tank 295M 3,83G 18K /tank tank/ports 294M 3,83G 294M /usr/ports tank/tmp 535K 3,83G 535K /tmp Thanks, Alexander. Pawel Jakub Dawidek wrote: > Ok, ZFS is now in the tree, what's now? Below you'll find some > instructions how to quickly make it up and running. > > First of all you need some disks. Let's assume you have three spare SCSI > disks: da0, da1, da2. > > Add a line to your /etc/rc.conf to start ZFS automatically on boot: > > # echo 'zfs_enable="YES"' >> /etc/rc.conf > > Load ZFS kernel module, for the first time by hand: > > # kldload zfs.ko > > Now, setup one pool using RAIDZ: > > # zpool create tank raidz da0 da1 da2 > > It should automatically mount /tank/ for you. > > Ok, now put /usr/ on ZFS and propose some file systems layout. I know > you probably have some files already, so we will work on /tank/usr > directory and once we ready, we will just change the mountpoint to /usr. > > # zfs create tank/usr > > Create ports/ file system and enable gzip compression on it, because > most likely we will have only text files there. On the other hand, we > don't want to compress ports/distfiles/, because we keep compressed > stuff already in-there: > > # zfs create tank/usr/ports > # zfs set compression=gzip tank/usr/ports > # zfs create tank/usr/ports/distfiles > # zfs set compression=off tank/usr/ports/distfiles > > (You do see how your life is changing, don't you?:)) > > Let's create home file system, my own home/pjd/ file system. I know we > use RAIDZ, but I want to have directory where I put extremly important > stuff, you I'll define that each block has to be stored in tree copies: > > # zfs create tank/usr/home > # zfs create tank/usr/home/pjd > # zfs create tank/usr/home/pjd/important > # zfs set copies=3 tank/usr/home/pjd/important > > I'd like to have directory with music, etc. that I NFS share. I don't > really care about this stuff and my computer is not very fast, so I'll > just turn off checksumming (this is only for example purposes! please, > benchmark before doing it, because it's most likely not worth it!): > > # zfs create tank/music > # zfs set checksum=off tank/music > # zfs set sharenfs=on tank/music > > Oh, I almost forget. Who cares about access time updates? > > # zfs set atime=off tank > > Yes, we set it only on tank and it will be automatically inherited by > others. > > Will be also good to be informed if everything is fine with our pool: > > # echo 'daily_status_zfs_enable="YES"' >> /etc/periodic.conf > > For some reason you still need UFS file system, for example you use ACLs > or extended attributes which are not yet supported by our ZFS. If so, > why not just use ZFS to provide storage? This way we gain cheap UFS > snapshots, UFS clones, etc. by simply using ZVOLs. > > # zfs create -V 10g tank/ufs > # newfs /dev/zvol/tank/ufs > # mount /dev/zvol/tank/ufs /ufs > > # zfs snapshot tank/ufs@20070406 > # mount -r /dev/zvol/tank/ufs@20070406 /ufs20070406 > > # zfs clone tank/ufs@20070406 tank/ufsok > # fsck_ffs -p /dev/zvol/tank/ufsok > # mount /dev/zvol/tank/ufsok /ufsok > > Want to encrypt your swap and still use ZFS? Nothing more trivial: > > # zfs create -V 4g tank/swap > # geli onetime -s 4096 /dev/zvol/tank/swap > # swapon /dev/zvol/tank/swap.eli > > Trying to do something risky with your home? Snapshot it first! > > # zfs snapshot tank/home/pjd@justincase > > Turns out it was more stupid than risky? Rollback your snapshot! > > # zfs rollback tank/home/pjd@justincase > # zfs destroy tank/home/pjd@justincase > > Ok, everything works, we may set tank/usr as our real /usr: > > # zfs set mountpoint=/usr tank/usr > > Don't forget to read zfs(8) and zpool(8) manual pages and SUN's ZFS > administration guide: > > http://www.opensolaris.org/os/community/zfs/docs/zfsadmin.pdf > > From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 06:36:06 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 5CD8016A400 for ; Mon, 9 Apr 2007 06:36:06 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (lab.alexdupre.com [81.174.31.42]) by mx1.freebsd.org (Postfix) with ESMTP id E346313C448 for ; Mon, 9 Apr 2007 06:36:05 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 71746 invoked from network); 9 Apr 2007 06:36:04 -0000 Received: from unknown (HELO ?192.168.178.2?) (192.168.178.2) by lab.alexdupre.com with SMTP; 9 Apr 2007 06:36:04 -0000 Message-ID: <4619DED4.6060102@FreeBSD.org> Date: Mon, 09 Apr 2007 08:36:04 +0200 From: Alex Dupre User-Agent: Thunderbird 1.5.0.10 (X11/20070310) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070409011723.GB74547@garage.freebsd.pl> In-Reply-To: <20070409011723.GB74547@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS: amd64, devd, root file system. 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, 09 Apr 2007 06:36:06 -0000 Pawel Jakub Dawidek wrote: > 3. It is now possible to have root file system on ZFS. You would still > need UFS for your /boot/ file system. Many thanks! I should have known that "some time to implement it" meant "just a couple of nights" ;-) -- Alex Dupre From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 08:44:24 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 ABBAB16A400 for ; Mon, 9 Apr 2007 08:44:24 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 62B7713C455 for ; Mon, 9 Apr 2007 08:44:24 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54a5d3cf.dip.t-dialin.net [84.165.211.207]) by redbull.bpaserver.net (Postfix) with ESMTP id 1EE642E1AC; Mon, 9 Apr 2007 10:22:44 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 3728D5B489B; Mon, 9 Apr 2007 10:22:41 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l398Mfqx012357; Mon, 9 Apr 2007 10:22:41 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from proxy.Leidinger.net (proxy.Leidinger.net [192.168.1.103]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 09 Apr 2007 10:22:40 +0200 Message-ID: <20070409102240.u6yxvjr72888cc04@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 09 Apr 2007 10:22:40 +0200 From: Alexander Leidinger To: Pawel Jakub Dawidek References: <20070409011723.GB74547@garage.freebsd.pl> In-Reply-To: <20070409011723.GB74547@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.787, required 8, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14, TW_ZF 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS: amd64, devd, root file system. 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, 09 Apr 2007 08:44:24 -0000 Quoting Pawel Jakub Dawidek (from Mon, 9 Apr 2007 =20 03:17:23 +0200): > 3. It is now possible to have root file system on ZFS. You would still > need UFS for your /boot/ file system. Do you have a quick guide how to do this? I'm a little bit puzzled how the FS layout would look like. Just from =20 thinking about it I would do the following, but I like to know if this =20 is the right way: - ad0s1a -> contains a / with contains only the boot directory - some zpool which contains / with everything except the boot directory In one scenario I would just hope that ZFS DTRT magically, but this =20 would imply that ZFS does some kind of union/overlay/underlay mount. So I lean more towards a ad0s1a mounted by hand to somewhere else in =20 the ZFS namespace and a symlink from the zfs /boot directory to the =20 real location where the UFS is mounted. In both scenarios I'm not sure how the fstab would look like. Bye, Alexander. --=20 The older a man gets, the farther he had to walk to school as a boy. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 08:51:37 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 0683616A401 for ; Mon, 9 Apr 2007 08:51:37 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (lab.alexdupre.com [81.174.31.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5C91F13C459 for ; Mon, 9 Apr 2007 08:51:36 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 47193 invoked from network); 9 Apr 2007 08:51:35 -0000 Received: from unknown (HELO ?192.168.178.2?) (192.168.178.2) by lab.alexdupre.com with SMTP; 9 Apr 2007 08:51:35 -0000 Message-ID: <4619FE96.2010508@FreeBSD.org> Date: Mon, 09 Apr 2007 10:51:34 +0200 From: Alex Dupre User-Agent: Thunderbird 1.5.0.10 (X11/20070310) MIME-Version: 1.0 To: Alexander Leidinger References: <20070409011723.GB74547@garage.freebsd.pl> <20070409102240.u6yxvjr72888cc04@webmail.leidinger.net> In-Reply-To: <20070409102240.u6yxvjr72888cc04@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS: amd64, devd, root file system. 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, 09 Apr 2007 08:51:37 -0000 Alexander Leidinger wrote: > Do you have a quick guide how to do this? It's the same as having a graid3 or geli root fs: you need a simple ufs partition with /boot and then everything else on zfs. > I'm a little bit puzzled how the FS layout would look like. Just from > thinking about it I would do the following, but I like to know if this > is the right way: > - ad0s1a -> contains a / with contains only the boot directory > - some zpool which contains / with everything except the boot > directory It's not mandatory to remove the boot directory from zfs, but yes, that's the idea. Usually you have ad0s1a on a removable media, or (g)mirror all the adXs1a partitions so that a disk failure doesn't prevent booting into a usable system. > In one scenario I would just hope that ZFS DTRT magically, but this > would imply that ZFS does some kind of union/overlay/underlay mount. > > So I lean more towards a ad0s1a mounted by hand to somewhere else in the > ZFS namespace and a symlink from the zfs /boot directory to the real > location where the UFS is mounted. Why a symlink? You can mount it exactly there. > In both scenarios I'm not sure how the fstab would look like. Currently I'm using a removable media, so I don't automatically mount /boot from it, but I have a copy. If you use the gmirrored disk slices, you can design your /etc/fstab like: /dev/zfs/tank/root / /dev/gmirror/boot /boot /dev/zvol/tank/swap /dev/zfs/tank/usr /usr ... (This is the general idea, I haven't looked how zfs fs entries should appear in fstab, yet, so I cannot give you the exact fstab dump). -- Alex Dupre From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 08:57:42 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 CC1FA16A402 for ; Mon, 9 Apr 2007 08:57:42 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (lab.alexdupre.com [81.174.31.42]) by mx1.freebsd.org (Postfix) with ESMTP id 637E713C4B0 for ; Mon, 9 Apr 2007 08:57:42 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 47370 invoked from network); 9 Apr 2007 08:57:41 -0000 Received: from unknown (HELO ?192.168.178.2?) (192.168.178.2) by lab.alexdupre.com with SMTP; 9 Apr 2007 08:57:41 -0000 Message-ID: <461A0004.7000303@FreeBSD.org> Date: Mon, 09 Apr 2007 10:57:40 +0200 From: Alex Dupre User-Agent: Thunderbird 1.5.0.10 (X11/20070310) MIME-Version: 1.0 To: Alexander Leidinger References: <20070409011723.GB74547@garage.freebsd.pl> <20070409102240.u6yxvjr72888cc04@webmail.leidinger.net> <4619FE96.2010508@FreeBSD.org> In-Reply-To: <4619FE96.2010508@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS: amd64, devd, root file system. 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, 09 Apr 2007 08:57:42 -0000 Alex Dupre wrote: > Why a symlink? You can mount it exactly there. Ops, yes, a symlink, since ad0s1a already contains 'boot' directory. (I said I don't use hard disk slices ;-)) -- Alex Dupre From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 09:43:35 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 0D6B816A40E; Mon, 9 Apr 2007 09:43:35 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 9E57113C46E; Mon, 9 Apr 2007 09:43:34 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id E8AA2487FF; Mon, 9 Apr 2007 11:43:32 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id C5E21487F0; Mon, 9 Apr 2007 11:43:27 +0200 (CEST) Date: Mon, 9 Apr 2007 11:43:19 +0200 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20070409094319.GB76673@garage.freebsd.pl> References: <20070409011723.GB74547@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UHN/qo2QbUvPLonB" Content-Disposition: inline In-Reply-To: <20070409011723.GB74547@garage.freebsd.pl> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS: amd64, devd, root file system. 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, 09 Apr 2007 09:43:35 -0000 --UHN/qo2QbUvPLonB Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2007 at 03:17:23AM +0200, Pawel Jakub Dawidek wrote: > 3. It is now possible to have root file system on ZFS. You would still > need UFS for your /boot/ file system. Let me explain how this suppose to work. You have ad0 disk. Create one slice covering entire disk: # fdisk -BI /dev/ad0 Initialize BSDlabel: # bsdlabel -wB /dev/ad0s1 Edit your label and create small (like 256MB-512MB) 'a' partition and use the rest for 'd' partition: # bsdlabel -e /dev/ad0s1 'd' partition will be used for ZFS: # zpool create tank ad0s1d Create UFS file system on /dev/ad0s1a and copy /boot/ directory in there: # newfs /dev/ad0s1a # mount /dev/ad0s1a /mnt/tmp # cp -Rp /boot/* /mnt/tmp/ Note that there is no /boot/ directory on ad0s1a yet. This is one of the two possibilities. You now need to create symlink: # cd /mnt/tmp # ln -s . boot =46rom what I checked our loader should handle symlinks just fine. This will allow us to mount /dev/ad0s1a on /boot directory and use it as usual. Another option is to: # cp -Rp /boot /mnt/tmp/ and in the future mount /dev/ad0s1a on eg. /bootdisk and create symlink: # ln -s bootdisk/boot /boot All in all, you should see your kernel when you do: # ls -l /mnt/tmp/boot/kernel Now don't forget to add zfs_load=3D"YES" to /mnt/tmp/boot/loader.conf. Ok, you also need to tell your loader where your root file system is. You can do it by adding: vfs.root.mountfrom=3D"zfs:tank" to /mnt/tmp/boot/loader.conf or you can create /mnt/tmp/etc/fstab file with one entry only: tank / zfs rw 0 0 On your ZFS file system, your /etc/fstab should contains the line above and: /dev/ad0s1a /boot ufs rw 0 0 (and everything else, ie. your swap and other file systems) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --UHN/qo2QbUvPLonB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGGgq3ForvXbEpPzQRAmlbAKDspksBGqObSZy1iCUqWDfGIkwGZwCgkrsV RsDmcIlojnNaF2KCDzFTesA= =+ZEQ -----END PGP SIGNATURE----- --UHN/qo2QbUvPLonB-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 14:25:20 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 0C6D316A401 for ; Mon, 9 Apr 2007 14:25:20 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id D6B8613C4D5 for ; Mon, 9 Apr 2007 14:25:19 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l39EPGQE039233; Mon, 9 Apr 2007 09:25:18 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <461A4CCC.8060205@freebsd.org> Date: Mon, 09 Apr 2007 09:25:16 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Mike Wolman References: <20070406025700.GB98545@garage.freebsd.pl> <4615F62A.5090001@FreeBSD.org> <20070406214804.GC61039@garage.freebsd.pl> <20070407001555.G87655@nux.eros.office> In-Reply-To: <20070407001555.G87655@nux.eros.office> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3052/Mon Apr 9 07:23:53 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-fs@freebsd.org Subject: Re: some thoughts about gmirror 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, 09 Apr 2007 14:25:20 -0000 On 04/06/07 18:48, Mike Wolman wrote: > Hi, > > Currently I am using gmirror and ggated to run a live network mirror. > Obviously this can cause problems if the server exporting the 'backup' > device is offline then the mirror is broken - when the machines reconnect > a full mirror sync takes place. This is fine over gbit crossover and if > the size of the mirror is only a few 100Gb. > > Is it feasible that when the connection to one of the mirror devices > breaks gmirror starts to log the changes to the mirror (obviously you > would need to configure up this mirror device as a 'lazy' mirror member > with a spare local device to write the changes to) - when the machines > reconnect gmirror would only then have to sync the actual changes. > > This is sort of achieves a similar result to Live Network Backup on NetBSD > (http://kerneltrap.org/node/5058). > > It could be used for laptop users mirroring their whole drive, allowing a > fast sync when they are on their local lan and should the laptop get lost > it would be possible to restore the whole machine with a simple dd. If > they were using a usb key as the device to log the changes while they were > disconnected from the network and they remember to unplug/plug this each > time they use the laptop then it could even be possible to recover the > data to the point they actually lost the machine. > > It could also be used for asynchronous mirrors over slow links, if the log > device was always written to first then the write latency for long distant > links could be removed. Im not sure if it would be possible to achieve > this using just a modified ggatec instead which has a local device used > as a write cache. Personally, I think this would be a very useful feature. This is sort of like snapshots for GEOM, which would be useful in other ways too. GEOM journaling, GEOM snapshots, and this lazy mirroring are all somewhat similar it seems. Are you proposing to write such a feature? Even if you can't code it, writing up the design/specs might help someone actually implement it. Eric From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 15:08:28 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 5ABA116A404 for ; Mon, 9 Apr 2007 15:08:28 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by mx1.freebsd.org (Postfix) with ESMTP id F3E3413C45D for ; Mon, 9 Apr 2007 15:08:27 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: by wr-out-0506.google.com with SMTP id 50so867600wra for ; Mon, 09 Apr 2007 08:08:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EflwNvC7mMn1iqv80AxiE4MmTtTkpdWbIZiIpPASEJMeFaQslch8lnc3/7wnMWEgtOUU9E0LehhZxZRwU1DOXefcZI846PHR2CV/3Lv1qz7DFl5ABgDQk+/h4BgQzY9danNln8BO5VvU054J+fm3AMmpE3am8dfTotktn6xrD8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XEoM+AFcW9Ay2vyjymBCyJk8FBRaPjccsIx2G4j35wjUk9wSh/j6IFlWu6TPopMLOl3edRnCoxO3itguYpHIFn7+XAF1ibAYakS+O2MXDjTqVbhBvTutovX7nal+/92UwC1HdOX4u1VKU6/98Tn6bYEvEt1zQYA862/RUf7Q8d8= Received: by 10.78.203.13 with SMTP id a13mr877261hug.1176131306408; Mon, 09 Apr 2007 08:08:26 -0700 (PDT) Received: by 10.78.188.9 with HTTP; Mon, 9 Apr 2007 08:08:26 -0700 (PDT) Message-ID: <70e8236f0704090808y5d305175wdc3cee5be1a26a9@mail.gmail.com> Date: Mon, 9 Apr 2007 16:08:26 +0100 From: "Joao Barros" To: "Pawel Jakub Dawidek" In-Reply-To: <20070409094319.GB76673@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070409011723.GB74547@garage.freebsd.pl> <20070409094319.GB76673@garage.freebsd.pl> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS: amd64, devd, root file system. 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, 09 Apr 2007 15:08:28 -0000 I was looking at how Solaris got support for booting off ZFS and the patch to GRUB to support it. Is it feasible for FreeBSD's boot loader? What would be the main issue: technical or licensing? On 4/9/07, Pawel Jakub Dawidek wrote: > On Mon, Apr 09, 2007 at 03:17:23AM +0200, Pawel Jakub Dawidek wrote: > > 3. It is now possible to have root file system on ZFS. You would still > > need UFS for your /boot/ file system. > > Let me explain how this suppose to work. > > You have ad0 disk. Create one slice covering entire disk: > > # fdisk -BI /dev/ad0 > > Initialize BSDlabel: > > # bsdlabel -wB /dev/ad0s1 > > Edit your label and create small (like 256MB-512MB) 'a' partition and > use the rest for 'd' partition: > > # bsdlabel -e /dev/ad0s1 > > 'd' partition will be used for ZFS: > > # zpool create tank ad0s1d > > Create UFS file system on /dev/ad0s1a and copy /boot/ directory in > there: > > # newfs /dev/ad0s1a > # mount /dev/ad0s1a /mnt/tmp > # cp -Rp /boot/* /mnt/tmp/ > > Note that there is no /boot/ directory on ad0s1a yet. This is one of the > two possibilities. You now need to create symlink: > > # cd /mnt/tmp > # ln -s . boot > > From what I checked our loader should handle symlinks just fine. > This will allow us to mount /dev/ad0s1a on /boot directory and use it as > usual. > > Another option is to: > > # cp -Rp /boot /mnt/tmp/ > > and in the future mount /dev/ad0s1a on eg. /bootdisk and create symlink: > > # ln -s bootdisk/boot /boot > > All in all, you should see your kernel when you do: > > # ls -l /mnt/tmp/boot/kernel > > Now don't forget to add zfs_load="YES" to /mnt/tmp/boot/loader.conf. > > Ok, you also need to tell your loader where your root file system is. > You can do it by adding: > > vfs.root.mountfrom="zfs:tank" > > to /mnt/tmp/boot/loader.conf or you can create /mnt/tmp/etc/fstab file > with one entry only: > > tank / zfs rw 0 0 > > On your ZFS file system, your /etc/fstab should contains the line above > and: > > /dev/ad0s1a /boot ufs rw 0 0 > > (and everything else, ie. your swap and other file systems) > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > > -- Joao Barros From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 15:34:03 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 17EC116A402; Mon, 9 Apr 2007 15:34:03 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 801C813C43E; Mon, 9 Apr 2007 15:34:02 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 33AB9487F0; Mon, 9 Apr 2007 17:33:59 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4941B45683; Mon, 9 Apr 2007 17:33:50 +0200 (CEST) Date: Mon, 9 Apr 2007 17:33:38 +0200 From: Pawel Jakub Dawidek To: Joao Barros Message-ID: <20070409153338.GH76673@garage.freebsd.pl> References: <20070409011723.GB74547@garage.freebsd.pl> <20070409094319.GB76673@garage.freebsd.pl> <70e8236f0704090808y5d305175wdc3cee5be1a26a9@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gTtJ75FAzB1T2CN6" Content-Disposition: inline In-Reply-To: <70e8236f0704090808y5d305175wdc3cee5be1a26a9@mail.gmail.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS: amd64, devd, root file system. 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, 09 Apr 2007 15:34:03 -0000 --gTtJ75FAzB1T2CN6 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2007 at 04:08:26PM +0100, Joao Barros wrote: > I was looking at how Solaris got support for booting off ZFS and the > patch to GRUB to support it. > Is it feasible for FreeBSD's boot loader? What would be the main > issue: technical or licensing? I don't know if there are licensing issues, probably yes if we would like to add ZFS support to our standard loader. The biggest problem I see is lack of motivation on my side. Really. Why someone would like to keep kernel on ZFS so much? This would be a huge amount of work, I expect, and what we get in turn? On Solaris you can only boot from a single-disk pool or from a mirrored pool. Is it really worth the effort for us? I much more prefer to spend the time working on something more useful than that and keep my small /boot/ file system protected by gmirror on UFS - with this approach there are no limitations - we can keep our root file system on compressed RAID-Z pool. Of course if someone is willing to try working on this, I'm happy to help. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --gTtJ75FAzB1T2CN6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGGlzSForvXbEpPzQRAkamAKDmaWgfF/ojSw1M5XNdZgA2GoGSVACg6zXx NuhM7BoNUiuqouW23pR84mQ= =hWRY -----END PGP SIGNATURE----- --gTtJ75FAzB1T2CN6-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 16:13:44 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 1F5EE16A402; Mon, 9 Apr 2007 16:13:44 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id 9051213C45A; Mon, 9 Apr 2007 16:13:43 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.185.1] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1HawUv3AOf-0005wK; Mon, 09 Apr 2007 18:13:42 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Mon, 9 Apr 2007 16:13:39 +0200 User-Agent: KMail/1.9.5 References: <20070406025700.GB98545@garage.freebsd.pl> <20070409010703.GA74547@garage.freebsd.pl> <200704090359.30493.max@love2party.net> In-Reply-To: <200704090359.30493.max@love2party.net> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1646430.lqxkHg5yHB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704091613.46291.max@love2party.net> X-Provags-ID: V01U2FsdGVkX184Wfal4G7n3g2rf8dhmxLG/Jz48N4qf1tXyqp fUWgTXv9jFYS5U7CX8kLcwyxvndKkPs2HUjTPHSJ5s4VM3f14Z sviLgtjt35PqBkwmARzGA== Cc: freebsd-fs@freebsd.org, Dag-Erling Sm?rgrav , Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. 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, 09 Apr 2007 16:13:44 -0000 --nextPart1646430.lqxkHg5yHB Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 09 April 2007 03:59, Max Laier wrote: > On Monday 09 April 2007 03:07, Pawel Jakub Dawidek wrote: > > On Sun, Apr 08, 2007 at 08:53:12PM +0200, Pawel Jakub Dawidek wrote: =2E.. > > > I'm quite tired of tracking such problems, because our mechanism > > > for detecting already initialized locks is too simple (based on one > > > bit), so I'd prefer to improve it, or just add bzero() to > > > mutex_init(). > > > > I just committed a fix. Now I do 13 bits check for already > > initialized locks detection instead of standard 1 bit check. Could > > you repeat your test? > > Will do tomorrow. Thanks. Confirmed to work for my testcase. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1646430.lqxkHg5yHB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGGkoaXyyEoT62BG0RAhaaAJ0U5bX66g+pXma4Dern9RkHX1R62wCeOr3f LaklXni4/XbyJW64gWguUtk= =wNGK -----END PGP SIGNATURE----- --nextPart1646430.lqxkHg5yHB-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 16:31:43 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 E30FA16A409 for ; Mon, 9 Apr 2007 16:31:43 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.177]) by mx1.freebsd.org (Postfix) with ESMTP id 49F1113C4B8 for ; Mon, 9 Apr 2007 16:31:43 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: by ik-out-1112.google.com with SMTP id c21so1211559ika for ; Mon, 09 Apr 2007 09:31:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bQ1KY1lh/R20MAvpqZkblcwIy0C7+YMQcLV5XfxyZf6OPuXjJMATKz2zRGRwqlvBUPn+V8OESa0+Ad7CseVzRoY/Ehq29X6q58emaOAscYBjVmPTvVaAzohrF+95SUcSneEhLhpylYPwCn4g6WOHAlWz61pvFAEgycsYL8UjbHQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Vo8zzIWIbaRlfxXUE98J+5zsaraRrsI2cEbc/84esSSTnn3y+I8EPnxHA0cE0jKMBkRx6JrVGXORkPlY5rKRcHPbd8XphS5j8msjHDy54jsqbXW8C7VTUEzNArdZjePJoY9OasxLNHaC1QqbJM0fWnBIseueCt7Fpxr7HskaWhM= Received: by 10.78.138.14 with SMTP id l14mr885216hud.1176136301793; Mon, 09 Apr 2007 09:31:41 -0700 (PDT) Received: by 10.78.188.9 with HTTP; Mon, 9 Apr 2007 09:31:41 -0700 (PDT) Message-ID: <70e8236f0704090931v3d62d067kfa25993da10fb331@mail.gmail.com> Date: Mon, 9 Apr 2007 17:31:41 +0100 From: "Joao Barros" To: "Pawel Jakub Dawidek" In-Reply-To: <20070409153338.GH76673@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070409011723.GB74547@garage.freebsd.pl> <20070409094319.GB76673@garage.freebsd.pl> <70e8236f0704090808y5d305175wdc3cee5be1a26a9@mail.gmail.com> <20070409153338.GH76673@garage.freebsd.pl> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS: amd64, devd, root file system. 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, 09 Apr 2007 16:31:44 -0000 I was unaware there was no support for booting off a RAID-Z in Solaris, that was my intended setup so no fun. Btw, I hold you personally responsible for my acquisition of two extra 320GB drives ;) On 4/9/07, Pawel Jakub Dawidek wrote: > On Mon, Apr 09, 2007 at 04:08:26PM +0100, Joao Barros wrote: > > I was looking at how Solaris got support for booting off ZFS and the > > patch to GRUB to support it. > > Is it feasible for FreeBSD's boot loader? What would be the main > > issue: technical or licensing? > > I don't know if there are licensing issues, probably yes if we would > like to add ZFS support to our standard loader. > > The biggest problem I see is lack of motivation on my side. Really. Why > someone would like to keep kernel on ZFS so much? This would be a huge > amount of work, I expect, and what we get in turn? On Solaris you can > only boot from a single-disk pool or from a mirrored pool. Is it really > worth the effort for us? I much more prefer to spend the time working on > something more useful than that and keep my small /boot/ file system > protected by gmirror on UFS - with this approach there are no > limitations - we can keep our root file system on compressed RAID-Z > pool. > > Of course if someone is willing to try working on this, I'm happy to > help. > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > > -- Joao Barros From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 18:28:23 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 3E41416A402; Mon, 9 Apr 2007 18:28:23 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0502A13C4C2; Mon, 9 Apr 2007 18:28:23 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-g20.free.fr (Postfix) with ESMTP id 91B9CD60515; Mon, 9 Apr 2007 19:57:50 +0200 (CEST) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 994E04356A; Mon, 9 Apr 2007 19:57:48 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 87E0F9C387; Mon, 9 Apr 2007 17:57:40 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 658FC405B; Mon, 9 Apr 2007 19:57:40 +0200 (CEST) Date: Mon, 9 Apr 2007 19:57:40 +0200 From: Jeremie Le Hen To: Pawel Jakub Dawidek Message-ID: <20070409175740.GA2102@obiwan.tataz.chchile.org> References: <20070406025700.GB98545@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070406025700.GB98545@garage.freebsd.pl> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. 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, 09 Apr 2007 18:28:23 -0000 Hi, On Fri, Apr 06, 2007 at 04:57:00AM +0200, Pawel Jakub Dawidek wrote: > I'm happy to inform that the ZFS file system is now part of the FreeBSD > operating system. ZFS is available in the HEAD branch and will be > available in FreeBSD 7.0-RELEASE as an experimental feature. Thank you very much for the work Pawel. This is great news. BTW, does anyone have preliminary performances tests ? I can't do them has I have no spare disk currently. Thank you. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 22:05:35 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 C06A416A401; Mon, 9 Apr 2007 22:05:35 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 7AE3A13C4AE; Mon, 9 Apr 2007 22:05:35 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id A4AFC2091; Tue, 10 Apr 2007 00:05:31 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 26C7E2090; Tue, 10 Apr 2007 00:05:31 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 15AD2A10AC; Tue, 10 Apr 2007 00:05:30 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "Joao Barros" References: <20070409011723.GB74547@garage.freebsd.pl> <20070409094319.GB76673@garage.freebsd.pl> <70e8236f0704090808y5d305175wdc3cee5be1a26a9@mail.gmail.com> <20070409153338.GH76673@garage.freebsd.pl> <70e8236f0704090931v3d62d067kfa25993da10fb331@mail.gmail.com> Date: Tue, 10 Apr 2007 00:05:29 +0200 In-Reply-To: <70e8236f0704090931v3d62d067kfa25993da10fb331@mail.gmail.com> (Joao Barros's message of "Mon, 9 Apr 2007 17:31:41 +0100") Message-ID: <86bqhxcifq.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: ZFS: amd64, devd, root file system. 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, 09 Apr 2007 22:05:35 -0000 "Joao Barros" writes: > Btw, I hold you personally responsible for my acquisition of two extra > 320GB drives ;) Pffft. I have 3 TB under my desk right now, half of it ZFS :) DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Mon Apr 9 23:09:29 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 5CCC616A401 for ; Mon, 9 Apr 2007 23:09:29 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.freebsd.org (Postfix) with ESMTP id 222FD13C448 for ; Mon, 9 Apr 2007 23:09:29 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from office.nux.co.uk (unknown [82.133.40.67]) by smtp.nildram.co.uk (Postfix) with ESMTP id BC8662B74D3 for ; Tue, 10 Apr 2007 00:09:27 +0100 (BST) Received: (qmail 45158 invoked by uid 2223); 9 Apr 2007 23:09:27 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Apr 2007 23:09:27 -0000 Date: Tue, 10 Apr 2007 00:09:27 +0100 (BST) From: Mike Wolman X-X-Sender: mike@nux.eros.office To: Eric Anderson In-Reply-To: <461A4CCC.8060205@freebsd.org> Message-ID: <20070409235056.R44017@nux.eros.office> References: <20070406025700.GB98545@garage.freebsd.pl> <4615F62A.5090001@FreeBSD.org> <20070406214804.GC61039@garage.freebsd.pl> <20070407001555.G87655@nux.eros.office> <461A4CCC.8060205@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: some thoughts about gmirror 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, 09 Apr 2007 23:09:29 -0000 >> Hi, >> >> Currently I am using gmirror and ggated to run a live network mirror. >> Obviously this can cause problems if the server exporting the 'backup' >> device is offline then the mirror is broken - when the machines reconnect a >> full mirror sync takes place. This is fine over gbit crossover and if the >> size of the mirror is only a few 100Gb. > > > Personally, I think this would be a very useful feature. This is sort of > like snapshots for GEOM, which would be useful in other ways too. GEOM > journaling, GEOM snapshots, and this lazy mirroring are all somewhat similar > it seems. > > Are you proposing to write such a feature? Even if you can't code it, > writing up the design/specs might help someone actually implement it. > > > Eric > My initial thoughts were for fast recovery from a non failed mirror device but realised it could be used for many other things from mobile users to remote asyncs. I had not thought of using it for snapshots but i can see where your coming from - by simply keeping the changes you could rewind to any point in time without having to actually create a snapshot(s) beforehand. I only wish my os/file system/geom knowledge was up to even specifying this, let alone my complete lack of c programming ability. However I can try to put together a specification from a system admins perspective if that is of any help? And of course i would be more than willing to test test test. Mike. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 00:54:00 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 8050716A401; Tue, 10 Apr 2007 00:54:00 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 65D7113C489; Tue, 10 Apr 2007 00:54:00 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id D6703110FB; Mon, 9 Apr 2007 19:38:38 -0500 (CDT) Date: Mon, 9 Apr 2007 19:38:37 -0500 From: Craig Boston To: freebsd-current@FreeBSD.org Message-ID: <20070410003837.GB8189@nowhere> Mail-Followup-To: Craig Boston , freebsd-current@FreeBSD.org, Pawel Jakub Dawidek , freebsd-fs@FreeBSD.org References: <20070406025700.GB98545@garage.freebsd.pl> <20070407025644.GC8831@cicely12.cicely.de> <20070407131353.GE63916@garage.freebsd.pl> <4617A3A6.60804@kasimir.com> <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> <20070410003505.GA8189@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070410003505.GA8189@nowhere> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 00:54:00 -0000 On Mon, Apr 09, 2007 at 07:35:05PM -0500, Craig Boston wrote: > 512MB RAM. So I've been testing in a VMware instance with 512MB. My > vm.kmem_size is defaulting to 169758720. Meh, wrong stat, I probably should have said that vm.kmem_size_max: 335544320 From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 00:54:00 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 89E6D16A404; Tue, 10 Apr 2007 00:54:00 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 61E3913C46C; Tue, 10 Apr 2007 00:54:00 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id C17C310F4B; Mon, 9 Apr 2007 19:35:08 -0500 (CDT) Date: Mon, 9 Apr 2007 19:35:05 -0500 From: Craig Boston To: freebsd-current@FreeBSD.org Message-ID: <20070410003505.GA8189@nowhere> Mail-Followup-To: Craig Boston , freebsd-current@FreeBSD.org, Pawel Jakub Dawidek , freebsd-fs@FreeBSD.org References: <20070406025700.GB98545@garage.freebsd.pl> <20070407025644.GC8831@cicely12.cicely.de> <20070407131353.GE63916@garage.freebsd.pl> <4617A3A6.60804@kasimir.com> <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070407212413.GK8831@cicely12.cicely.de> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 00:54:00 -0000 On Sat, Apr 07, 2007 at 11:24:14PM +0200, Bernd Walter wrote: > On Sat, Apr 07, 2007 at 09:15:17PM +0200, Pawel Jakub Dawidek wrote: > > Just committed a change. You can tune max and min ARC size via > > vfs.zfs.arc_max and vfs.zfs.arc_min tunnables. > > Thanks - I'd set c_max to 80M now and will see what happens, since > I had such a panic again with 240M kmem. Hi, just wanted to chime in that I'm experiencing the same panic with a fresh -CURRENT. I'm seriously considering trying out ZFS on my home file server (this should tell you how much I've come to trust pjd's work ;). Anyway, since it's a repurposed desktop with a crappy board, it's limited to 512MB RAM. So I've been testing in a VMware instance with 512MB. My vm.kmem_size is defaulting to 169758720. Works fine up until the point I start copying lots of files onto the ZFS partition. I tried the suggestion of reducing the tunables. After modifying the source to accept these values, I have it set to: kstat.zfs.misc.arcstats.p: 33554432 kstat.zfs.misc.arcstats.c: 67108864 kstat.zfs.misc.arcstats.c_min: 33554432 kstat.zfs.misc.arcstats.c_max: 67108864 kstat.zfs.misc.arcstats.size: 20606976 This is after a clean boot before trying anything. arcstats.size floats right at the max for quite a while before the panic happens, so I suspect something else is causing it to run out of kvm, perhaps the normal buffer cache since I'm copying from a UFS filesystem. panic: kmem_malloc(131072): kmem_map too small: 131440640 total allocated Though the backtrace (assuming I'm loading the module symbols correctly) seems to implicate zfs. #0 doadump () at pcpu.h:172 #1 0xc06bbaab in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc06bbd38 in panic ( fmt=0xc094f28c "kmem_malloc(%ld): kmem_map too small: %ld total allocated") at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0821e70 in kmem_malloc (map=0xc145408c, size=131072, flags=2) at /usr/src/sys/vm/vm_kern.c:305 #4 0xc0819d56 in page_alloc (zone=0x0, bytes=131072, pflag=0x0, wait=2) at /usr/src/sys/vm/uma_core.c:955 #5 0xc081bfcf in uma_large_malloc (size=131072, wait=2) at /usr/src/sys/vm/uma_core.c:2709 #6 0xc06b0eb1 in malloc (size=131072, mtp=0xc0bd0080, flags=2) at /usr/src/sys/kern/kern_malloc.c:364 #7 0xc0b66f67 in zfs_kmem_alloc (size=131072, kmflags=2) at /usr/src/sys/modules/zfs/../../compat/opensolaris/kern/opensolaris_kmem.c:67 #8 0xc0bb23ad in zio_buf_alloc (size=131072) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zio.c:211 #9 0xc0ba4487 in vdev_queue_io_to_issue (vq=0xc3424ee4, pending_limit=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:213 at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:312 #11 0xc0bc69fd in vdev_geom_io_done (zio=0xc4435400) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c:412 #12 0xc0b6ad19 in taskq_thread (arg=0xc2dfa0cc) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/os/taskq.c:833 #13 0xc06a54ba in fork_exit (callout=0xc0b6ac18 , arg=0xc2dfa0cc, frame=0xd62cdd38) at /usr/src/sys/kern/kern_fork.c:814 #14 0xc08a8c10 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 I haven't tried increasing kmem yet -- I'm a bit leery of devoting so much memory (presumably nonpageable, nonreclaimable) to the kernel. Admittedly I'm somewhat confused as to why ZFS needs its own special cache rather than sharing the system's, or at least only use free physical pages allocated as VM objects rather than precious kmem. But I'm no VM guru :) Craig From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 01:11:26 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 CE6C016A405; Tue, 10 Apr 2007 01:11:26 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B24BC13C459; Tue, 10 Apr 2007 01:11:26 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 75C591A4D87; Mon, 9 Apr 2007 18:11:31 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id CF98851B82; Mon, 9 Apr 2007 21:11:25 -0400 (EDT) Date: Mon, 9 Apr 2007 21:11:25 -0400 From: Kris Kennaway To: Craig Boston , freebsd-current@FreeBSD.org, Pawel Jakub Dawidek , freebsd-fs@FreeBSD.org Message-ID: <20070410011125.GB38535@xor.obsecurity.org> References: <20070406025700.GB98545@garage.freebsd.pl> <20070407025644.GC8831@cicely12.cicely.de> <20070407131353.GE63916@garage.freebsd.pl> <4617A3A6.60804@kasimir.com> <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> <20070410003505.GA8189@nowhere> <20070410003837.GB8189@nowhere> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A6N2fC+uXW/VQSAv" Content-Disposition: inline In-Reply-To: <20070410003837.GB8189@nowhere> User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 01:11:26 -0000 --A6N2fC+uXW/VQSAv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2007 at 07:38:37PM -0500, Craig Boston wrote: > On Mon, Apr 09, 2007 at 07:35:05PM -0500, Craig Boston wrote: > > 512MB RAM. So I've been testing in a VMware instance with 512MB. My > > vm.kmem_size is defaulting to 169758720. >=20 > Meh, wrong stat, I probably should have said that >=20 > vm.kmem_size_max: 335544320 Nah, you were right the first time :) Your system is defaulting to 160MB for the kmem_map, of which zfs will (by default) try to use up to 3/4. Naturally this doesn't leave much for the rest of the kernel (40MB), so you'll easily run the kernel out of memory. For now, you probably want to increase vm.kmem_size a bit to allow some more room for zfs, and set vfs.zfs.arc_max and arc_min to something more reasonable like 64*1024*1024+1 (the +1 is needed because zfs currently requires "greater than 64MB" for the arc). Kris --A6N2fC+uXW/VQSAv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGGuQ9Wry0BWjoQKURAugnAKDkyF6Tyh1x9toi9iyJNnITpQ7alACg2h74 l3NTAnIcISQTYHauSTtWo9c= =Jp9h -----END PGP SIGNATURE----- --A6N2fC+uXW/VQSAv-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 01:30:37 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 A182A16A408; Tue, 10 Apr 2007 01:30:37 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 83B2913C4C3; Tue, 10 Apr 2007 01:30:37 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id 37CE7110C5; Mon, 9 Apr 2007 20:30:37 -0500 (CDT) Date: Mon, 9 Apr 2007 20:30:35 -0500 From: Craig Boston To: Kris Kennaway Message-ID: <20070410013034.GC8189@nowhere> Mail-Followup-To: Craig Boston , Kris Kennaway , freebsd-current@FreeBSD.org, Pawel Jakub Dawidek , freebsd-fs@FreeBSD.org References: <20070407025644.GC8831@cicely12.cicely.de> <20070407131353.GE63916@garage.freebsd.pl> <4617A3A6.60804@kasimir.com> <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> <20070410003505.GA8189@nowhere> <20070410003837.GB8189@nowhere> <20070410011125.GB38535@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070410011125.GB38535@xor.obsecurity.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 01:30:37 -0000 On Mon, Apr 09, 2007 at 09:11:25PM -0400, Kris Kennaway wrote: > Nah, you were right the first time :) Your system is defaulting to > 160MB for the kmem_map, of which zfs will (by default) try to use up > to 3/4. Naturally this doesn't leave much for the rest of the kernel > (40MB), so you'll easily run the kernel out of memory. Hmm, I had already reduced the maximum arc size to 64MB though, which I figured (hoped?) would leave plenty of room. So if kmem_size is the total size and it can't grow, what is kmem_size_max? Is there a way to see a sum of total kmem allocation? Even the vm.zone breakdown seems to be gone in current so apparently my knowledge of such things is becoming obsolete :) > For now, you probably want to increase vm.kmem_size a bit to allow > some more room for zfs, and set vfs.zfs.arc_max and arc_min to > something more reasonable like 64*1024*1024+1 (the +1 is needed > because zfs currently requires "greater than 64MB" for the arc). Yeah, I found that out the hard way after wondering why it was ignoring the tunables :) I ran out of kmem_map space once with it set to 64*1024*1024+1, then I modified the source so that it would accept zfs_arc_max >= (64 << 20) instead, just in case it was a power-of-2 thing. Craig From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 01:42:37 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 C1F2D16A400; Tue, 10 Apr 2007 01:42:37 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id A4AEF13C455; Tue, 10 Apr 2007 01:42:35 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id 6B05D110C5; Mon, 9 Apr 2007 20:42:35 -0500 (CDT) Date: Mon, 9 Apr 2007 20:42:33 -0500 From: Craig Boston To: Kris Kennaway , freebsd-current@FreeBSD.org, Pawel Jakub Dawidek , freebsd-fs@FreeBSD.org Message-ID: <20070410014233.GD8189@nowhere> Mail-Followup-To: Craig Boston , Kris Kennaway , freebsd-current@FreeBSD.org, Pawel Jakub Dawidek , freebsd-fs@FreeBSD.org References: <20070407131353.GE63916@garage.freebsd.pl> <4617A3A6.60804@kasimir.com> <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> <20070410003505.GA8189@nowhere> <20070410003837.GB8189@nowhere> <20070410011125.GB38535@xor.obsecurity.org> <20070410013034.GC8189@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070410013034.GC8189@nowhere> User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 01:42:37 -0000 On Mon, Apr 09, 2007 at 08:30:35PM -0500, Craig Boston wrote: > Even the vm.zone breakdown seems to be gone in current so apparently my > knowledge of such things is becoming obsolete :) But vmstat -m still works ... solaris 145806 122884K - 15319671 16,32,64,128,256,512,1024,2048,4096 ... Whoa! That's a lot of kernel memory. Meanwhile... kstat.zfs.misc.arcstats.size: 33554944 (which is just barely above vfs.zfs.arc_min) So I don't think it's the arc cache (yeah I know that's redundant) that is the problem. Seems like something elsewhere in zfs is allocating large amounts of memory and not letting it go, and even the cache is having to shrink to its minimum size due to the memory pressure. It didn't panic this time, so when the tar finished I tried a "zfs unmount /usr/ports". This caused the "solaris" entry to drop down to about 64MB, so it's not a leak. It could just be that ZFS needs lots of memory to operate if it keeps a lot of metadata for each file in memory. The sheer # of allocations still seems excessive though. It was well over 20 million by the time the tar process exited. Craig From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 01:48:24 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 9635516A401; Tue, 10 Apr 2007 01:48:24 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7BECC13C44C; Tue, 10 Apr 2007 01:48:24 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 47BA81A4D87; Mon, 9 Apr 2007 18:48:29 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A34EB513AE; Mon, 9 Apr 2007 21:48:23 -0400 (EDT) Date: Mon, 9 Apr 2007 21:48:23 -0400 From: Kris Kennaway To: Craig Boston , Kris Kennaway , freebsd-current@FreeBSD.org, Pawel Jakub Dawidek , freebsd-fs@FreeBSD.org Message-ID: <20070410014823.GA38959@xor.obsecurity.org> References: <20070407131353.GE63916@garage.freebsd.pl> <4617A3A6.60804@kasimir.com> <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> <20070410003505.GA8189@nowhere> <20070410003837.GB8189@nowhere> <20070410011125.GB38535@xor.obsecurity.org> <20070410013034.GC8189@nowhere> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <20070410013034.GC8189@nowhere> User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 01:48:24 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2007 at 08:30:35PM -0500, Craig Boston wrote: > On Mon, Apr 09, 2007 at 09:11:25PM -0400, Kris Kennaway wrote: > > Nah, you were right the first time :) Your system is defaulting to > > 160MB for the kmem_map, of which zfs will (by default) try to use up > > to 3/4. Naturally this doesn't leave much for the rest of the kernel > > (40MB), so you'll easily run the kernel out of memory. >=20 > Hmm, I had already reduced the maximum arc size to 64MB though, which I > figured (hoped?) would leave plenty of room. >=20 > So if kmem_size is the total size and it can't grow, what is > kmem_size_max? Is there a way to see a sum of total kmem allocation? > Even the vm.zone breakdown seems to be gone in current so apparently my > knowledge of such things is becoming obsolete :) It's the cap used by the auto-sizing code, i.e. no matter how much RAM the system has it will never use more than 320MB for kmem, by default. Currently I think there is no exported way to view the amount of free space in the map, but there should be. > > For now, you probably want to increase vm.kmem_size a bit to allow > > some more room for zfs, and set vfs.zfs.arc_max and arc_min to > > something more reasonable like 64*1024*1024+1 (the +1 is needed > > because zfs currently requires "greater than 64MB" for the arc). >=20 > Yeah, I found that out the hard way after wondering why it was ignoring > the tunables :) >=20 > I ran out of kmem_map space once with it set to 64*1024*1024+1, then I > modified the source so that it would accept zfs_arc_max >=3D (64 << 20) > instead, just in case it was a power-of-2 thing. OK. Probably this is a sign that 160 - 64 =3D 96MB is not enough for your kernel, i.e. you'd also get the panics if you turned down vm.kmem_size to 96MB and didn't use zfs. Kris --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGGuznWry0BWjoQKURApB9AJ4lgiraecHeW18EQjeZEk3a+sbvQACdFXUC RSQng/cu0rDKeiciAu8DPPE= =D/pW -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 01:55:24 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 AD22C16A403; Tue, 10 Apr 2007 01:55:24 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9395C13C4BF; Tue, 10 Apr 2007 01:55:24 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 5F0D11A4D87; Mon, 9 Apr 2007 18:55:29 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B6816513F4; Mon, 9 Apr 2007 21:55:23 -0400 (EDT) Date: Mon, 9 Apr 2007 21:55:23 -0400 From: Kris Kennaway To: Craig Boston , Kris Kennaway , freebsd-current@FreeBSD.org, Pawel Jakub Dawidek , freebsd-fs@FreeBSD.org Message-ID: <20070410015523.GA39181@xor.obsecurity.org> References: <4617A3A6.60804@kasimir.com> <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> <20070410003505.GA8189@nowhere> <20070410003837.GB8189@nowhere> <20070410011125.GB38535@xor.obsecurity.org> <20070410013034.GC8189@nowhere> <20070410014233.GD8189@nowhere> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <20070410014233.GD8189@nowhere> User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 01:55:24 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2007 at 08:42:33PM -0500, Craig Boston wrote: > On Mon, Apr 09, 2007 at 08:30:35PM -0500, Craig Boston wrote: > > Even the vm.zone breakdown seems to be gone in current so apparently my > > knowledge of such things is becoming obsolete :) >=20 > But vmstat -m still works >=20 > ... >=20 > solaris 145806 122884K - 15319671 16,32,64,128,256,512,1024,2048,40= 96 > ... >=20 > Whoa! That's a lot of kernel memory. Meanwhile... >=20 > kstat.zfs.misc.arcstats.size: 33554944 > (which is just barely above vfs.zfs.arc_min) >=20 > So I don't think it's the arc cache (yeah I know that's redundant) that > is the problem. Seems like something elsewhere in zfs is allocating > large amounts of memory and not letting it go, and even the cache is > having to shrink to its minimum size due to the memory pressure. >=20 > It didn't panic this time, so when the tar finished I tried a "zfs > unmount /usr/ports". This caused the "solaris" entry to drop down to > about 64MB, so it's not a leak. It could just be that ZFS needs lots of > memory to operate if it keeps a lot of metadata for each file in memory. >=20 > The sheer # of allocations still seems excessive though. It was well > over 20 million by the time the tar process exited. That is a lifetime count of the # of operations, not the current number allocated ("InUse"). It does look like there is something else using a significant amount of memory apart from arc, but arc might at least be the major one due to its extremely greedy default allocation policy. Kris --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGGu6LWry0BWjoQKURAsvPAJ9RQY1byjCO6m2ffTfKNdcal+MHqgCfXipe L730fhNTz/IegK/hc1PK+/g= =dFbw -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 02:04:56 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 30FFA16A400; Tue, 10 Apr 2007 02:04:56 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 15AE013C45B; Tue, 10 Apr 2007 02:04:56 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id D2C0311555; Mon, 9 Apr 2007 21:04:55 -0500 (CDT) Date: Mon, 9 Apr 2007 21:04:55 -0500 From: Craig Boston To: Kris Kennaway Message-ID: <20070410020455.GA73825@nowhere> References: <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> <20070410003505.GA8189@nowhere> <20070410003837.GB8189@nowhere> <20070410011125.GB38535@xor.obsecurity.org> <20070410013034.GC8189@nowhere> <20070410014233.GD8189@nowhere> <20070410015523.GA39181@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070410015523.GA39181@xor.obsecurity.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 02:04:56 -0000 On Mon, Apr 09, 2007 at 09:55:23PM -0400, Kris Kennaway wrote: > That is a lifetime count of the # of operations, not the current > number allocated ("InUse"). Yes, perhaps I should have said "sheer number of allocations & deallocations". I was just surprised that it seems to grab and release memory much more often than anything else tracked by vmstat. > It does look like there is something else using a significant amount > of memory apart from arc, but arc might at least be the major one due > to its extremely greedy default allocation policy. I wasn't going to post again until somebody suggested trying this, but I think the name cache can be ruled out. I reduced vfs.zfs.dnlc.ncsize from ~13000 to 4096 with no appreciable drop in total memory usage. It seems to be stable with vm.kmem_size at 256MB, but the wired count has come dangerously close a few times. Craig From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 02:39:17 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 651B816A404; Tue, 10 Apr 2007 02:39:17 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id F3AAE13C487; Tue, 10 Apr 2007 02:39:16 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 41ABE45B26; Tue, 10 Apr 2007 04:39:15 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 26D744569A; Tue, 10 Apr 2007 04:39:10 +0200 (CEST) Date: Tue, 10 Apr 2007 04:38:57 +0200 From: Pawel Jakub Dawidek To: Craig Boston , Kris Kennaway , freebsd-current@FreeBSD.org, freebsd-fs@FreeBSD.org Message-ID: <20070410023857.GZ76673@garage.freebsd.pl> References: <4617A3A6.60804@kasimir.com> <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> <20070410003505.GA8189@nowhere> <20070410003837.GB8189@nowhere> <20070410011125.GB38535@xor.obsecurity.org> <20070410013034.GC8189@nowhere> <20070410014233.GD8189@nowhere> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dZHW955j1vPFHE0Q" Content-Disposition: inline In-Reply-To: <20070410014233.GD8189@nowhere> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 02:39:17 -0000 --dZHW955j1vPFHE0Q Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2007 at 08:42:33PM -0500, Craig Boston wrote: > On Mon, Apr 09, 2007 at 08:30:35PM -0500, Craig Boston wrote: > > Even the vm.zone breakdown seems to be gone in current so apparently my > > knowledge of such things is becoming obsolete :) >=20 > But vmstat -m still works >=20 > ... >=20 > solaris 145806 122884K - 15319671 16,32,64,128,256,512,1024,2048,40= 96 > ... >=20 > Whoa! That's a lot of kernel memory. Meanwhile... >=20 > kstat.zfs.misc.arcstats.size: 33554944 > (which is just barely above vfs.zfs.arc_min) >=20 > So I don't think it's the arc cache (yeah I know that's redundant) that > is the problem. Seems like something elsewhere in zfs is allocating > large amounts of memory and not letting it go, and even the cache is > having to shrink to its minimum size due to the memory pressure. ARC and ZIO are the biggest memory consumers and they are somehow connected. I just committed changes that should stabilize ZFS in this regard. Could you try them? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --dZHW955j1vPFHE0Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGGvjBForvXbEpPzQRAjGfAKCfnQAjCxkZ5vawLf9vxI++38CI8wCdGvwt uHR2Eu0WmhvO3KBsE/qkJ60= =ek/6 -----END PGP SIGNATURE----- --dZHW955j1vPFHE0Q-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 03:43:39 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 449E016A400 for ; Tue, 10 Apr 2007 03:43:39 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id EA5B913C448 for ; Tue, 10 Apr 2007 03:43:38 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id CF4FAEB153E; Tue, 10 Apr 2007 11:28:05 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id 8BHVasvZQ9xP; Tue, 10 Apr 2007 11:27:59 +0800 (CST) Received: from [10.217.12.249] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 54FF6EB08E9; Tue, 10 Apr 2007 11:27:59 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=gtCOuXs8tXSFPSQmbZt5XSaUeo8haJ7FjuS2Fd7MJQdTDO0gn4vxXOF/0sDhvPcze v2uzftluOI3J+h43ktgLg== Message-ID: <461B0438.8010602@delphij.net> Date: Tue, 10 Apr 2007 11:27:52 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Joao Barros References: <20070409011723.GB74547@garage.freebsd.pl> <20070409094319.GB76673@garage.freebsd.pl> <70e8236f0704090808y5d305175wdc3cee5be1a26a9@mail.gmail.com> In-Reply-To: <70e8236f0704090808y5d305175wdc3cee5be1a26a9@mail.gmail.com> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigB95AB24F28725FDE71AEAAD5" Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: ZFS: amd64, devd, root file system. 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, 10 Apr 2007 03:43:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB95AB24F28725FDE71AEAAD5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Joao Barros wrote: > I was looking at how Solaris got support for booting off ZFS and the > patch to GRUB to support it. > Is it feasible for FreeBSD's boot loader? What would be the main > issue: technical or licensing? I think it's about licensing, i.e. the FreeBSD loader has to be free of licenses that does not allow others to freely redistribute, at very least, it must be able to work without such code, and does not link against these code by default. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigB95AB24F28725FDE71AEAAD5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGGwQ4OfuToMruuMARCii9AJ0cM07+60RpO04ULbW41Nry2uX64wCggkZ1 Z104487f4s1r/3SDNxHzolE= =aAFn -----END PGP SIGNATURE----- --------------enigB95AB24F28725FDE71AEAAD5-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 04:04:38 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 4504416A401; Tue, 10 Apr 2007 04:04:38 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 2AA4913C455; Tue, 10 Apr 2007 04:04:34 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id 8FEAE11555; Mon, 9 Apr 2007 23:04:33 -0500 (CDT) Date: Mon, 9 Apr 2007 23:04:31 -0500 From: Craig Boston To: Pawel Jakub Dawidek Message-ID: <20070410040431.GE8189@nowhere> Mail-Followup-To: Craig Boston , Pawel Jakub Dawidek , Kris Kennaway , freebsd-current@FreeBSD.org, freebsd-fs@FreeBSD.org References: <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> <20070410003505.GA8189@nowhere> <20070410003837.GB8189@nowhere> <20070410011125.GB38535@xor.obsecurity.org> <20070410013034.GC8189@nowhere> <20070410014233.GD8189@nowhere> <20070410023857.GZ76673@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070410023857.GZ76673@garage.freebsd.pl> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Kris Kennaway Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 04:04:38 -0000 On Tue, Apr 10, 2007 at 04:38:57AM +0200, Pawel Jakub Dawidek wrote: > ARC and ZIO are the biggest memory consumers and they are somehow > connected. I just committed changes that should stabilize ZFS in this > regard. Could you try them? Hrm, well I was attempting to but it panic'd in the middle of the kernel build (/usr/src and obj are on the test zfs partition). Apparently 256MB isn't enough kmem either. I'll bump it up again and try rebuilding, and lower it back to 256 for testing. kmem_malloc(131072): kmem_map too small: 214921216 total allocated Craig From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 04:36:12 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 8462216A402; Tue, 10 Apr 2007 04:36:12 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 6A68313C45B; Tue, 10 Apr 2007 04:36:12 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id 36DAD11555; Mon, 9 Apr 2007 23:36:12 -0500 (CDT) Date: Mon, 9 Apr 2007 23:36:10 -0500 From: Craig Boston To: Pawel Jakub Dawidek Message-ID: <20070410043610.GF8189@nowhere> Mail-Followup-To: Craig Boston , Pawel Jakub Dawidek , Kris Kennaway , freebsd-current@FreeBSD.org, freebsd-fs@FreeBSD.org References: <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> <20070410003505.GA8189@nowhere> <20070410003837.GB8189@nowhere> <20070410011125.GB38535@xor.obsecurity.org> <20070410013034.GC8189@nowhere> <20070410014233.GD8189@nowhere> <20070410023857.GZ76673@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070410023857.GZ76673@garage.freebsd.pl> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Kris Kennaway Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 04:36:12 -0000 On Tue, Apr 10, 2007 at 04:38:57AM +0200, Pawel Jakub Dawidek wrote: > ARC and ZIO are the biggest memory consumers and they are somehow > connected. I just committed changes that should stabilize ZFS in this > regard. Could you try them? Preliminary results with the latest -current kernel and vm.kmem_size=268435456, disabling all my other loader.conf entries and letting it autosize: kstat.zfs.misc.arcstats.p: 15800320 kstat.zfs.misc.arcstats.c: 16777216 kstat.zfs.misc.arcstats.c_min: 16777216 kstat.zfs.misc.arcstats.c_max: 134217728 kstat.zfs.misc.arcstats.size: 18003456 solaris 43705 91788K - 4522887 16,32,64,128,256,512,1024,2048,4096 So it looks like it autosized the ARC to a 16M-128M range. I'm currently doing a buildworld and am going to try untarring the ports tree. The ARC size is tending to hover around 16-20M, probably due to memory pressure. The "solaris" group appears to be taking up about 16M less memory than it did before, which is consistent with the ARC being 16M smaller (I had changed the minimum to 32M before reverting to HEAD). I may poke around in ZIO but judging from the complexity of the code I don't have much of a chance of really understanding it anytime soon. In my defense, the machine I was planning to use this on isn't _that_ old. It's a 2Ghz P4, which should be "okay" as far as checksum calculations go. It just has a braindead motherboard that refuses to accept more than 512MB of RAM. Craig From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 05:37:10 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 9F61016A402; Tue, 10 Apr 2007 05:37:10 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp1.yandex.ru (smtp1.yandex.ru [213.180.223.87]) by mx1.freebsd.org (Postfix) with ESMTP id BE1E113C4BE; Tue, 10 Apr 2007 05:37:09 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([77.72.136.145]:23814 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S2077402AbXDJFRT (ORCPT + 1 other); Tue, 10 Apr 2007 09:17:19 +0400 X-Comment: RFC 2476 MSA function at smtp1.yandex.ru logged sender identity as: bu7cher Message-ID: <461B1DDC.8050009@yandex.ru> Date: Tue, 10 Apr 2007 09:17:16 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> In-Reply-To: <20070406025700.GB98545@garage.freebsd.pl> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 05:37:10 -0000 Pawel Jakub Dawidek wrote: > Limitations. > > Currently ZFS is only compiled as kernel module and is only available > for i386 architecture. Amd64 should be available very soon, the other > archs will come later, as we implement needed atomic operations. > > Missing functionality. > > - We don't have iSCSI target daemon in the tree, so sharing ZVOLs via > iSCSI is also not supported at this point. This should be fixed in > the future, we may also add support for sharing ZVOLs over ggate. > - There is no support for ACLs and extended attributes. > - There is no support for booting off of ZFS file system. > > Other than that, ZFS should be fully-functional. Hi, Pawel. Thanks for the great work! 1. I have an yesterday's CURRENT and I get a `kmem_map too small` panic when try to copy /usr/src to ZFS partition with enabled compression. (I have 512M of RAM) 2. I've tried snapshots. Seems that all work good. I have one question: .zfs directory should be invisible? I can `cd .zfs` and see it's content, but may be .zfs should be visible like an ufs's .snap? -- WBR, Andrey V. Elsukov From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 06:10:08 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 C5B7716A406; Tue, 10 Apr 2007 06:10:08 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B1A9D13C45D; Tue, 10 Apr 2007 06:10:08 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id B1CFF1A4D87; Mon, 9 Apr 2007 23:10:13 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A93BD5206A; Tue, 10 Apr 2007 02:10:07 -0400 (EDT) Date: Tue, 10 Apr 2007 02:10:07 -0400 From: Kris Kennaway To: "Andrey V. Elsukov" Message-ID: <20070410061006.GA42711@xor.obsecurity.org> References: <20070406025700.GB98545@garage.freebsd.pl> <461B1DDC.8050009@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <461B1DDC.8050009@yandex.ru> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@FreeBSD.org, zfs-discuss@opensolaris.org, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 06:10:08 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2007 at 09:17:16AM +0400, Andrey V. Elsukov wrote: > Pawel Jakub Dawidek wrote: > >Limitations. > > > > Currently ZFS is only compiled as kernel module and is only available > > for i386 architecture. Amd64 should be available very soon, the other > > archs will come later, as we implement needed atomic operations. > > > >Missing functionality. > > > > - We don't have iSCSI target daemon in the tree, so sharing ZVOLs via > > iSCSI is also not supported at this point. This should be fixed in > > the future, we may also add support for sharing ZVOLs over ggate. > > - There is no support for ACLs and extended attributes. > > - There is no support for booting off of ZFS file system. > > > >Other than that, ZFS should be fully-functional. >=20 > Hi, Pawel. Thanks for the great work! >=20 > 1. I have an yesterday's CURRENT and I get a `kmem_map too small` > panic when try to copy /usr/src to ZFS partition with enabled > compression. (I have 512M of RAM) See discussion in many other emails (e.g. mine). Also cvs update. > 2. I've tried snapshots. Seems that all work good. I have one > question: .zfs directory should be invisible? I can `cd .zfs` > and see it's content, but may be .zfs should be visible like > an ufs's .snap? I think this is controlled by the 'snapdir' property, see p80 of the admin guide. Kris --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGGyo+Wry0BWjoQKURAiKAAKDZKQVnbJfwDr1qoIvVKipmWmFObQCdErpo xfQ8oX3wT3ZGb8C3GasXbzw= =w9k1 -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 06:38:18 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 7A92216A406; Tue, 10 Apr 2007 06:38:18 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 664A613C46A; Tue, 10 Apr 2007 06:38:18 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 6BC571A4D87; Mon, 9 Apr 2007 23:38:23 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5553D513AE; Tue, 10 Apr 2007 02:38:17 -0400 (EDT) Date: Tue, 10 Apr 2007 02:38:17 -0400 From: Kris Kennaway To: Rong-en Fan Message-ID: <20070410063817.GA43061@xor.obsecurity.org> References: <20070406025700.GB98545@garage.freebsd.pl> <461B1DDC.8050009@yandex.ru> <20070410061006.GA42711@xor.obsecurity.org> <6eb82e0704092335h31df5be5qd7cee8f7234b1539@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: <6eb82e0704092335h31df5be5qd7cee8f7234b1539@mail.gmail.com> User-Agent: Mutt/1.4.2.2i Cc: zfs-discuss@opensolaris.org, Pawel Jakub Dawidek , freebsd-current@freebsd.org, freebsd-fs@freebsd.org, Kris Kennaway Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 06:38:18 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2007 at 02:35:25PM +0800, Rong-en Fan wrote: > >> 2. I've tried snapshots. Seems that all work good. I have one > >> question: .zfs directory should be invisible? I can `cd .zfs` > >> and see it's content, but may be .zfs should be visible like > >> an ufs's .snap? > > > >I think this is controlled by the 'snapdir' property, see p80 of the > >admin guide. >=20 > Isn't that default 'hidden' ? I thought that is what the claim was, and the question was how to make it visible :) Kris --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGGzDYWry0BWjoQKURAlQ7AJ95jNqx4QJGtXcOgAR+sqOKpRl7AwCffnV8 8E3UJpcW69UfSHNXpAyk/QY= =S7AM -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 06:52:32 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 9F2C416A401 for ; Tue, 10 Apr 2007 06:52:32 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 2058213C489 for ; Tue, 10 Apr 2007 06:52:32 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1910012ana for ; Mon, 09 Apr 2007 23:52:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PQ/j4BrnBoi0fzswkr1i3W9dbw+W4OqBxXS2HiJoaxQggD6ZGq+ky79ZUD0wgEJV1HLjgfWunlULSqVMB5aHXaBbtRer3kKF8eiL4W7h0qY2Slmvxpp/sCDDkoege3ND7Mpu4Zsc/9xV6fjU7siwTvJbmN9UbOcID2JRlLP+d8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=e+IN6WXbJQejrsXBoc5gLhd1OUyQxWgEfr/pKsA4tQaVBY1JS9kZt49jK+UV85Hlo9TLA2QIhL560T0D8xiDBr4YnyNJi1Y6azpqc70vLwqGVusyobePIBrmAqrXk3SQRWvXpwnOozUV5W/3NMAfeL+6McuLVjGhvKP+pn7ZLVE= Received: by 10.100.94.3 with SMTP id r3mr4625448anb.1176186505125; Mon, 09 Apr 2007 23:28:25 -0700 (PDT) Received: by 10.100.141.14 with HTTP; Mon, 9 Apr 2007 23:28:25 -0700 (PDT) Message-ID: <790a9fff0704092328q722de3bfnddbe78ed6b0dbe84@mail.gmail.com> Date: Tue, 10 Apr 2007 01:28:25 -0500 From: "Scot Hetzel" To: "Andrey V. Elsukov" In-Reply-To: <461B1DDC.8050009@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070406025700.GB98545@garage.freebsd.pl> <461B1DDC.8050009@yandex.ru> Cc: freebsd-fs@freebsd.org, zfs-discuss@opensolaris.org, freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 06:52:32 -0000 On 4/10/07, Andrey V. Elsukov wrote: > 2. I've tried snapshots. Seems that all work good. I have one > question: .zfs directory should be invisible? I can `cd .zfs` > and see it's content, but may be .zfs should be visible like > an ufs's .snap? > >From zfs(1M) man page: : Snapshots : File system snapshots can be accessed under the ".zfs/snapshot" direc- tory in the root of the file system. Snapshots are automatically mounted on demand and may be unmounted at regular intervals. The visi- bility of the ".zfs" directory can be controlled by the "snapdir" prop- erty. : snapdir=hidden | visible Controls whether the ".zfs" directory is hidden or visible in the root of the file system as discussed in the "Snapshots" section. The default value is "hidden". Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 07:03:15 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 CEA6616A406 for ; Tue, 10 Apr 2007 07:03:15 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 6744F13C46C for ; Tue, 10 Apr 2007 07:03:15 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so22747ugh for ; Tue, 10 Apr 2007 00:03:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EDmVq5JXMUkombvwh/AB3wWVh3LBK7vjTyGvRnH5I7zx/PquZFbiYIfxj0xqEzowErlzsID6CkZdeMlnTgtbrItD1q3syKDQPybuBXmpBkA/vBBkgucTRBLgVsl2dMu5/9nwJbme4C05vGIA1DIG6xMDD6Gq3jmbJWWZ6QwrilM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VwSa8WPufr2yUzK8cS0Fe/9wFTyal3crWB20Uw3joRsHsxu3SZLS5ajbKUhZ+DrDylJwFwkRlt4yOb4boFRTjOkq+9ndnSiGW/CjDDeUeUNyPuHE8ycO5rM4WANmulgGZviz4Mfs8VRONYwYpT+cGLyjgMYzxtW48aHA5YdnNi4= Received: by 10.82.186.5 with SMTP id j5mr8617754buf.1176186925167; Mon, 09 Apr 2007 23:35:25 -0700 (PDT) Received: by 10.82.106.12 with HTTP; Mon, 9 Apr 2007 23:35:25 -0700 (PDT) Message-ID: <6eb82e0704092335h31df5be5qd7cee8f7234b1539@mail.gmail.com> Date: Tue, 10 Apr 2007 14:35:25 +0800 From: "Rong-en Fan" To: "Kris Kennaway" In-Reply-To: <20070410061006.GA42711@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070406025700.GB98545@garage.freebsd.pl> <461B1DDC.8050009@yandex.ru> <20070410061006.GA42711@xor.obsecurity.org> Cc: freebsd-fs@freebsd.org, zfs-discuss@opensolaris.org, Pawel Jakub Dawidek , freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 07:03:15 -0000 On 4/10/07, Kris Kennaway wrote: > On Tue, Apr 10, 2007 at 09:17:16AM +0400, Andrey V. Elsukov wrote: > > Pawel Jakub Dawidek wrote: > > >Limitations. > > > > > > Currently ZFS is only compiled as kernel module and is only available > > > for i386 architecture. Amd64 should be available very soon, the other > > > archs will come later, as we implement needed atomic operations. > > > > > >Missing functionality. > > > > > > - We don't have iSCSI target daemon in the tree, so sharing ZVOLs via > > > iSCSI is also not supported at this point. This should be fixed in > > > the future, we may also add support for sharing ZVOLs over ggate. > > > - There is no support for ACLs and extended attributes. > > > - There is no support for booting off of ZFS file system. > > > > > >Other than that, ZFS should be fully-functional. > > > > Hi, Pawel. Thanks for the great work! > > > > 1. I have an yesterday's CURRENT and I get a `kmem_map too small` > > panic when try to copy /usr/src to ZFS partition with enabled > > compression. (I have 512M of RAM) > > See discussion in many other emails (e.g. mine). Also cvs update. > > > 2. I've tried snapshots. Seems that all work good. I have one > > question: .zfs directory should be invisible? I can `cd .zfs` > > and see it's content, but may be .zfs should be visible like > > an ufs's .snap? > > I think this is controlled by the 'snapdir' property, see p80 of the > admin guide. Isn't that default 'hidden' ? Regards, Rong-En Fan > > Kris > > From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 07:03:59 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 6306616A400; Tue, 10 Apr 2007 07:03:59 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp1.yandex.ru (smtp1.yandex.ru [213.180.223.87]) by mx1.freebsd.org (Postfix) with ESMTP id 4990D13C480; Tue, 10 Apr 2007 07:03:58 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([77.72.136.145]:64263 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S2077443AbXDJHDw (ORCPT + 2 others); Tue, 10 Apr 2007 11:03:52 +0400 X-Comment: RFC 2476 MSA function at smtp1.yandex.ru logged sender identity as: bu7cher Message-ID: <461B36D5.3020307@yandex.ru> Date: Tue, 10 Apr 2007 11:03:49 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Kris Kennaway References: <20070406025700.GB98545@garage.freebsd.pl> <461B1DDC.8050009@yandex.ru> <20070410061006.GA42711@xor.obsecurity.org> <6eb82e0704092335h31df5be5qd7cee8f7234b1539@mail.gmail.com> <20070410063817.GA43061@xor.obsecurity.org> In-Reply-To: <20070410063817.GA43061@xor.obsecurity.org> Content-Type: multipart/mixed; boundary="------------080008020102090408060409" Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek , zfs-discuss@opensolaris.org, freebsd-current@freebsd.org, Rong-en Fan Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 07:03:59 -0000 This is a multi-part message in MIME format. --------------080008020102090408060409 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Kris Kennaway wrote: > I thought that is what the claim was, and the question was how to make > it visible :) Yes, thanks for the answer. Now i've been locked up in the "zfs" state :) How to repeat: # zfs set snapdir=visible media/disk3/src # ls -la media/disk3/src/.zfs -- WBR, Andrey V. Elsukov --------------080008020102090408060409 Content-Type: text/plain; name="zfs-report.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="zfs-report.txt" UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 1455 1127 0 -4 0 18032 3896 zfs D+ v0 0:00,01 mc 0 1462 1457 0 -4 0 3416 1236 zfs T+ p0 0:00,00 ls -lA db> trace 1462 Tracing pid 1462 tid 100061 td 0xc29c81b0 sched_switch(c29c81b0,0,1) at sched_switch+0xc7 mi_switch(1,0) at mi_switch+0x1d4 sleepq_switch(c3404d18) at sleepq_switch+0x8a sleepq_wait(c3404d18,50,0,0,c07315e4,...) at sleepq_wait+0x36 _sleep(c3404d18,c076f340,50,c2946f6f,0,...) at _sleep+0x24d acquire(d3b2e728,80,60000,d3b2e708,d3b2e70c,...) at acquire+0x73 _lockmgr(c3404d18,3002,c3404d48,c29c81b0,c2941e7b,...) at _lockmgr+0x442 vop_stdlock(d3b2e770) at vop_stdlock+0x27 _VOP_LOCK_APV(c294abc0,d3b2e770) at _VOP_LOCK_APV+0x38 _vn_lock(c3404cc0,1002,c29c81b0,c2941e7b,c4,...) at _vn_lock+0xf8 domount(c29c81b0,c3404cc0,c2946f6f,c2ce87c0,d3b2e85c,...) at domount+0xfd zfsctl_snapdir_lookup(d3b2eacc) at zfsctl_snapdir_lookup+0x1ac VOP_LOOKUP_APV(c294adc0,d3b2eacc) at VOP_LOOKUP_APV+0x43 lookup(d3b2eb50) at lookup+0x4c0 namei(d3b2eb50) at namei+0x2d2 kern_lstat(c29c81b0,2821c268,0,d3b2ec24) at kern_lstat+0x47 lstat(c29c81b0,d3b2ed00) at lstat+0x1b syscall(d3b2ed38) at syscall+0x29e Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (190, FreeBSD ELF32, lstat), eip = 0x2818d267, esp = 0xbfbfe3fc, ebp = 0xbfbfe498 --- db> cont --------------080008020102090408060409-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 07:06:29 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 A540416A403; Tue, 10 Apr 2007 07:06:29 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9414D13C483; Tue, 10 Apr 2007 07:06:29 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id A0E661A4D87; Tue, 10 Apr 2007 00:06:34 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A60C15153C; Tue, 10 Apr 2007 03:06:28 -0400 (EDT) Date: Tue, 10 Apr 2007 03:06:28 -0400 From: Kris Kennaway To: "Andrey V. Elsukov" Message-ID: <20070410070628.GA43365@xor.obsecurity.org> References: <20070406025700.GB98545@garage.freebsd.pl> <461B1DDC.8050009@yandex.ru> <20070410061006.GA42711@xor.obsecurity.org> <6eb82e0704092335h31df5be5qd7cee8f7234b1539@mail.gmail.com> <20070410063817.GA43061@xor.obsecurity.org> <461B36D5.3020307@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <461B36D5.3020307@yandex.ru> User-Agent: Mutt/1.4.2.2i Cc: zfs-discuss@opensolaris.org, Pawel Jakub Dawidek , Rong-en Fan , freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Kris Kennaway Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 07:06:29 -0000 On Tue, Apr 10, 2007 at 11:03:49AM +0400, Andrey V. Elsukov wrote: > Kris Kennaway wrote: > >I thought that is what the claim was, and the question was how to make > >it visible :) > > Yes, thanks for the answer. Now i've been locked up in the "zfs" > state :) > > How to repeat: > # zfs set snapdir=visible media/disk3/src > # ls -la media/disk3/src/.zfs \o/ You might need to recompile with DEBUG_LOCKS and DEBUG_VFS_LOCKS and do 'show lockedvnods', but maybe this is trivially reproducible. Kris > > -- > WBR, Andrey V. Elsukov > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 0 1455 1127 0 -4 0 18032 3896 zfs D+ v0 0:00,01 mc > 0 1462 1457 0 -4 0 3416 1236 zfs T+ p0 0:00,00 ls -lA > > db> trace 1462 > Tracing pid 1462 tid 100061 td 0xc29c81b0 > sched_switch(c29c81b0,0,1) at sched_switch+0xc7 > mi_switch(1,0) at mi_switch+0x1d4 > sleepq_switch(c3404d18) at sleepq_switch+0x8a > sleepq_wait(c3404d18,50,0,0,c07315e4,...) at sleepq_wait+0x36 > _sleep(c3404d18,c076f340,50,c2946f6f,0,...) at _sleep+0x24d > acquire(d3b2e728,80,60000,d3b2e708,d3b2e70c,...) at acquire+0x73 > _lockmgr(c3404d18,3002,c3404d48,c29c81b0,c2941e7b,...) at _lockmgr+0x442 > vop_stdlock(d3b2e770) at vop_stdlock+0x27 > _VOP_LOCK_APV(c294abc0,d3b2e770) at _VOP_LOCK_APV+0x38 > _vn_lock(c3404cc0,1002,c29c81b0,c2941e7b,c4,...) at _vn_lock+0xf8 > domount(c29c81b0,c3404cc0,c2946f6f,c2ce87c0,d3b2e85c,...) at domount+0xfd > zfsctl_snapdir_lookup(d3b2eacc) at zfsctl_snapdir_lookup+0x1ac > VOP_LOOKUP_APV(c294adc0,d3b2eacc) at VOP_LOOKUP_APV+0x43 > lookup(d3b2eb50) at lookup+0x4c0 > namei(d3b2eb50) at namei+0x2d2 > kern_lstat(c29c81b0,2821c268,0,d3b2ec24) at kern_lstat+0x47 > lstat(c29c81b0,d3b2ed00) at lstat+0x1b > syscall(d3b2ed38) at syscall+0x29e > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (190, FreeBSD ELF32, lstat), eip = 0x2818d267, esp = 0xbfbfe3fc, ebp > = 0xbfbfe498 --- > db> cont > From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 08:12:37 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 0BA6A16A402; Tue, 10 Apr 2007 08:12:37 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp2.yandex.ru (smtp2.yandex.ru [213.180.200.18]) by mx1.freebsd.org (Postfix) with ESMTP id B369513C4B8; Tue, 10 Apr 2007 08:12:35 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mail.kirov.so-cdu.ru ([77.72.136.145]:1289 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S3375841AbXDJIMZ (ORCPT + 2 others); Tue, 10 Apr 2007 12:12:25 +0400 X-Comment: RFC 2476 MSA function at smtp2.yandex.ru logged sender identity as: bu7cher Message-ID: <461B46E5.5070509@yandex.ru> Date: Tue, 10 Apr 2007 12:12:21 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Kris Kennaway References: <20070406025700.GB98545@garage.freebsd.pl> <461B1DDC.8050009@yandex.ru> <20070410061006.GA42711@xor.obsecurity.org> <6eb82e0704092335h31df5be5qd7cee8f7234b1539@mail.gmail.com> <20070410063817.GA43061@xor.obsecurity.org> <461B36D5.3020307@yandex.ru> <20070410070628.GA43365@xor.obsecurity.org> In-Reply-To: <20070410070628.GA43365@xor.obsecurity.org> Content-Type: multipart/mixed; boundary="------------080400060005060508070803" Cc: freebsd-fs@freebsd.org, Rong-en Fan , zfs-discuss@opensolaris.org, freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 08:12:37 -0000 This is a multi-part message in MIME format. --------------080400060005060508070803 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Kris Kennaway wrote: > \o/ > > You might need to recompile with DEBUG_LOCKS and DEBUG_VFS_LOCKS and > do 'show lockedvnods', but maybe this is trivially reproducible. I've rollbacked and destroyed this snapshot and now don't have this problem. But i have several LOR. -- WBR, Andrey V. Elsukov --------------080400060005060508070803 Content-Type: text/plain; name="zfs-report.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="zfs-report.txt" [btr-nb butcher]# zfs list NAME USED AVAIL REFER MOUNTPOINT media 431M 28,4G 19K /media media/disk3 431M 28,4G 21K /media/disk3 media/disk3/src 431M 28,4G 428M /media/disk3/src media/disk3/src@test 2,87M - 430M - [btr-nb butcher]# zfs rollback media/disk3/src@test lock order reversal: 1st 0xc2be9154 zfs:&db->db_mtx (zfs:&db->db_mtx) @ /usr/src/sys/modules/zfs/../ ../contrib/opensolaris/uts/common/fs/zfs/dnode.c:318 2nd 0xc2c94b20 zfs:&zp->z_lock (zfs:&zp->z_lock) @ /usr/src/sys/modules/zfs/../ ../contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:73 KDB: stack backtrace: db_trace_self_wrapper(c06f8954) at db_trace_self_wrapper+0x25 kdb_backtrace(0,ffffffff,c0786648,c07864b8,c073cbac,...) at kdb_backtrace+0x29 witness_checkorder(c2c94b20,9,c294b949,49) at witness_checkorder+0x586 _sx_xlock(c2c94b20,c294b949,49,c056dc15,c07c5498,...) at _sx_xlock+0x3e znode_pageout_func(c2be9118,c2c94b10,c2be9118,d3ca8aa4,c28f5ad1,...) at znode_pa geout_func+0x1c dbuf_evict_user(c2be9230,c2be9118,c2cb4250,c2c53cb0,d3ca8ab4,...) at dbuf_evict_ user+0x31 dbuf_clear(c2be9118,c2cb42e8,d3ca8ad8,c290283a,c2be9118,...) at dbuf_clear+0x1d dbuf_evict(c2be9118,c2be9154,c2947a33,13e,3,...) at dbuf_evict+0xd dnode_destroy(c2be9230,c2c921d0,c2be92bc,d3ca8b00,c28f4a7d,...) at dnode_destroy +0xbe dnode_buf_pageout(c2be9230,c2cb6300,c2be9230,d3ca8b18,c28f5ad1,...) at dnode_buf _pageout+0x33 dbuf_evict_user(0,c2be9230,c2be926c,c2c92350,d3ca8bcc,...) at dbuf_evict_user+0x 31 dbuf_clear(c2be9230,c2c92338,0,1,9,...) at dbuf_clear+0x1d dnode_evict_dbufs(c2c921d0,1,c2cb4250,c2947717,151,...) at dnode_evict_dbufs+0x7 8 dmu_objset_evict_dbufs(c281e610,1,c2a6d048,c2c7407c,c2a6d070,...) at dmu_objset_ evict_dbufs+0xe5 zfs_umount(c2c74000,0,c2daa870) at zfs_umount+0x1b1 dounmount(c2c74000,0,c2daa870,c0568bf2,c2daa870,...) at dounmount+0x3c1 unmount(c2daa870,d3ca8d00) at unmount+0x231 syscall(d3ca8d38) at syscall+0x26a Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (22, FreeBSD ELF32, unmount), eip = 0x2811044f, esp = 0xbfbfd23c, eb p = 0xbfbfd268 --- KDB: enter: witness_checkorder [thread pid 1122 tid 100181 ] Stopped at kdb_enter+0x2b: nop db> db> db> cont lock order reversal: 1st 0xc30ca520 zfs:&dr->dt.di.dr_mtx (zfs:&dr->dt.di.dr_mtx) @ /usr/src/sys/mod ules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1865 2nd 0xc2be9bb8 zfs:&db->db_mtx (zfs:&db->db_mtx) @ /usr/src/sys/modules/zfs/../ ../contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1836 KDB: stack backtrace: db_trace_self_wrapper(c06f8954) at db_trace_self_wrapper+0x25 kdb_backtrace(0,ffffffff,c0786350,c0786648,c073cbac,...) at kdb_backtrace+0x29 witness_checkorder(c2be9bb8,9,c294715e,72c) at witness_checkorder+0x586 _sx_xlock(c2be9bb8,c294715e,72c,728,c07101b6,...) at _sx_xlock+0x3e dbuf_sync_list(c30ca538,c2ebc700,c06f7bd3,91,c294880b,...) at dbuf_sync_list+0x5 e dbuf_sync_list(c2c92b80,c2ebc700,d3c48b84,c28fe6b1,c2bacc00,...) at dbuf_sync_li st+0xde dnode_sync(c2c92ae0,c2ebc700,720,0,c2b1d400,...) at dnode_sync+0x3a8 dmu_objset_sync(c2c3de00,c2bacc00,c2ebc700,c281294c,c28bf600,...) at dmu_objset_ sync+0xf6 dsl_pool_sync(c2812800,720,0,c2868000,720,...) at dsl_pool_sync+0x6d spa_sync(c2868000,720,0,c28128ac,c294aa21,...) at spa_sync+0x33f txg_sync_thread(c2812800,d3c48d38) at txg_sync_thread+0x183 fork_exit(c291a75c,c2812800,d3c48d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xd3c48d70, ebp = 0 --- KDB: enter: witness_checkorder [thread pid 295 tid 100149 ] Stopped at kdb_enter+0x2b: nop db> cont [btr-nb butcher]# [btr-nb butcher]# zfs list NAME USED AVAIL REFER MOUNTPOINT media 431M 28,4G 19K /media media/disk3 431M 28,4G 21K /media/disk3 media/disk3/src 430M 28,4G 430M /media/disk3/src media/disk3/src@test 0 - 430M - [btr-nb butcher]# zfs destroy media/disk3/src@test lock order reversal: 1st 0xc2c3e818 zfs:&ds->ds_deadlist.bpl_lock (zfs:&ds->ds_deadlist.bpl_lock) @ /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/bplist.c:15 4 2nd 0xc2be63a0 zfs:&dn->dn_struct_rwlock (zfs:&dn->dn_struct_rwlock) @ /usr/src /sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/dnode.c:571 KDB: stack backtrace: db_trace_self_wrapper(c06f8954) at db_trace_self_wrapper+0x25 kdb_backtrace(0,ffffffff,c0786508,c0786710,c073cbac,...) at kdb_backtrace+0x29 witness_checkorder(c2be63a0,1,c2947a33,23b,c2be63a0,...) at witness_checkorder+0 x586 _sx_slock(c2be63a0,c2947a33,23b,91,c2a42000,...) at _sx_slock+0x3e dnode_hold_impl(c28bf600,22,0,1,c29456cd,...) at dnode_hold_impl+0x5b dnode_hold(c28bf600,22,0,c29456cd,d3c48a10,...) at dnode_hold+0x19 dmu_bonus_hold(c28bf618,22,0,c2c3e818,c2c3e848,...) at dmu_bonus_hold+0x20 bplist_hold(c2c3e818,c294700d,9a,0,0,...) at bplist_hold+0x27 bplist_iterate(c2c3e818,d3c48ac8,d3c48ad8,c1056788,728,...) at bplist_iterate+0x 23 dsl_dataset_destroy_sync(c2ff3200,c2945a94,c2eeb600,c29846f0,c28129a4,...) at ds l_dataset_destroy_sync+0x1f5 dsl_sync_task_group_sync(c2eead00,c2eeb600,c281294c,c28bf600,c2eeb600,...) at ds l_sync_task_group_sync+0x110 dsl_pool_sync(c2812800,7a0,0,c2868000,7a0,...) at dsl_pool_sync+0xb9 spa_sync(c2868000,7a0,0,c28128ac,c294aa21,...) at spa_sync+0x33f txg_sync_thread(c2812800,d3c48d38) at txg_sync_thread+0x183 fork_exit(c291a75c,c2812800,d3c48d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xd3c48d70, ebp = 0 --- KDB: enter: witness_checkorder [thread pid 295 tid 100149 ] Stopped at kdb_enter+0x2b: nop db> cont [btr-nb butcher]# [btr-nb butcher]# zfs snapshot media/disk3@test acquiring duplicate lock of same type: "sleepq chain" 1st sleepq chain @ /usr/src/sys/kern/subr_sleepqueue.c:229 2nd sleepq chain @ /usr/src/sys/kern/subr_sleepqueue.c:229 KDB: stack backtrace: db_trace_self_wrapper(c06f8954) at db_trace_self_wrapper+0x25 kdb_backtrace(c077f434,0,c0788c68,c0788c68,c073b578,...) at kdb_backtrace+0x29 witness_checkorder(c077d784,9,c06f93a3,e5) at witness_checkorder+0x586 _mtx_lock_spin_flags(c077d784,0,c06f93a3,e5,d3c15c34,...) at _mtx_lock_spin_flag s+0x81 sleepq_lock(c29700ec,c29700ec,d3c15c58,c0547fd8,c29700ec,...) at sleepq_lock+0x2 e _sx_xunlock_hard(c29700ec,c2a291b0,c06f674e,98) at _sx_xunlock_hard+0x7e _sx_xunlock(c29700ec,c06f674e,98,c2a291b0,d3c15ca0,...) at _sx_xunlock+0x80 unlock_sx(c29700ec,c0566c7a,c073cbac,0,c06f93a3,...) at unlock_sx+0x3d _cv_wait(c297011c,c29700ec,c2970104,c2970124,c2970148,...) at _cv_wait+0x161 taskq_thread(c29700cc,d3c15d38) at taskq_thread+0x1de fork_exit(c28e7740,c29700cc,d3c15d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xd3c15d70, ebp = 0 --- KDB: enter: witness_checkorder [thread pid 243 tid 100134 ] Stopped at kdb_enter+0x2b: nop db> cont [btr-nb butcher]# --------------080400060005060508070803-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 09:11:54 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 959CB16A400; Tue, 10 Apr 2007 09:11:54 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.freebsd.org (Postfix) with ESMTP id 352FC13C4BB; Tue, 10 Apr 2007 09:11:53 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id l3A9JwLT027089; Tue, 10 Apr 2007 11:19:58 +0200 (MEST) Message-ID: <461B54B6.60404@fer.hr> Date: Tue, 10 Apr 2007 11:11:18 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.10 (X11/20060911) MIME-Version: 1.0 Newsgroups: gmane.os.freebsd.current, gmane.os.freebsd.devel.file-systems, gmane.os.solaris.opensolaris.zfs To: Wilko Bulte References: <20070406025700.GB98545@garage.freebsd.pl> <46177881.3090509@wcborstel.com> <20070407141736.GC4058@freebie.xs4all.nl> In-Reply-To: <20070407141736.GC4058@freebie.xs4all.nl> X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig91D3EF91FDFA3344064F76AE" Cc: freebsd-fs@freebsd.org, zfs-discuss@opensolaris.org, Jorn Argelo , Pawel Jakub Dawidek , freebsd-current@freebsd.org Subject: Re: [zfs-discuss] ZFS committed to the FreeBSD base. 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, 10 Apr 2007 09:11:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig91D3EF91FDFA3344064F76AE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Wilko Bulte wrote: > On Sat, Apr 07, 2007 at 12:54:57PM +0200, Jorn Argelo wrote.. >> Rich Teer wrote: >>> This is fantastic news! At the risk of raking over ye olde arguments= , >>> as the old saying goes: "Dual licensing? We don't need no stinkeen >>> dual licensing!". :-) >>> >>> =20 >> First of all, thanks a lot for all the hard work of both the FreeBSD=20 >> developers as the ZFS developers. I can't wait to give it a go. >> >> That leads me to one question though: Why is *BSD able to bring it int= o=20 >> the OS as where Linux has licensing problems with the CDDL? AFAIK Linu= x=20 >> users can only run it in userland mode and not in kernel mode because = of=20 >> the licenses. >=20 > My guess(!) is that they do not want non-GPL-ed code in the standard ke= rnel. Sorry if I'm reiterating what someone maybe already explained, but I=20 don't see it on the lists I read: FreeBSD can include GPL'ed code due to a "technicality" (literally): As=20 long as the code is in a separate kernel module and not in the default=20 shipped GENERIC kernel, it's considered "bundled" and not a part of the=20 kernel. As soon as the user loads a GPLed kernel module, presto-changeo! = his kernel "automagically" becomes GPLed. I believe the same holds for=20 CDDL. (I have no idea how to resolve the licensing issues of a kernel=20 with both GPL and CDDL parts :) ). This is less inconvenient than it=20 seems since kernel modules can be (pre)loaded at the same time the=20 kernel loads, and so we can have a ZFS root partition, etc. The problem with DTrace in FreeBSD is twofold: 1. It's much more intertwined with the kernel. 2. Much of its usability comes from it being available in the default=20 shipped kernel - so that users can use it to troubleshoot problems "on=20 the fly" without having to recompile and install a new kernel (involves=20 rebooting). AFAIK (not involved with its development), most of dtrace can reside in=20 a kernel module but some parts need to be in the kernel proper to=20 support this mode of operation, and *this* is where the licensing comes=20 in. Just a few files (AFAIK: mostly header files!) need to be=20 dual-licensed so they can be included in the default kernel build, and=20 the rest can be in the CDDL licensed kernel module. --------------enig91D3EF91FDFA3344064F76AE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGG1S8ldnAQVacBcgRAoNyAJ4mGKdfVa7EBCjxaq+vstSfN2YxoACeMAlM K2zXWIRJqR5gI/wRUzNTASs= =AeqS -----END PGP SIGNATURE----- --------------enig91D3EF91FDFA3344064F76AE-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 09:15:08 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 63D6016A401 for ; Tue, 10 Apr 2007 09:15:08 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0C02513C45E for ; Tue, 10 Apr 2007 09:15:08 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HbCRK-0004Y6-Qn for freebsd-fs@freebsd.org; Tue, 10 Apr 2007 11:15:02 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2007 11:15:02 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2007 11:15:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Tue, 10 Apr 2007 11:11:18 +0200 Lines: 74 Message-ID: <461B54B6.60404@fer.hr> References: <20070406025700.GB98545@garage.freebsd.pl> <46177881.3090509@wcborstel.com> <20070407141736.GC4058@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig91D3EF91FDFA3344064F76AE" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.10 (X11/20060911) In-Reply-To: <20070407141736.GC4058@freebie.xs4all.nl> X-Enigmail-Version: 0.94.2.0 Sender: news Cc: freebsd-fs@freebsd.org, zfs-discuss@opensolaris.org, freebsd-current@freebsd.org Subject: Re: [zfs-discuss] ZFS committed to the FreeBSD base. 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, 10 Apr 2007 09:15:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig91D3EF91FDFA3344064F76AE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Wilko Bulte wrote: > On Sat, Apr 07, 2007 at 12:54:57PM +0200, Jorn Argelo wrote.. >> Rich Teer wrote: >>> This is fantastic news! At the risk of raking over ye olde arguments= , >>> as the old saying goes: "Dual licensing? We don't need no stinkeen >>> dual licensing!". :-) >>> >>> =20 >> First of all, thanks a lot for all the hard work of both the FreeBSD=20 >> developers as the ZFS developers. I can't wait to give it a go. >> >> That leads me to one question though: Why is *BSD able to bring it int= o=20 >> the OS as where Linux has licensing problems with the CDDL? AFAIK Linu= x=20 >> users can only run it in userland mode and not in kernel mode because = of=20 >> the licenses. >=20 > My guess(!) is that they do not want non-GPL-ed code in the standard ke= rnel. Sorry if I'm reiterating what someone maybe already explained, but I=20 don't see it on the lists I read: FreeBSD can include GPL'ed code due to a "technicality" (literally): As=20 long as the code is in a separate kernel module and not in the default=20 shipped GENERIC kernel, it's considered "bundled" and not a part of the=20 kernel. As soon as the user loads a GPLed kernel module, presto-changeo! = his kernel "automagically" becomes GPLed. I believe the same holds for=20 CDDL. (I have no idea how to resolve the licensing issues of a kernel=20 with both GPL and CDDL parts :) ). This is less inconvenient than it=20 seems since kernel modules can be (pre)loaded at the same time the=20 kernel loads, and so we can have a ZFS root partition, etc. The problem with DTrace in FreeBSD is twofold: 1. It's much more intertwined with the kernel. 2. Much of its usability comes from it being available in the default=20 shipped kernel - so that users can use it to troubleshoot problems "on=20 the fly" without having to recompile and install a new kernel (involves=20 rebooting). AFAIK (not involved with its development), most of dtrace can reside in=20 a kernel module but some parts need to be in the kernel proper to=20 support this mode of operation, and *this* is where the licensing comes=20 in. Just a few files (AFAIK: mostly header files!) need to be=20 dual-licensed so they can be included in the default kernel build, and=20 the rest can be in the CDDL licensed kernel module. --------------enig91D3EF91FDFA3344064F76AE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGG1S8ldnAQVacBcgRAoNyAJ4mGKdfVa7EBCjxaq+vstSfN2YxoACeMAlM K2zXWIRJqR5gI/wRUzNTASs= =AeqS -----END PGP SIGNATURE----- --------------enig91D3EF91FDFA3344064F76AE-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 09:37:58 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 CD85716A404; Tue, 10 Apr 2007 09:37:58 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.freebsd.org (Postfix) with ESMTP id 68F6913C4E1; Tue, 10 Apr 2007 09:37:58 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [192.168.3.57] ([172.21.151.2]) by smtp-1.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 11:25:53 +0200 Message-ID: <461B581B.3010501@dlr.de> Date: Tue, 10 Apr 2007 11:25:47 +0200 From: Hartmut Brandt User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Ivan Voras References: <20070406025700.GB98545@garage.freebsd.pl> <46177881.3090509@wcborstel.com> <20070407141736.GC4058@freebie.xs4all.nl> <461B54B6.60404@fer.hr> In-Reply-To: <461B54B6.60404@fer.hr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2007 09:25:53.0356 (UTC) FILETIME=[3C5C38C0:01C77B52] Cc: zfs-discuss@opensolaris.org, Pawel Jakub Dawidek , Jorn Argelo , freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Wilko Bulte Subject: Re: [zfs-discuss] ZFS committed to the FreeBSD base. 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, 10 Apr 2007 09:37:58 -0000 Ivan Voras wrote: > Wilko Bulte wrote: >> On Sat, Apr 07, 2007 at 12:54:57PM +0200, Jorn Argelo wrote.. >>> Rich Teer wrote: >>>> This is fantastic news! At the risk of raking over ye olde arguments, >>>> as the old saying goes: "Dual licensing? We don't need no stinkeen >>>> dual licensing!". :-) >>>> >>>> >>> First of all, thanks a lot for all the hard work of both the FreeBSD >>> developers as the ZFS developers. I can't wait to give it a go. >>> >>> That leads me to one question though: Why is *BSD able to bring it >>> into the OS as where Linux has licensing problems with the CDDL? >>> AFAIK Linux users can only run it in userland mode and not in kernel >>> mode because of the licenses. >> >> My guess(!) is that they do not want non-GPL-ed code in the standard >> kernel. > > Sorry if I'm reiterating what someone maybe already explained, but I > don't see it on the lists I read: > > FreeBSD can include GPL'ed code due to a "technicality" (literally): > As long as the code is in a separate kernel module and not in the > default shipped GENERIC kernel, it's considered "bundled" and not a > part of the kernel. As soon as the user loads a GPLed kernel module, > presto-changeo! his kernel "automagically" becomes GPLed. I believe > the same holds for CDDL. (I have no idea how to resolve the licensing > issues of a kernel with both GPL and CDDL parts :) ). This is less > inconvenient than it seems since kernel modules can be (pre)loaded at > the same I had some discussion with folks at Sun (indirectly via another guy) while they were in the process of making the CDDL: They said: Modifications to CDDL code must be under CDDL. This means if you change a CDDLed file, your changes are CDDL. If you add a line to the CDDL code that calls a function in another, new file, you're free to put that other file under any license as long as there is a compatibility the other way 'round - you probably cannot put that file under GPL, but you can put it under BSD. The new file is not a modification of the CDDLed code. harti From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 09:43:14 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 8A2D116A401 for ; Tue, 10 Apr 2007 09:43:14 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4906C13C45D for ; Tue, 10 Apr 2007 09:43:14 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HbCsN-0000db-HF for freebsd-fs@freebsd.org; Tue, 10 Apr 2007 11:42:59 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2007 11:42:59 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2007 11:42:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Tue, 10 Apr 2007 11:42:48 +0200 Lines: 35 Message-ID: References: <20070328100536.S6916@besplex.bde.org> <20070330062726.I2388@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig75FCAF2FA895EF3969DECB66" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.10 (X11/20060911) In-Reply-To: <20070330062726.I2388@besplex.bde.org> X-Enigmail-Version: 0.94.2.0 Sender: news Subject: Re: gvirstor & UFS 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, 10 Apr 2007 09:43:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig75FCAF2FA895EF3969DECB66 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Bruce Evans wrote: > Apparently it get past the media size check in g_io_check() to give > ENOSPC instead of EIO because g_io_check() only checks the virtual > size. To support virtual overcommitted media, it is necessary for > file systems to either do a physical check whenever they allocate a Ok, what about this: What would happen if I "stall" the IO ops? When I=20 get into the ENOSPC situation (which can happen only during BIO_WRITE),=20 I can add the request in an internal queue, and process it only when I=20 reliably determine that a new physical provider is added (which I can)? Would it interact badly with soft-updates timeouts? --------------enig75FCAF2FA895EF3969DECB66 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGG1wYldnAQVacBcgRAsZPAKDgzKZH9BzOuL3T6+fhK0aEMKn5fQCfThE9 IjgdqdzICFyNJg53NcMWGlw= =E+o3 -----END PGP SIGNATURE----- --------------enig75FCAF2FA895EF3969DECB66-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 13:04:03 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 597C916A404; Tue, 10 Apr 2007 13:04:03 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id D699813C45B; Tue, 10 Apr 2007 13:04:02 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id EF6BF45B26; Tue, 10 Apr 2007 15:04:00 +0200 (CEST) Received: from localhost (pjd.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 4426345684; Tue, 10 Apr 2007 15:03:54 +0200 (CEST) Date: Tue, 10 Apr 2007 15:03:46 +0200 From: Pawel Jakub Dawidek To: Alexander Nedotsukov Message-ID: <20070410130346.GD85578@garage.freebsd.pl> References: <20070406214325.GB61039@garage.freebsd.pl> <4619AE5C.7000902@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cHMo6Wbp1wrKhbfi" Content-Disposition: inline In-Reply-To: <4619AE5C.7000902@FreeBSD.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) 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=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS - quick start. 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, 10 Apr 2007 13:04:03 -0000 --cHMo6Wbp1wrKhbfi Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2007 at 12:09:16PM +0900, Alexander Nedotsukov wrote: > Pawel, >=20 > Quick question. Is it typical to ZFS to run over 100 kthreads? I see a lo= t of spa_*s in ps output. Yes, that's the Solaris default. It's starts eight spa_zio_issue and eight spa_zio_intr threads for each ZIO type and there are six of them, which gives 2*8*6=3D96 threads. We may want to reduce it for FreeBSD, but I see no reason doing so except for a nicer ps(1) output. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --cHMo6Wbp1wrKhbfi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGG4syForvXbEpPzQRArR4AJ94A2LaJV8S4U/QgUu+je93E0/eyQCguMXR aZDOHYZiwugl1Y9Pekz3nTg= =EQgw -----END PGP SIGNATURE----- --cHMo6Wbp1wrKhbfi-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 15:52:59 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 91BD116A402 for ; Tue, 10 Apr 2007 15:52:59 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.238]) by mx1.freebsd.org (Postfix) with ESMTP id 4BD5C13C459 for ; Tue, 10 Apr 2007 15:52:59 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1741498wxc for ; Tue, 10 Apr 2007 08:52:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rfrQTAaHRojeMCinY6KWppu1QAv3dS1ATcQHQEbs3CZQfJyEasagLL+NjGKL5FeqKppkAa+CJmWic/wsqTsxsk5BQmdHSccfzD8aEf+yaQMn6Vml083rc1EuzN5364sjvetAEnAm07mAkTysEMXnYfz41tXwbjSvFdtZAfENIls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=A/VhMb/K9Hz+M+Av/6KzwRtXW+O/j9i+7bRPR6rl0wtoY8Ts53VOoURqN+T53RxIRb7IWFRubBn+D1mtvyz9vXf0uEcWTRLGxptd+LTT4+NxT1whpEJdmIRiJoADJzJxVRmeC2QURsjClLQR16LUJCtQHN6dWINnYT421fEpEGA= Received: by 10.78.204.7 with SMTP id b7mr1113031hug.1176220377991; Tue, 10 Apr 2007 08:52:57 -0700 (PDT) Received: by 10.78.188.9 with HTTP; Tue, 10 Apr 2007 08:52:57 -0700 (PDT) Message-ID: <70e8236f0704100852y214dad89g1291bb525f4efc74@mail.gmail.com> Date: Tue, 10 Apr 2007 16:52:57 +0100 From: "Joao Barros" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86bqhxcifq.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20070409011723.GB74547@garage.freebsd.pl> <20070409094319.GB76673@garage.freebsd.pl> <70e8236f0704090808y5d305175wdc3cee5be1a26a9@mail.gmail.com> <20070409153338.GH76673@garage.freebsd.pl> <70e8236f0704090931v3d62d067kfa25993da10fb331@mail.gmail.com> <86bqhxcifq.fsf@dwp.des.no> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: ZFS: amd64, devd, root file system. 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, 10 Apr 2007 15:52:59 -0000 I managed to sell the 200GB boot disk so now I'm going for a 4x320GB raid-z with a gmirror partition for boot. If everything goes well I'll make up a recipe for this setup and share :) PS: DES, without checking any data, I'd say the minimum wage in Norway is 3x the Portuguese one ;) On 4/9/07, Dag-Erling Sm=F8rgrav wrote: > "Joao Barros" writes: > > Btw, I hold you personally responsible for my acquisition of two extra > > 320GB drives ;) > > Pffft. I have 3 TB under my desk right now, half of it ZFS :) > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > --=20 Joao Barros From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 17:02:26 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 CE9A016A406 for ; Tue, 10 Apr 2007 17:02:26 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8671913C4BE for ; Tue, 10 Apr 2007 17:02:26 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HbJjc-0007SV-4n for freebsd-fs@freebsd.org; Tue, 10 Apr 2007 19:02:24 +0200 Received: from 89-172-44-29.adsl.net.t-com.hr ([89.172.44.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2007 19:02:24 +0200 Received: from ivoras by 89-172-44-29.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Apr 2007 19:02:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Tue, 10 Apr 2007 19:02:04 +0200 Lines: 34 Message-ID: References: <4746DA006C148BC0FF1241C6@ganymede.hub.org> <45CCECCB7ECB612F504211F3@ganymede.hub.org> <20070408014234.GP79199@beastie.creo.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig52E8C44A99743BD0857B0707" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-44-29.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) In-Reply-To: <20070408014234.GP79199@beastie.creo.hu> X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: TDFS ... or other distributed file system technologies for FreeBSD? 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, 10 Apr 2007 17:02:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig52E8C44A99743BD0857B0707 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Csaba Henk wrote: > I didn't mean I won't maintain (keep code in sync with the rest of the > kernel, fix bugs, etc.). I just said I can't work on new features ATM. Of the new feature, file locking (flock()) is very disireable, when you get the time :) Also, do you know if file locking will work "locally", even if FUSE doesn't handle it? (By locally I mean: automagically for files that are assumed to be local to the machine / kernel). --------------enig52E8C44A99743BD0857B0707 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGG8MTldnAQVacBcgRArIBAJ4nXdvAobOUdB4OnNk7Kpe6+3FsEwCg+SBB I3JpVcj4vOhcQs4nQgLjElo= =Eyn/ -----END PGP SIGNATURE----- --------------enig52E8C44A99743BD0857B0707-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 18:03:48 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 7B06916A402; Tue, 10 Apr 2007 18:03:48 +0000 (UTC) (envelope-from peter@pean.org) Received: from mxfep04.bredband.com (mxfep04.bredband.com [195.54.107.79]) by mx1.freebsd.org (Postfix) with ESMTP id 7C87513C45E; Tue, 10 Apr 2007 18:03:45 +0000 (UTC) (envelope-from peter@pean.org) Received: from ironport2.bredband.com ([195.54.107.84] [195.54.107.84]) by mxfep01.bredband.com with ESMTP id <20070410173505.QHHO3634.mxfep01.bredband.com@ironport2.bredband.com>; Tue, 10 Apr 2007 19:35:05 +0200 Received: from c-1fda72d5.07-172-73746f44.cust.bredbandsbolaget.se (HELO [172.25.1.26]) ([213.114.218.31]) by ironport2.bredband.com with ESMTP; 10 Apr 2007 19:35:05 +0200 Message-ID: <461BCAC8.2040001@pean.org> Date: Tue, 10 Apr 2007 19:35:04 +0200 From: Peter User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070406214325.GB61039@garage.freebsd.pl> In-Reply-To: <20070406214325.GB61039@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS - quick start. 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, 10 Apr 2007 18:03:48 -0000 Pawel Jakub Dawidek skrev: >Ok, ZFS is now in the tree, what's now? Below you'll find some >instructions how to quickly make it up and running. > >First of all you need some disks. Let's assume you have three spare SCSI >disks: da0, da1, da2. > >Add a line to your /etc/rc.conf to start ZFS automatically on boot: > > # echo 'zfs_enable="YES"' >> /etc/rc.conf > >Load ZFS kernel module, for the first time by hand: > > # kldload zfs.ko > >Now, setup one pool using RAIDZ: > > # zpool create tank raidz da0 da1 da2 > >It should automatically mount /tank/ for you. > >Ok, now put /usr/ on ZFS and propose some file systems layout. I know >you probably have some files already, so we will work on /tank/usr >directory and once we ready, we will just change the mountpoint to /usr. > > # zfs create tank/usr > >Create ports/ file system and enable gzip compression on it, because >most likely we will have only text files there. On the other hand, we >don't want to compress ports/distfiles/, because we keep compressed >stuff already in-there: > > # zfs create tank/usr/ports > # zfs set compression=gzip tank/usr/ports > # zfs create tank/usr/ports/distfiles > # zfs set compression=off tank/usr/ports/distfiles > >(You do see how your life is changing, don't you?:)) > >Let's create home file system, my own home/pjd/ file system. I know we >use RAIDZ, but I want to have directory where I put extremly important >stuff, you I'll define that each block has to be stored in tree copies: > > # zfs create tank/usr/home > # zfs create tank/usr/home/pjd > # zfs create tank/usr/home/pjd/important > # zfs set copies=3 tank/usr/home/pjd/important > >I'd like to have directory with music, etc. that I NFS share. I don't >really care about this stuff and my computer is not very fast, so I'll >just turn off checksumming (this is only for example purposes! please, >benchmark before doing it, because it's most likely not worth it!): > > # zfs create tank/music > # zfs set checksum=off tank/music > # zfs set sharenfs=on tank/music > >Oh, I almost forget. Who cares about access time updates? > > # zfs set atime=off tank > >Yes, we set it only on tank and it will be automatically inherited by >others. > >Will be also good to be informed if everything is fine with our pool: > > # echo 'daily_status_zfs_enable="YES"' >> /etc/periodic.conf > >For some reason you still need UFS file system, for example you use ACLs >or extended attributes which are not yet supported by our ZFS. If so, >why not just use ZFS to provide storage? This way we gain cheap UFS >snapshots, UFS clones, etc. by simply using ZVOLs. > > # zfs create -V 10g tank/ufs > # newfs /dev/zvol/tank/ufs > # mount /dev/zvol/tank/ufs /ufs > > # zfs snapshot tank/ufs@20070406 > # mount -r /dev/zvol/tank/ufs@20070406 /ufs20070406 > > # zfs clone tank/ufs@20070406 tank/ufsok > # fsck_ffs -p /dev/zvol/tank/ufsok > # mount /dev/zvol/tank/ufsok /ufsok > >Want to encrypt your swap and still use ZFS? Nothing more trivial: > > # zfs create -V 4g tank/swap > # geli onetime -s 4096 /dev/zvol/tank/swap > # swapon /dev/zvol/tank/swap.eli > >Trying to do something risky with your home? Snapshot it first! > > # zfs snapshot tank/home/pjd@justincase > >Turns out it was more stupid than risky? Rollback your snapshot! > > # zfs rollback tank/home/pjd@justincase > # zfs destroy tank/home/pjd@justincase > >Ok, everything works, we may set tank/usr as our real /usr: > > # zfs set mountpoint=/usr tank/usr > >Don't forget to read zfs(8) and zpool(8) manual pages and SUN's ZFS >administration guide: > > http://www.opensolaris.org/os/community/zfs/docs/zfsadmin.pdf > > > I think i just did somethink stupid. Heh. I wanted to try to add some space to my pool, so i used zpool add tank da0s1eand it worked out very well. But I cant figure out how to remove it. Can I remove it? I dont want to have my external drive connected to my laptop for ever. :( zpool iostat -v tells me there is only 8MB of data on the da0s1e.. If there is a simple way to solve this problem please tell me. Thanks in advance. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 18:26:07 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 A508416A402; Tue, 10 Apr 2007 18:26:07 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 404FC13C465; Tue, 10 Apr 2007 18:26:07 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C32FB456B1; Tue, 10 Apr 2007 20:26:05 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 92E214569A; Tue, 10 Apr 2007 20:25:58 +0200 (CEST) Date: Tue, 10 Apr 2007 20:25:49 +0200 From: Pawel Jakub Dawidek To: Peter Message-ID: <20070410182549.GB90135@garage.freebsd.pl> References: <20070406214325.GB61039@garage.freebsd.pl> <461BCAC8.2040001@pean.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s/l3CgOIzMHHjg/5" Content-Disposition: inline In-Reply-To: <461BCAC8.2040001@pean.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS - quick start. 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, 10 Apr 2007 18:26:07 -0000 --s/l3CgOIzMHHjg/5 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2007 at 07:35:04PM +0200, Peter wrote: > I think i just did somethink stupid. Heh. >=20 > I wanted to try to add some space to my pool, so i used > zpool add tank da0s1eand it worked out very well. > But I cant figure out how to remove it. Can I remove it? > I dont want to have my external drive connected to my laptop for ever. :( > zpool iostat -v tells me there is only 8MB of data on the da0s1e.. >=20 > If there is a simple way to solve this problem please tell me. Unfortunately you can't remove component from zpool yet (actually you can, but only if it's a part of a mirror/raidz). All you can do is to backup your data, fix the pool and restore. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --s/l3CgOIzMHHjg/5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGG9atForvXbEpPzQRAuwCAJ9i2/zeDm7wCEnwMA2zaKrKN5cpWgCdHCHI tajpJx9ebUb6aBHi43k3wDM= =BJvz -----END PGP SIGNATURE----- --s/l3CgOIzMHHjg/5-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 18:58:22 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 50E9816A404; Tue, 10 Apr 2007 18:58:22 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3964613C484; Tue, 10 Apr 2007 18:58:22 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id DDEAA1A4D81; Tue, 10 Apr 2007 11:58:27 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 48F3F51566; Tue, 10 Apr 2007 14:58:21 -0400 (EDT) Date: Tue, 10 Apr 2007 14:58:21 -0400 From: Kris Kennaway To: "Andrey V. Elsukov" Message-ID: <20070410185821.GA72472@xor.obsecurity.org> References: <20070406025700.GB98545@garage.freebsd.pl> <461B1DDC.8050009@yandex.ru> <20070410061006.GA42711@xor.obsecurity.org> <6eb82e0704092335h31df5be5qd7cee8f7234b1539@mail.gmail.com> <20070410063817.GA43061@xor.obsecurity.org> <461B36D5.3020307@yandex.ru> <20070410070628.GA43365@xor.obsecurity.org> <461B46E5.5070509@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: <461B46E5.5070509@yandex.ru> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek , freebsd-current@freebsd.org, Rong-en Fan , Kris Kennaway Subject: Re: ZFS committed to the FreeBSD base. 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, 10 Apr 2007 18:58:22 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2007 at 12:12:21PM +0400, Andrey V. Elsukov wrote: > Kris Kennaway wrote: > >\o/ > > > >You might need to recompile with DEBUG_LOCKS and DEBUG_VFS_LOCKS and > >do 'show lockedvnods', but maybe this is trivially reproducible. >=20 > I've rollbacked and destroyed this snapshot and now don't have this > problem. But i have several LOR. Some of these are already known, at least. Also please try to recreate the deadlock. Thanks, Kris --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGG95MWry0BWjoQKURAg0mAJ0UORPKTLd+b/sG8c+xTVfREBqMcACgxkKW u8zrDBZsFZ+ij6MujCiVE80= =kxZY -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 19:41:56 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 3944F16A400 for ; Tue, 10 Apr 2007 19:41:56 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.184]) by mx1.freebsd.org (Postfix) with ESMTP id B948813C4BD for ; Tue, 10 Apr 2007 19:41:55 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by mu-out-0910.google.com with SMTP id g7so2581089muf for ; Tue, 10 Apr 2007 12:41:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=CjBJsnYvxJZJv7yRcCmfs0mBBKDFMarVlG/fejnsWIJluwOyA1ZTLuqpQ4xcAgSUuIXQllp21T/x9QIFKzX/vw4Ckf5laOU5pi12zv7yDW6l3TJ4SaQqfPC0yAyKXpMuFodg8Rpd5K+FpY3AJsq3D6LbmbaEfluaVDxftlY/Dxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=om1Tj0rDYGvkvLQf8MeUdUZfOMyXmhzifGb/TZytoDzSYUqC1yBOdXMDJ51cDyfVdlMmpbBDDQnHPYfLW+K9cr7uI4IMFWxjng4LRMSUVCgj/hjMEuEay+VlNhxf8O/19VXbzmuFvjWvWElWlEENmmEc9j/PaG8h8woYdhoPVi0= Received: by 10.82.163.13 with SMTP id l13mr4875095bue.1176234113620; Tue, 10 Apr 2007 12:41:53 -0700 (PDT) Received: from roadrunner.q.local ( [217.185.114.66]) by mx.google.com with ESMTP id u9sm6551277muf.2007.04.10.12.41.51; Tue, 10 Apr 2007 12:41:53 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.8/8.13.8) with ESMTP id l3AJfaKV004356; Tue, 10 Apr 2007 21:41:36 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.8/8.13.8/Submit) id l3AHMuYh003069; Tue, 10 Apr 2007 19:22:56 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Tue, 10 Apr 2007 19:22:56 +0200 From: Ulrich Spoerlein To: Pawel Jakub Dawidek Message-ID: <20070410172256.GA1401@roadrunner.q.local> Mail-Followup-To: Pawel Jakub Dawidek , freebsd-current@FreeBSD.org, freebsd-fs@FreeBSD.org References: <20070406214325.GB61039@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070406214325.GB61039@garage.freebsd.pl> Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS - quick start. 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, 10 Apr 2007 19:41:56 -0000 Hi Pawel, impressive stuff. Is it possible and useable to use ZFS as a GMIRROR replacement where one disk is detached most of the time? I use an external (Firewire) disk to mirror my system disk. It gets only attached once a week for synchronizing. That way, I get a consistent 1:1 mirror of the system disk. Does ZFS cope with detached drives as well? And can the detached drive function on its own? (Sometimes, I use this firewire drive as a portable disk to supplement my laptop storage). Thanks! Ulrich Spoerlein -- "The trouble with the dictionary is you have to know how the word is spelled before you can look it up to see how it is spelled." -- Will Cuppy From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 19:54:23 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 CD55716A400 for ; Tue, 10 Apr 2007 19:54:23 +0000 (UTC) (envelope-from ml.freebsd-fs@ledisez.net) Received: from ledisez.net (ledisez.net [80.247.230.138]) by mx1.freebsd.org (Postfix) with ESMTP id 6E63E13C45A for ; Tue, 10 Apr 2007 19:54:23 +0000 (UTC) (envelope-from ml.freebsd-fs@ledisez.net) Received: from webmail.ledisez.net (localhost.localdomain [80.247.230.138]) by ledisez.net (Postfix) with ESMTP id 4782945AD09 for ; Tue, 10 Apr 2007 21:54:22 +0200 (CEST) Received: from 86.71.19.20 (SquirrelMail authenticated user romain) by webmail.ledisez.net with HTTP; Tue, 10 Apr 2007 21:54:22 +0200 (CEST) Message-ID: <51823.86.71.19.20.1176234862.squirrel@webmail.ledisez.net> In-Reply-To: <60158.62.212.122.219.1175863494.squirrel@webmail.ledisez.net> References: <20070406025700.GB98545@garage.freebsd.pl> <4615D28D.8030909@wizy.org> <20070406112911.GC1251@garage.freebsd.pl> <20070406123447.GC3519@garage.freebsd.pl> <60158.62.212.122.219.1175863494.squirrel@webmail.ledisez.net> Date: Tue, 10 Apr 2007 21:54:22 +0200 (CEST) From: "Romain LE DISEZ" To: freebsd-fs@freebsd.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [zfs-discuss] ZFS committed to the FreeBSD base. 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, 10 Apr 2007 19:54:24 -0000 Hello, I'm experiencing some problems due to this operation. When the partitions table is fixed, the system run into the bug described here : http://www.freebsd.org/cgi/query-pr.cgi?pr=72896&cat= The only way to do a fresh install (or run sysinstall) after the fix is to unplugged the fixed disks. Le Ven 6 avril 2007 14:44, Romain LE DISEZ a écrit : > Hello, > > first of all, thank you for your great work. > > When i tried to read my ZFS volume created under Solaris, I had the same > error. I simply used gpte (available in ports) to erase the partition > table and create a new one with the correct value. I hadn't lost any data > and now this error message has disappear. I can continue to read these > volume under Solaris and Linux, of course. > > I can't try to read my ZFS volumes under FreeBSD because I get an error > when loading the module. "kldload zfs" return me an error about missing > files. (I will get back with the exact error later) > > One time again : great job ! > > -- > Romain LE DISEZ > 06.78.77.99.18 > http://www.ledisez.net/ > > Le Ven 6 avril 2007 14:34, Pawel Jakub Dawidek a écrit : >> On Fri, Apr 06, 2007 at 01:29:11PM +0200, Pawel Jakub Dawidek wrote: >>> On Fri, Apr 06, 2007 at 05:54:37AM +0100, Ricardo Correia wrote: >>> > I'm interested in the cross-platform portability of ZFS pools, so I >>> have >>> > one question: did you implement the Solaris ZFS whole-disk support >>> > (specifically, the creation and recognition of the EFI/GPT label)? >>> > >>> > Unfortunately some tools in Linux (parted and cfdisk) have trouble >>> > recognizing the EFI partition created by ZFS/Solaris.. >>> >>> I'm not yet setup to move disks between FreeBSD and Solaris, but my >>> first goal was to integrate it with FreeBSD's GEOM framework. >>> >>> We support cache flushing operations on any GEOM provider (disk, >>> partition, slice, anything disk-like), so bascially currently I treat >>> everything as a whole disk (because I simply can), but don't do any >>> EFI/GPT labeling. I'll try to move data from Solaris' disk to FreeBSD >>> and see what happen. >> >> First try: >> >> GEOM: ad6: corrupt or invalid GPT detected. >> GEOM: ad6: GPT rejected -- may not be recoverable. >> >> :) >> >> -- >> Pawel Jakub Dawidek http://www.wheel.pl >> pjd@FreeBSD.org http://www.FreeBSD.org >> FreeBSD committer Am I Evil? Yes, I Am! >> > > > _______________________________________________ > 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 Apr 10 20:22:48 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 360D216A402; Tue, 10 Apr 2007 20:22:48 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id CF75013C448; Tue, 10 Apr 2007 20:22:47 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 63748487F0; Tue, 10 Apr 2007 22:22:46 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 04C864569A; Tue, 10 Apr 2007 22:22:40 +0200 (CEST) Date: Tue, 10 Apr 2007 22:22:32 +0200 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org, freebsd-fs@FreeBSD.org Message-ID: <20070410202232.GE90135@garage.freebsd.pl> References: <20070406214325.GB61039@garage.freebsd.pl> <20070410172256.GA1401@roadrunner.q.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SNIs70sCzqvszXB4" Content-Disposition: inline In-Reply-To: <20070410172256.GA1401@roadrunner.q.local> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: Subject: Re: ZFS - quick start. 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, 10 Apr 2007 20:22:48 -0000 --SNIs70sCzqvszXB4 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2007 at 07:22:56PM +0200, Ulrich Spoerlein wrote: > Hi Pawel, >=20 > impressive stuff. Is it possible and useable to use ZFS as a GMIRROR > replacement where one disk is detached most of the time? >=20 > I use an external (Firewire) disk to mirror my system disk. It gets only > attached once a week for synchronizing. That way, I get a consistent > 1:1 mirror of the system disk. Yes, it is possible. The nice things about ZFS is that (because of integrated with volume manager) it will know exactly which data to synchronize, so won't be blindly synchronize entire disk. > Does ZFS cope with detached drives as well? And can the detached drive > function on its own? (Sometimes, I use this firewire drive as a > portable disk to supplement my laptop storage). I don't think that is possible, you may want to look for the answer in zfs-discuss@opensolaris.org mailing list archives. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --SNIs70sCzqvszXB4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGG/IIForvXbEpPzQRAtXNAKDZ2haQFPjXfrKhL01v4+uGwkWMhgCguPv7 pQCfB6G6ANIa+3A+zotvVfo= =YTkJ -----END PGP SIGNATURE----- --SNIs70sCzqvszXB4-- From owner-freebsd-fs@FreeBSD.ORG Wed Apr 11 08:03:42 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 E1F0016A40A for ; Wed, 11 Apr 2007 08:03:42 +0000 (UTC) (envelope-from ec@dns2.anthonyschool.org) Received: from dns2.anthonyschool.org (h158.29.102.166.ip.alltel.net [166.102.29.158]) by mx1.freebsd.org (Postfix) with ESMTP id B56E513C45D for ; Wed, 11 Apr 2007 08:03:42 +0000 (UTC) (envelope-from ec@dns2.anthonyschool.org) Received: by dns2.anthonyschool.org (Postfix, from userid 1049) id A793973FECD; Wed, 11 Apr 2007 01:44:07 -0500 (CDT) To: freebsd-fs@freebsd.org From: postcards1001 Message-Id: <20070411064407.A793973FECD@dns2.anthonyschool.org> Date: Wed, 11 Apr 2007 01:44:07 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: You've received a greeting from a family member! 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, 11 Apr 2007 08:03:43 -0000 You have just received a virtual postcard from a family member! . You can pick up your postcard at the following web address: . [1]http://www2.postcards.org/?a91-valets-cloud-31337 . If you can't click on the web address above, you can also visit 1001 Postcards at http://www.postcards.org/postcards/ and enter your pickup code, which is: a91-valets-cloud-mad . (Your postcard will be available for 60 days.) . Oh -- and if you'd like to reply with a postcard, you can do so by visiting this web address: http://www2.postcards.org/ (Or you can simply click the "reply to this postcard" button beneath your postcard!) . We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! . Regards, 1001 Postcards http://www.postcards.org/postcards/ References 1. http://80.14.64.19/~el/postcard.exe From owner-freebsd-fs@FreeBSD.ORG Wed Apr 11 08:40:53 2007 Return-Path: X-Original-To: fs@freebsd.org 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 F3DDB16A411 for ; Wed, 11 Apr 2007 08:40:52 +0000 (UTC) (envelope-from ec@dns2.anthonyschool.org) Received: from dns2.anthonyschool.org (h158.29.102.166.ip.alltel.net [166.102.29.158]) by mx1.freebsd.org (Postfix) with ESMTP id D3F0113C468 for ; Wed, 11 Apr 2007 08:40:52 +0000 (UTC) (envelope-from ec@dns2.anthonyschool.org) Received: by dns2.anthonyschool.org (Postfix, from userid 1049) id 060527427CE; Wed, 11 Apr 2007 01:46:46 -0500 (CDT) To: fs@freebsd.org From: postcards1001 Message-Id: <20070411064646.060527427CE@dns2.anthonyschool.org> Date: Wed, 11 Apr 2007 01:46:46 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: You've received a greeting from a family member! 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, 11 Apr 2007 08:40:53 -0000 You have just received a virtual postcard from a family member! . You can pick up your postcard at the following web address: . [1]http://www2.postcards.org/?a91-valets-cloud-31337 . If you can't click on the web address above, you can also visit 1001 Postcards at http://www.postcards.org/postcards/ and enter your pickup code, which is: a91-valets-cloud-mad . (Your postcard will be available for 60 days.) . Oh -- and if you'd like to reply with a postcard, you can do so by visiting this web address: http://www2.postcards.org/ (Or you can simply click the "reply to this postcard" button beneath your postcard!) . We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! . Regards, 1001 Postcards http://www.postcards.org/postcards/ References 1. http://80.14.64.19/~el/postcard.exe From owner-freebsd-fs@FreeBSD.ORG Wed Apr 11 22:17:51 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 B9C8616A404; Wed, 11 Apr 2007 22:17:51 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.freebsd.org (Postfix) with ESMTP id 80ADA13C459; Wed, 11 Apr 2007 22:17:51 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.8/8.13.1) with ESMTP id l3BLnCUS038475; Wed, 11 Apr 2007 17:49:12 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.8/8.13.1/Submit) id l3BLnBp9038474; Wed, 11 Apr 2007 17:49:11 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 11 Apr 2007 17:49:11 -0400 From: David Schultz To: "Dag-Erling =?us-ascii:iso-8859-1?Q?Sm=F8rgrav?=" Message-ID: <20070411214911.GA38351@VARK.MIT.EDU> Mail-Followup-To: "Dag-Erling =?us-ascii:iso-8859-1?Q?Sm=F8rgrav?=" , ticso@cicely.de, freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, Pawel Jakub Dawidek References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii:iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86wt0n3mxv.fsf@dwp.des.no> Cc: freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, Pawel Jakub Dawidek , ticso@cicely.de Subject: Re: ZFS committed to the FreeBSD base. 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, 11 Apr 2007 22:17:51 -0000 On Sat, Apr 07, 2007, Dag-Erling Smrgrav wrote: > Bernd Walter writes: > > On Sat, Apr 07, 2007 at 09:43:59PM +0200, Dag-Erling Smørgrav wrote: > > > ZFS is now also available on pc98 and amd64. > > Great to read - is it just atomic.S missing for the remaining > > architectures? > > Yes. Ideally, ZFS would use FreeBSD's atomic operations instead of > its own. I believe that the reason it doesn't is (at least in part) > that we don't have 64-bit atomic operations for i386. I have > unfinished patches for cleaning up the atomic operations on all > platforms; I'll dust them off and see what I can do. As I recall, Solaris 10 targets PPro and later processors, whereas FreeBSD supports everything back to a 486DX. Hence we can't assume that cmpxchg8b is available. The last time I remember this coming up, people argued that we had to do things slow way in the default kernel for compatibility. Any ideas how ZFS and GEOM are going to work out, given that ZFS is designed to be the filesystem + volume manager in one? Anyway, this looks like awesome stuff! Unfortunately, I won't have any time to play with it much in the short term, but as soon as WD sends me the replacement for my spare disk I'll at least install ZFS and see how it goes. Awesome work, once again. Thanks! From owner-freebsd-fs@FreeBSD.ORG Wed Apr 11 22:30:15 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 8208916A400; Wed, 11 Apr 2007 22:30:15 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 444C913C45B; Wed, 11 Apr 2007 22:30:15 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 375DA2090; Thu, 12 Apr 2007 00:30:09 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id B1B762081; Thu, 12 Apr 2007 00:30:08 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 9C852A1089; Thu, 12 Apr 2007 00:30:08 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: ticso@cicely.de References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> Date: Thu, 12 Apr 2007 00:30:08 +0200 In-Reply-To: <20070411214911.GA38351@VARK.MIT.EDU> (David Schultz's message of "Wed, 11 Apr 2007 17:49:11 -0400") Message-ID: <86fy764k9b.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. 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, 11 Apr 2007 22:30:15 -0000 David Schultz writes: > Any ideas how ZFS and GEOM are going to work out, given that ZFS > is designed to be the filesystem + volume manager in one? Pawel has seveal years' experience writing GEOM classes, and ZFS plays along nicely with GEOM. You can create zpools on any kind of GEOM provider, and attach any kind of GEOM consumer to zvols. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Wed Apr 11 22:51:38 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 06F4616A406; Wed, 11 Apr 2007 22:51:38 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id A580513C44C; Wed, 11 Apr 2007 22:51:37 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l3BMpYUq039139; Thu, 12 Apr 2007 00:51:34 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l3BMpPeV029660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 00:51:26 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l3BMpPkL032526; Thu, 12 Apr 2007 00:51:25 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l3BMpPOf032525; Thu, 12 Apr 2007 00:51:25 +0200 (CEST) (envelope-from ticso) Date: Thu, 12 Apr 2007 00:51:25 +0200 From: Bernd Walter To: Dag-Erling =?us-ascii?Q?=3D=3Fus-ascii=3Aiso-8859-1=3FQ=3FSm=3DF8rgrav?= =?us-ascii?B?Pz0=?= , ticso@cicely.de, freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, Pawel Jakub Dawidek Message-ID: <20070411225124.GM30772@cicely12.cicely.de> References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070411214911.GA38351@VARK.MIT.EDU> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2007 22:51:38 -0000 On Wed, Apr 11, 2007 at 05:49:11PM -0400, David Schultz wrote: > On Sat, Apr 07, 2007, Dag-Erling Smrgrav wrote: > > Bernd Walter writes: > > > On Sat, Apr 07, 2007 at 09:43:59PM +0200, Dag-Erling Smørgrav wrote: > > > > ZFS is now also available on pc98 and amd64. > > > Great to read - is it just atomic.S missing for the remaining > > > architectures? > > > > Yes. Ideally, ZFS would use FreeBSD's atomic operations instead of > > its own. I believe that the reason it doesn't is (at least in part) > > that we don't have 64-bit atomic operations for i386. I have > > unfinished patches for cleaning up the atomic operations on all > > platforms; I'll dust them off and see what I can do. I already did a good cleanup of arm atomic functions based on your work a while ago. > As I recall, Solaris 10 targets PPro and later processors, whereas > FreeBSD supports everything back to a 486DX. Hence we can't > assume that cmpxchg8b is available. The last time I remember this > coming up, people argued that we had to do things slow way in the > default kernel for compatibility. 486 support is definitively needed, but it is very unlikely that many real existing 486 system has enough RAM for ZFS. AFAIK a ELAN520 can have up to 256MB, but I doubt that one would spend so much RAM for such a system without better use for it. Not shure about 586, this is more likely. But I'm not very familar with x86 assembly, so I don't even know which CPUs have cmpxchg8b. If ZFS wouldn't be so greedy I might have used it on flash media for x86 and ARM systems, but those boards usually don't have enough RAM. > Any ideas how ZFS and GEOM are going to work out, given that ZFS > is designed to be the filesystem + volume manager in one? Although you want to use ZFS RAID functionality GEOM has still many goodies avalable, such as md, ggate, partition-parsing, encyption, etc. There are other cool points, which I've found possible lately. E.g. replace all RAIDZ drives with bigger ones, export/import the pool and you have additional storage with the same number of drives. You just need a single additional drive at the same time, which is great in case you are short on drive bays. In case you accidently added a drive you didn't want to, you can't easily remove it, but you can workaround by replacing it with another one, which is equal or bigger in size. A short time workaround in such a case until you can backup/restore or replace the wrong drive with a long standing drive, you can use sparse md-vnode devices, ggate or gconcat ones. You just have to be carefull with sparse files, since ZFS don't care about it when filling with data, but you can at least detach your USB or firewire drive and hopefully live with the situation a few days. Today I tested a 6T Volume with sparse md files. This all worked really great. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-fs@FreeBSD.ORG Wed Apr 11 23:30:23 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 8855A16A403; Wed, 11 Apr 2007 23:30:23 +0000 (UTC) (envelope-from louisk@cryptomonkeys.com) Received: from abeyance.cryptomonkeys.com (abeyance.cryptomonkeys.com [67.42.3.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2FB0E13C45D; Wed, 11 Apr 2007 23:30:23 +0000 (UTC) (envelope-from louisk@cryptomonkeys.com) Received: from localhost (dsl092-011-183.sfo1.dsl.speakeasy.net [66.92.11.183]) (authenticated bits=0) by abeyance.cryptomonkeys.com (8.13.8+Sun/8.13.8) with ESMTP id l3BNAls7005056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2007 16:11:03 -0700 (PDT) Date: Wed, 11 Apr 2007 16:10:46 -0700 From: Louis Kowolowski To: freebsd-current@freebsd.org Message-ID: <20070411231045.GC1726@cryptomonkeys.com> References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070411225124.GM30772@cicely12.cicely.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JgQwtEuHJzHdouWu" Content-Disposition: inline In-Reply-To: <20070411225124.GM30772@cicely12.cicely.de> User-Agent: TV Remote 3.2b X-Disclaimer: WARNING: May contain scarcasm! X-Header: "WARNING: POLITICALLY INCORRECT AREA All P.C. Personnel entering these premises will encounter gravely offensive behavior and opinions. (SEC4623. Ministry of political incorrection security act of 1995) RAMPANT INSENSITIVITY AUTHORIZED" X-GPG-Fingerprint: 7A77 80FD 3F4D 995E A807 A218 664D 2BEA 8024 37B6 X-GPG-Key: http://www.cryptomonkeys.com/~louisk/pgp.html Organization: Hopelessly Disorganized Cc: freebsd-fs@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. 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, 11 Apr 2007 23:30:23 -0000 --JgQwtEuHJzHdouWu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 12, 2007 at 12:51:25AM +0200, Bernd Walter wrote: =2E.. > 486 support is definitively needed, but it is very unlikely that many > real existing 486 system has enough RAM for ZFS. > AFAIK a ELAN520 can have up to 256MB, but I doubt that one would > spend so much RAM for such a system without better use for it. > Not shure about 586, this is more likely. > But I'm not very familar with x86 assembly, so I don't even know which > CPUs have cmpxchg8b. > If ZFS wouldn't be so greedy I might have used it on flash media for > x86 and ARM systems, but those boards usually don't have enough RAM. >=20 I'm some people would be interested in being able to use ZFS with boxes like Soekris for NAS (FreeNAS comes to mind) type stuff... --=20 Louis Kowolowski KE7BAX louisk@cryptomonkeys.com Cryptomonkeys: http://www.cryptomonkeys.com/~louisk Warning: Do not point laser at remaining eye! --JgQwtEuHJzHdouWu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGHWr1Zk0r6oAkN7YRAq8AAKCUObGmjzOevsjouXbK0ojv5LSDHACfZiPT USwkAsZmF9tjiUu37R+8lac= =Tx0F -----END PGP SIGNATURE----- --JgQwtEuHJzHdouWu-- From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 02:14:41 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 ED8C716A400; Thu, 12 Apr 2007 02:14:41 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 65A9913C48C; Thu, 12 Apr 2007 02:14:41 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l3C2D0PN042335; Thu, 12 Apr 2007 04:13:01 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l3C2CrnS031220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 04:12:53 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l3C2CqTe033302; Thu, 12 Apr 2007 04:12:52 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l3C2CqOv033301; Thu, 12 Apr 2007 04:12:52 +0200 (CEST) (envelope-from ticso) Date: Thu, 12 Apr 2007 04:12:52 +0200 From: Bernd Walter To: Louis Kowolowski Message-ID: <20070412021251.GP30772@cicely12.cicely.de> References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070411225124.GM30772@cicely12.cicely.de> <20070411231045.GC1726@cryptomonkeys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070411231045.GC1726@cryptomonkeys.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 02:14:42 -0000 On Wed, Apr 11, 2007 at 04:10:46PM -0700, Louis Kowolowski wrote: > On Thu, Apr 12, 2007 at 12:51:25AM +0200, Bernd Walter wrote: > ... > > 486 support is definitively needed, but it is very unlikely that many > > real existing 486 system has enough RAM for ZFS. > > AFAIK a ELAN520 can have up to 256MB, but I doubt that one would > > spend so much RAM for such a system without better use for it. > > Not shure about 586, this is more likely. > > But I'm not very familar with x86 assembly, so I don't even know which > > CPUs have cmpxchg8b. > > If ZFS wouldn't be so greedy I might have used it on flash media for > > x86 and ARM systems, but those boards usually don't have enough RAM. > > > I'm some people would be interested in being able to use ZFS with boxes like > Soekris for NAS (FreeNAS comes to mind) type stuff... I'm currently running an NFS fileserver with 384M RAM, which seems to work with some restrictions, but it is also putting pressure on the CPU, which is a 700MHz PIII and this is not only while accessing compressed data. You might be able to get it running on a 256MB 4801, but don't expect any speed wonders. The upcoming 5501 might be a good candidate if populated with much RAM. If I got the prototype picture on soekris.com right they have 512MBit chips soldered, which gives 256MB only - more than enough for most embedded use, but not with ZFS as it stands right now... That said - I don't know what the default population really will be. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 08:06:10 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 24B7416A406 for ; Thu, 12 Apr 2007 08:06:10 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 861F413C4B0 for ; Thu, 12 Apr 2007 08:06:09 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l3C7a9qD001051; Thu, 12 Apr 2007 17:36:09 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l3C7a6bW001050; Thu, 12 Apr 2007 17:36:06 +1000 (EST) (envelope-from peter) Date: Thu, 12 Apr 2007 17:36:06 +1000 From: Peter Jeremy To: Dag-Erling =?us-ascii?Q?=3D=3Fus-ascii=3Aiso-8859-1=3FQ=3FSm=3DF8rgrav?= =?us-ascii?B?Pz0=?= , ticso@cicely.de, freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, Pawel Jakub Dawidek Message-ID: <20070412073605.GB834@turion.vk2pj.dyndns.org> References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QTprm0S8XgL7H0Dt" Content-Disposition: inline In-Reply-To: <20070411214911.GA38351@VARK.MIT.EDU> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.14 (2007-02-12) Cc: Subject: Re: ZFS committed to the FreeBSD base. 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, 12 Apr 2007 08:06:10 -0000 --QTprm0S8XgL7H0Dt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Apr-11 17:49:11 -0400, David Schultz wrote: >As I recall, Solaris 10 targets PPro and later processors, whereas >FreeBSD supports everything back to a 486DX. Hence we can't >assume that cmpxchg8b is available. There's a feature bit (CPUID_CX8) that advertises the availability of cmpxchg8b (and maybe some related instructions). My pre-MMX 586 has this bit set so I presume anything later than 486 will support it. (I'm not sure about the low-end VIA, GEODE etc clones). > The last time I remember this >coming up, people argued that we had to do things slow way in the >default kernel for compatibility. I agree that GENERIC should run on lowest-common-denominator hardware (the definition of that is a subject for a different thread). GENERIC performance could be enhanced by using an indirect call for 8-byte atomic instructions and selecting between the cmpxchg8b and alternative implementation as part of the CPU startup (much like i586_bcopy). If CPU_486 is not defined, you code could inline the cmpxchg8b-based variant. --=20 Peter Jeremy --QTprm0S8XgL7H0Dt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGHeFl/opHv/APuIcRAjDaAJsG9QfBNkAk5Xvpx818Ut28xe6IFQCffK1/ mJFSlNMN0zjm0/NGbm7KL7A= =gBQ2 -----END PGP SIGNATURE----- --QTprm0S8XgL7H0Dt-- From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 08:54:23 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 92D5D16A401; Thu, 12 Apr 2007 08:54:23 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 4EA4913C45E; Thu, 12 Apr 2007 08:54:23 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 180182090; Thu, 12 Apr 2007 10:54:19 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id E39D52087; Thu, 12 Apr 2007 10:54:18 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 378C24A29; Thu, 12 Apr 2007 10:54:18 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Peter Jeremy References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070412073605.GB834@turion.vk2pj.dyndns.org> Date: Thu, 12 Apr 2007 10:54:17 +0200 In-Reply-To: <20070412073605.GB834@turion.vk2pj.dyndns.org> (Peter Jeremy's message of "Thu, 12 Apr 2007 17:36:06 +1000") Message-ID: <86ps6aht1i.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, Pawel Jakub Dawidek , ticso@cicely.de Subject: Re: ZFS committed to the FreeBSD base. 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, 12 Apr 2007 08:54:23 -0000 Peter Jeremy writes: > There's a feature bit (CPUID_CX8) that advertises the availability of > cmpxchg8b (and maybe some related instructions). My pre-MMX 586 has > this bit set so I presume anything later than 486 will support it. > (I'm not sure about the low-end VIA, GEODE etc clones). The Geode is a 486, and does not support it. The C3 however is a 586. The C3 Ezra and C3 Samuel / Samuel 2 do not have CX8. I'm not sure about the C3 Nehemiah, I don't have one running at the moment. > I agree that GENERIC should run on lowest-common-denominator hardware > (the definition of that is a subject for a different thread). GENERIC > performance could be enhanced by using an indirect call for 8-byte > atomic instructions and selecting between the cmpxchg8b and > alternative implementation as part of the CPU startup (much like > i586_bcopy). If CPU_486 is not defined, you code could inline the > cmpxchg8b-based variant. Our native atomic operations are all defined as either macros or static inline functions in machine/atomic.h, so we can easily make this choice at compile time based on a config option. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 09:39:42 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 F050B16A401; Thu, 12 Apr 2007 09:39:42 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id AD96313C448; Thu, 12 Apr 2007 09:39:42 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 87A312094; Thu, 12 Apr 2007 11:39:35 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 778872090; Thu, 12 Apr 2007 11:39:35 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 5C2EF534C; Thu, 12 Apr 2007 11:39:35 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Louis Kowolowski References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070411225124.GM30772@cicely12.cicely.de> <20070411231045.GC1726@cryptomonkeys.com> Date: Thu, 12 Apr 2007 11:39:35 +0200 In-Reply-To: <20070411231045.GC1726@cryptomonkeys.com> (Louis Kowolowski's message of "Wed, 11 Apr 2007 16:10:46 -0700") Message-ID: <86tzvmylrc.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. 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, 12 Apr 2007 09:39:43 -0000 Louis Kowolowski writes: > I'm some people would be interested in being able to use ZFS with boxes l= ike > Soekris for NAS (FreeNAS comes to mind) type stuff... I don't think a Soekris will cut the mustard. A NAS would need a large case to hold the disks anyway, so you might as well use an EPIA board; most C3 / C7 boards can take 1 GB, and they don't cost more than a Soekris. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 09:58:28 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 257DA16A40E; Thu, 12 Apr 2007 09:58:28 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 04DEC13C4C4; Thu, 12 Apr 2007 09:58:26 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (kdapat@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l3C9wIs6062539; Thu, 12 Apr 2007 11:58:23 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l3C9wHop062538; Thu, 12 Apr 2007 11:58:17 +0200 (CEST) (envelope-from olli) Date: Thu, 12 Apr 2007 11:58:17 +0200 (CEST) Message-Id: <200704120958.l3C9wHop062538@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, des@des.no, Peter Jeremy , freebsd-fs@FreeBSD.ORG, Pawel Jakub Dawidek , ticso@cicely.de In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 12 Apr 2007 11:58:23 +0200 (CEST) Cc: Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, des@des.no, Peter Jeremy , freebsd-fs@FreeBSD.ORG, Pawel Jakub Dawidek , ticso@cicely.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 09:58:28 -0000 Dag-Erling Smørgrav wrote: > Peter Jeremy wrote: > > There's a feature bit (CPUID_CX8) that advertises the availability of > > cmpxchg8b (and maybe some related instructions). My pre-MMX 586 has > > this bit set so I presume anything later than 486 will support it. > > (I'm not sure about the low-end VIA, GEODE etc clones). > > The Geode is a 486, and does not support it. No, it's a 586-class processor. But you're right in that it does not seem to support cmpxchg8b. I have an old 233 MHz Geode currently running FreeBSD 4.6 (please no comments, it's my standalone mp3 player at home and not connected to the internet so I didn't care to update it yet, but I certainly will update it when I have some time). The kernel reports: CPU: Cyrix GXm (232.74-MHz 586-class CPU) Origin = "CyrixInstead" Id = 0x540 DIR=0x8246 Stepping=8 Revision=2 There's no "Features=" line, though. Maybe the Geode does not support the cpuid at all. Whether it supports cmpxchg8b is not 100% clear, but my guess would be "no". > The C3 however is a 586. In fact it's a 686. > The C3 Ezra and C3 Samuel / Samuel 2 do not have CX8. > I'm not sure about the C3 Nehemiah, I don't have one > running at the moment. I have a 1000 MHz C3 Nehemiah which is my home file server (NFS and SMB), among other things (Squid, Apache, FW). It does not support cmpxchg8b either, according to the cpuid feature bits: CPU: VIA C3 Nehemiah+RNG+AES (1002.28-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x698 Stepping = 8 Features=0x381b83f It's currently running 6-stable, but I would very much like to update it to -current and use ZFS for the file server volumes. I hope the absence of cmpxchg8b won't make that impossible. (It has 512 MB RAM, which should be sufficient to run ZFS, right? The squid process also takes quite some memory, but I've configured it to be rather small. After all this is only a private home server. I'm not planning to use compression, but maybe encryption (GELI) for a small part of it.) > > I agree that GENERIC should run on lowest-common-denominator hardware > > (the definition of that is a subject for a different thread). GENERIC > > performance could be enhanced by using an indirect call for 8-byte > > atomic instructions and selecting between the cmpxchg8b and > > alternative implementation as part of the CPU startup (much like > > i586_bcopy). If CPU_486 is not defined, you code could inline the > > cmpxchg8b-based variant. That wouldn't work on the C3 Nehemiah, I'm afraid. CPU_486 is not defined there (in fact I only have I686_CPU in my kernel config), but it does not support cmpxchg8b according to the dmesg output above. So the CPU class alone is not sufficient to decide about the use of cmpxchg8b; you have to check the actual CPU Features bit. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++: "an octopus made by nailing extra legs onto a dog" -- Steve Taylor, 1998 From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 10:18:09 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 2E27A16A403; Thu, 12 Apr 2007 10:18:09 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 9605413C44B; Thu, 12 Apr 2007 10:18:08 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (gfelop@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l3CAI04l063407; Thu, 12 Apr 2007 12:18:06 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l3CAI0ef063406; Thu, 12 Apr 2007 12:18:00 +0200 (CEST) (envelope-from olli) Date: Thu, 12 Apr 2007 12:18:00 +0200 (CEST) Message-Id: <200704121018.l3CAI0ef063406@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, peterjeremy@optushome.com.au, des@des.no, ticso@cicely.de, freebsd-fs@FreeBSD.ORG, Pawel Jakub Dawidek In-Reply-To: <20070412073605.GB834@turion.vk2pj.dyndns.org> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 12 Apr 2007 12:18:06 +0200 (CEST) Cc: Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, peterjeremy@optushome.com.au, des@des.no, ticso@cicely.de, freebsd-fs@FreeBSD.ORG, Pawel Jakub Dawidek List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 10:18:09 -0000 Peter Jeremy wrote: > David Schultz wrote: > > As I recall, Solaris 10 targets PPro and later processors, whereas > > FreeBSD supports everything back to a 486DX. Hence we can't > > assume that cmpxchg8b is available. > > There's a feature bit (CPUID_CX8) that advertises the availability of > cmpxchg8b (and maybe some related instructions). My pre-MMX 586 has > this bit set so I presume anything later than 486 will support it. > (I'm not sure about the low-end VIA, GEODE etc clones). They don't seem to support it. I made a quick survey of the machines of mine for which I have collected dmesg outputs. The following ones don't support cmpxchg8b according to the cpuid feature bits: CPU: i486 DX2 (486-class CPU) Origin = "GenuineIntel" Id = 0x435 Stepping = 5 Features=0x3 CPU: Cyrix GXm (232.74-MHz 586-class CPU) Origin = "CyrixInstead" Id = 0x540 DIR=0x8246 Stepping=8 Revision=2 CPU: VIA C3 Nehemiah+RNG+ACE (1002.28-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x698 Stepping = 8 Features=0x381b83f And the following ones do support cmpxchg8b: CPU: Pentium/P54C (165.79-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bf CPU: Pentium II/Pentium II Xeon/Celeron (465.50-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183fbff CPU: Intel Pentium III (799.77-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383fbff CPU: AMD Athlon(tm) Processor (846.23-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff CPU: Pentium III/Pentium III Xeon/Celeron (851.93-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x387f9ff CPU: Intel(R) Celeron(R) M processor 1300MHz (1295.80-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x695 Stepping = 5 CPU: Intel(R) Pentium(R) III CPU family 1400MHz (1396.45-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383fbff Features=0xa7e9f9bf CPU: Intel(R) Pentium(R) M processor 1.60GHz (1596.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9fbff Features2=0x180 CPU: AMD Athlon(tm) XP 2500+ (1826.03-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383fbff CPU: AMD Turion(tm) 64 Mobile Technology ML-37 (1989.82-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20f42 Stepping = 2 Features=0x78bfbff Features2=0x1 CPU: AMD Athlon(tm) 64 Processor 3200+ (2000.08-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20ff2 Stepping = 2 Features=0x78bfbff Features2=0x1 CPU: AMD Athlon(tm) 64 Processor 3700+ (2199.76-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x30f72 Stepping = 2 Features=0x78bfbff Features2=0x1 CPU: AMD Athlon(tm) 64 Processor 3800+ (2399.74-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20ff2 Stepping = 2 Features=0x78bfbff Features2=0x1 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3006.83-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff So a > 10 years old pre-MMX Pentium (586-class) does support cmpxchg8b, while a 1 year old C3 Nehemia (686- class) does not. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd We're sysadmins. To us, data is a protocol-overhead. From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 11:13:48 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 1566B16A403; Thu, 12 Apr 2007 11:13:48 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id C3D0713C484; Thu, 12 Apr 2007 11:13:47 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from tirith.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by solow.pil.dk (Postfix) with ESMTP id 228321CC233; Thu, 12 Apr 2007 12:55:46 +0200 (CEST) Received: by tirith.brixandersen.dk (Postfix, from userid 1001) id 8A9F9B950; Thu, 12 Apr 2007 12:55:45 +0200 (CEST) Date: Thu, 12 Apr 2007 12:55:45 +0200 From: Henrik Brix Andersen To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20070412105545.GB84337@tirith.brixandersen.dk> Mail-Followup-To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , Peter Jeremy , freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, Pawel Jakub Dawidek , ticso@cicely.de References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070412073605.GB834@turion.vk2pj.dyndns.org> <86ps6aht1i.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <86ps6aht1i.fsf@dwp.des.no> X-PGP-Key: http://www.brixandersen.dk/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.14 (2007-02-12) Cc: freebsd-fs@FreeBSD.ORG, Peter Jeremy , freebsd-current@FreeBSD.ORG, Pawel Jakub Dawidek , ticso@cicely.de Subject: Re: ZFS committed to the FreeBSD base. 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, 12 Apr 2007 11:13:48 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 12, 2007 at 10:54:17AM +0200, Dag-Erling Sm=F8rgrav wrote: > Peter Jeremy writes: > > There's a feature bit (CPUID_CX8) that advertises the availability of > > cmpxchg8b (and maybe some related instructions). My pre-MMX 586 has > > this bit set so I presume anything later than 486 will support it. > > (I'm not sure about the low-end VIA, GEODE etc clones). >=20 > The Geode is a 486, and does not support it. The Geodes found in both my net4801-50 and net4801-60 are both i586-class CPUs with CX8 support: $ dmesg | grep -A 2 ^CPU CPU: Geode(TM) Integrated Processor by National Semi (266.65-MHz 586-class = CPU) Origin =3D "Geode by NSC" Id =3D 0x540 Stepping =3D 0 Features=3D0x808131 Regards, Brix --=20 Henrik Brix Andersen --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: GnuPG signed iD8DBQFGHhAwv+Q4flTiePgRAjshAJ9vEwNB+GGf/KY124e+rMYR58V/zQCfRxBj wBXXlN+msrXE5UG3sMU0U4w= =yJ3Y -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 16:32:45 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 E81BF16A403 for ; Thu, 12 Apr 2007 16:32:45 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 715A613C455 for ; Thu, 12 Apr 2007 16:32:45 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 93069 invoked by uid 2001); 12 Apr 2007 16:06:03 -0000 Date: Thu, 12 Apr 2007 11:06:03 -0500 From: "Rick C. Petty" To: freebsd-fs@FreeBSD.ORG Message-ID: <20070412160603.GB92079@keira.kiwi-computer.com> References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070412073605.GB834@turion.vk2pj.dyndns.org> <86ps6aht1i.fsf@dwp.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86ps6aht1i.fsf@dwp.des.no> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.ORG Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 16:32:46 -0000 On Thu, Apr 12, 2007 at 10:54:17AM +0200, Dag-Erling Sm?rgrav wrote: > > Our native atomic operations are all defined as either macros or > static inline functions in machine/atomic.h, so we can easily make > this choice at compile time based on a config option. Is there any way we could make the choice at boot time, by checking for presence of the CX8 feature? Either as something like: extern int feature_cx8; /* or MIB variable */ #define CMPXCHG8(a) (feature_cx8 ? { _asm "..." } : emulate_cmpxch8(a)) Otherwise something like ZFS which utilizes this feature a lot could check the MIB variable and set different fn ptr in its device structure, or something along those lines. Of course, that would require compiling the same code twice essentially, but it had the advantage that it would work on non-CX8 systems and that it would be fast on systems with CX8. -- Rick C. Petty From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 18:30:33 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 A1C9916A404 for ; Thu, 12 Apr 2007 18:30:33 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by mx1.freebsd.org (Postfix) with ESMTP id 526C613C455 for ; Thu, 12 Apr 2007 18:30:33 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so587973wra for ; Thu, 12 Apr 2007 11:30:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uq8AAJMp9yIxulSn5LyTDq5WLiP9DDBRK/iErQ8lmFtU1I1HeekI/qrV9WlOMHrTgy/OPcbR6QJvN3qnlub9MQzYIEbtB3jtjlqvEG1YbXWLlWZvGVKK1Dv+AX35EJctlleeuXyr8RxMtY/jI2v/tZwh/Wc5LDjy4ep+WUtrJDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KqHdSjejCzY9wQCu3mkWWbFo8bHXDmE08vygQJTJbDyzZoLxo/jQ7sLqg3y1Yg300kpabxEn+2Te3JnXfqbwUuMFdxelOs7l0yH43hd81ufLw4KNKlBog55Ayxn9nNGuFP4cP1a20ALoFZK/SBNBIsXVQw2CYXAsKbvJU7fd5h4= Received: by 10.78.151.3 with SMTP id y3mr490830hud.1176402631742; Thu, 12 Apr 2007 11:30:31 -0700 (PDT) Received: by 10.78.188.9 with HTTP; Thu, 12 Apr 2007 11:30:31 -0700 (PDT) Message-ID: <70e8236f0704121130u1262ccb6r571e18ad1a491dd3@mail.gmail.com> Date: Thu, 12 Apr 2007 19:30:31 +0100 From: "Joao Barros" To: "Pawel Jakub Dawidek" In-Reply-To: <70e8236f0704100852y214dad89g1291bb525f4efc74@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20070409011723.GB74547@garage.freebsd.pl> <20070409094319.GB76673@garage.freebsd.pl> <70e8236f0704090808y5d305175wdc3cee5be1a26a9@mail.gmail.com> <20070409153338.GH76673@garage.freebsd.pl> <70e8236f0704090931v3d62d067kfa25993da10fb331@mail.gmail.com> <86bqhxcifq.fsf@dwp.des.no> <70e8236f0704100852y214dad89g1291bb525f4efc74@mail.gmail.com> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS: amd64, devd, root file system. 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, 12 Apr 2007 18:30:33 -0000 I have a dilemma... This is my system as is: # atacontrol list ATA channel 0: Master: ad0 ATA/ATAPI revision 6 Slave: no device present ATA channel 1: Master: ad2 Serial ATA II Slave: ad3 Serial ATA II ATA channel 2: Master: ad4 Serial ATA II Slave: no device present ATA channel 3: Master: ad6 Serial ATA II Slave: no device present FreeBSD CURRENT is installed on ad0 and I fdisk'd label'd and created a /boot on ad2 (300MB ad2s1a). All is fine, boots the kernel. I created the zpool like this: # zpool create r4x320 raidz ad2s1d ad3s1d ad4 ad6 Then copied everything to the new zfs fs that will be the new root fs The aim is to disconnect the ATA ad0 thus rendering the SATA ad2 to ad0, something like this: ATA channel 0: Master: ad0 Serial ATA II Slave: ad1 Serial ATA II ATA channel 1: Master: ad2 Serial ATA II Slave: no device present ATA channel 2: Master: ad4 Serial ATA II Slave: no device present The problem is that the info in zpool.cache is diferent from the new disk order and zfs doesn't pick the volume thus no root fs. I jumped on my "let's go for anything" suit and even tried to edit zpool.cache by hand with the new disk order, sadly with no luck. If I keep the ATA ad0 attached and boot from SATA ad2, zfs picks up the zpool and FreeBSD boots, which proves it works :D Now, my real question is: without having to boot from a device that doesn't change the disk configuration is there a way to force zfs to import zpools during boot in the way that zpool import does? On 4/10/07, Joao Barros wrote: > I managed to sell the 200GB boot disk so now I'm going for a 4x320GB > raid-z with a gmirror partition for boot. > If everything goes well I'll make up a recipe for this setup and share :) > > PS: DES, without checking any data, I'd say the minimum wage in Norway > is 3x the Portuguese one ;) > > On 4/9/07, Dag-Erling Sm=F8rgrav wrote: > > "Joao Barros" writes: > > > Btw, I hold you personally responsible for my acquisition of two extr= a > > > 320GB drives ;) > > > > Pffft. I have 3 TB under my desk right now, half of it ZFS :) > > > > DES > > -- > > Dag-Erling Sm=F8rgrav - des@des.no > > > > > -- > Joao Barros > --=20 Joao Barros From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 18:52:03 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 E2FA916A402; Thu, 12 Apr 2007 18:52:03 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id C882613C48C; Thu, 12 Apr 2007 18:52:01 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id 7DAB6110A3; Thu, 12 Apr 2007 13:52:01 -0500 (CDT) Date: Thu, 12 Apr 2007 13:51:59 -0500 From: Craig Boston To: "Rick C. Petty" Message-ID: <20070412185159.GB95302@nowhere> Mail-Followup-To: Craig Boston , "Rick C. Petty" , freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070412073605.GB834@turion.vk2pj.dyndns.org> <86ps6aht1i.fsf@dwp.des.no> <20070412160603.GB92079@keira.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070412160603.GB92079@keira.kiwi-computer.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: ZFS committed to the FreeBSD base. 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, 12 Apr 2007 18:52:04 -0000 On Thu, Apr 12, 2007 at 11:06:03AM -0500, Rick C. Petty wrote: > On Thu, Apr 12, 2007 at 10:54:17AM +0200, Dag-Erling Sm?rgrav wrote: > > > > Our native atomic operations are all defined as either macros or > > static inline functions in machine/atomic.h, so we can easily make > > this choice at compile time based on a config option. > > Is there any way we could make the choice at boot time, by checking for > presence of the CX8 feature? Either as something like: > > extern int feature_cx8; /* or MIB variable */ > #define CMPXCHG8(a) (feature_cx8 ? { _asm "..." } : emulate_cmpxch8(a)) For something this low level my opinion is it's better to stay with compile time options. After all, in the above example, cmpxchg8 is a single machine instruction. How much overhead does it add to retrieve a variable from memory and check it, then jump to the correct place? Enough that it outweighs the benefit of using that instruction in the first place? For entire functions that have been optimized (bzero comes to mind) you can always either use a function pointer or overwrite the code in memory with the optimized version. The function call overhead presumably isn't that much compared to the work that the function is doing. > Otherwise something like ZFS which utilizes this feature a lot could > check the MIB variable and set different fn ptr in its device structure, > or something along those lines. Of course, that would require compiling > the same code twice essentially, but it had the advantage that it would > work on non-CX8 systems and that it would be fast on systems with CX8. I agree this makes sense for some things, but atomic operations are supposed to be as fast as possible -- preferably single machine instructions I can't think of anything short of JIT compiling the kernel that wouldn't be a high price to pay. Craig From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 19:59:48 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 B4C9416A403 for ; Thu, 12 Apr 2007 19:59:48 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 38EA113C45A for ; Thu, 12 Apr 2007 19:59:48 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 99833 invoked by uid 2001); 12 Apr 2007 19:59:47 -0000 Date: Thu, 12 Apr 2007 14:59:47 -0500 From: "Rick C. Petty" To: freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Message-ID: <20070412195947.GA96935@keira.kiwi-computer.com> References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070412073605.GB834@turion.vk2pj.dyndns.org> <86ps6aht1i.fsf@dwp.des.no> <20070412160603.GB92079@keira.kiwi-computer.com> <20070412185159.GB95302@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070412185159.GB95302@nowhere> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 19:59:48 -0000 On Thu, Apr 12, 2007 at 01:51:59PM -0500, Craig Boston wrote: > > For something this low level my opinion is it's better to stay with > compile time options. After all, in the above example, cmpxchg8 is a > single machine instruction. How much overhead does it add to retrieve a > variable from memory and check it, then jump to the correct place? > Enough that it outweighs the benefit of using that instruction in the > first place? That's why I suggested the second method (to change fn pointers in the device struct). > I agree this makes sense for some things, but atomic operations are > supposed to be as fast as possible -- preferably single machine > instructions I can't think of anything short of JIT compiling the kernel > that wouldn't be a high price to pay. The problem is that ZFS would be compiled (by default) to work for many platforms, and thus a majority of systems wouldn't get the nice optimization. That's why I think we should do something along the lines of doing a check for CX8 and changing the pointers in the vfsops and vop_vector static structures, depending upon the availability of this optimization. I guess it really depends upon how much ZFS uses it; I got the sense that it is "often". -- Rick C. Petty From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 20:43:13 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 82A8216A405; Thu, 12 Apr 2007 20:43:13 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3D7FF13C4BA; Thu, 12 Apr 2007 20:43:13 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id C90572090; Thu, 12 Apr 2007 22:43:06 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 4298B2087; Thu, 12 Apr 2007 22:43:06 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 209DC53B2; Thu, 12 Apr 2007 22:43:05 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Craig Boston References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070412073605.GB834@turion.vk2pj.dyndns.org> <86ps6aht1i.fsf@dwp.des.no> <20070412160603.GB92079@keira.kiwi-computer.com> <20070412185159.GB95302@nowhere> Date: Thu, 12 Apr 2007 22:43:05 +0200 In-Reply-To: <20070412185159.GB95302@nowhere> (Craig Boston's message of "Thu, 12 Apr 2007 13:51:59 -0500") Message-ID: <86slb5e33a.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@FreeBSD.ORG, "Rick C. Petty" , freebsd-current@FreeBSD.ORG Subject: Re: ZFS committed to the FreeBSD base. 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, 12 Apr 2007 20:43:13 -0000 Craig Boston writes: > On Thu, Apr 12, 2007 at 11:06:03AM -0500, Rick C. Petty wrote: > > Is there any way we could make the choice at boot time, by checking for > > presence of the CX8 feature? Either as something like: > > > > extern int feature_cx8; /* or MIB variable */ > > #define CMPXCHG8(a) (feature_cx8 ? { _asm "..." } : emulate_cmpxch8(a)) > For something this low level my opinion is it's better to stay with > compile time options. After all, in the above example, cmpxchg8 is a > single machine instruction. How much overhead does it add to retrieve a > variable from memory and check it, then jump to the correct place? > Enough that it outweighs the benefit of using that instruction in the > first place? I don't think it matters. Contrary to popular belief, atomic operations are *expensive*. In the best case, on a UP machine, they stall the pipeline. In the worst case, on an SMP machine, they stall the entire memory bus. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 20:50:10 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 2797316A59C; Thu, 12 Apr 2007 20:50:09 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 86E4D13C455; Thu, 12 Apr 2007 20:50:09 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id C990A2094; Thu, 12 Apr 2007 22:50:05 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id B59A02091; Thu, 12 Apr 2007 22:50:05 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 9B4D653B5; Thu, 12 Apr 2007 22:50:05 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "Joao Barros" References: <20070409011723.GB74547@garage.freebsd.pl> <20070409094319.GB76673@garage.freebsd.pl> <70e8236f0704090808y5d305175wdc3cee5be1a26a9@mail.gmail.com> <20070409153338.GH76673@garage.freebsd.pl> <70e8236f0704090931v3d62d067kfa25993da10fb331@mail.gmail.com> <86bqhxcifq.fsf@dwp.des.no> <70e8236f0704100852y214dad89g1291bb525f4efc74@mail.gmail.com> <70e8236f0704121130u1262ccb6r571e18ad1a491dd3@mail.gmail.com> Date: Thu, 12 Apr 2007 22:50:05 +0200 In-Reply-To: <70e8236f0704121130u1262ccb6r571e18ad1a491dd3@mail.gmail.com> (Joao Barros's message of "Thu, 12 Apr 2007 19:30:31 +0100") Message-ID: <86odlte2rm.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: ZFS: amd64, devd, root file system. 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, 12 Apr 2007 20:50:10 -0000 "Joao Barros" writes: > I have a dilemma... No, you don't. A dilemma is a situation where one is forced to choose between two equally uncomfortable options. You have a problem, a difficulty, a snag, a conundrum, a predicament, a complication, possibly a quandary, but not a dilemma. > The aim is to disconnect the ATA ad0 thus rendering the SATA ad2 to > ad0, something like this: > > ATA channel 0: > Master: ad0 Serial ATA II > Slave: ad1 Serial ATA II > ATA channel 1: > Master: ad2 Serial ATA II > Slave: no device present > ATA channel 2: > Master: ad4 Serial ATA II > Slave: no device present > > The problem is that the info in zpool.cache is diferent from the new > disk order and zfs doesn't pick the volume thus no root fs. > I jumped on my "let's go for anything" suit and even tried to edit > zpool.cache by hand with the new disk order, sadly with no luck. Run "zpool export" before moving the disks, then "zpool import" after rebooting. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 21:16:56 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 8387916A408 for ; Thu, 12 Apr 2007 21:16:56 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6F413C45A for ; Thu, 12 Apr 2007 21:16:55 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so641283wra for ; Thu, 12 Apr 2007 14:16:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VYBQdODiNX1m9Jl+73ItwGNMVn57sjqaIYmA+1Mu2Kv2bGBJ1vbNKyvMkWTZw62eTJeFIUwRKkhT7/TMV4Ka7lDSk2mtxsEoe25QVcvDnvEObFcOAxx0uGuedMjuOkB2IQ59mWpXIdJTbfYjZfB9bqCngBMDScADU8JSUqZ+qj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=e76XCPdQeaN0FoVXTE3XNEYMl9QAqqKyaUJewmT2RTd+RGdRkTAGDPMqNCm30oOPbVNTKyIY/2uLeIoabHiPb5Y4GvzpxoWd1wvsaTd5fI/adpkeiOJPOD3wNmRnus6ehCr+N6x2f04XXRS2uy6TDeTKw9bFji+SVdMDrx7KAoU= Received: by 10.78.204.20 with SMTP id b20mr522234hug.1176412614637; Thu, 12 Apr 2007 14:16:54 -0700 (PDT) Received: by 10.78.188.9 with HTTP; Thu, 12 Apr 2007 14:16:54 -0700 (PDT) Message-ID: <70e8236f0704121416h15f398dah479351b7776e8679@mail.gmail.com> Date: Thu, 12 Apr 2007 22:16:54 +0100 From: "Joao Barros" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86odlte2rm.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20070409011723.GB74547@garage.freebsd.pl> <20070409094319.GB76673@garage.freebsd.pl> <70e8236f0704090808y5d305175wdc3cee5be1a26a9@mail.gmail.com> <20070409153338.GH76673@garage.freebsd.pl> <70e8236f0704090931v3d62d067kfa25993da10fb331@mail.gmail.com> <86bqhxcifq.fsf@dwp.des.no> <70e8236f0704100852y214dad89g1291bb525f4efc74@mail.gmail.com> <70e8236f0704121130u1262ccb6r571e18ad1a491dd3@mail.gmail.com> <86odlte2rm.fsf@dwp.des.no> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: ZFS: amd64, devd, root file system. 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, 12 Apr 2007 21:16:56 -0000 On 4/12/07, Dag-Erling Sm=F8rgrav wrote: > "Joao Barros" writes: > > The aim is to disconnect the ATA ad0 thus rendering the SATA ad2 to > > ad0, something like this: > > > > ATA channel 0: > > Master: ad0 Serial ATA II > > Slave: ad1 Serial ATA II > > ATA channel 1: > > Master: ad2 Serial ATA II > > Slave: no device present > > ATA channel 2: > > Master: ad4 Serial ATA II > > Slave: no device present > > > > The problem is that the info in zpool.cache is diferent from the new > > disk order and zfs doesn't pick the volume thus no root fs. > > I jumped on my "let's go for anything" suit and even tried to edit > > zpool.cache by hand with the new disk order, sadly with no luck. > > Run "zpool export" before moving the disks, then "zpool import" after > rebooting. I can export the zpool when I'm running off the ATA ad0 but I can't import from the SATA ad0, the root fs is on zfs... --=20 Joao Barros From owner-freebsd-fs@FreeBSD.ORG Thu Apr 12 21:27:13 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 6DE1816A402; Thu, 12 Apr 2007 21:27:13 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id F198013C448; Thu, 12 Apr 2007 21:27:12 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.187.68] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1Hc6ov2d6w-0000b8; Thu, 12 Apr 2007 23:27:10 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Thu, 12 Apr 2007 23:26:56 +0200 User-Agent: KMail/1.9.5 References: <20070409011723.GB74547@garage.freebsd.pl> <86odlte2rm.fsf@dwp.des.no> <70e8236f0704121416h15f398dah479351b7776e8679@mail.gmail.com> In-Reply-To: <70e8236f0704121416h15f398dah479351b7776e8679@mail.gmail.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1770616.Gb4IMlRJxC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704122327.06581.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+V+kGoU/BHQqZq3jWUmyRn2ugI7QGhMFna+fr 8Ro31PJ/u5TNRSJ1zOHjiv+7HvKrvPvRtMSRGSG6nRYavHLtdm odeYUZJt4jN3R2olQTUrA== Cc: freebsd-fs@freebsd.org, Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , Joao Barros , Pawel Jakub Dawidek Subject: Re: ZFS: amd64, devd, root file system. 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, 12 Apr 2007 21:27:13 -0000 --nextPart1770616.Gb4IMlRJxC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 12 April 2007 23:16, Joao Barros wrote: > On 4/12/07, Dag-Erling Sm=F8rgrav wrote: > > "Joao Barros" writes: > > > The aim is to disconnect the ATA ad0 thus rendering the SATA ad2 to > > > ad0, something like this: > > > > > > ATA channel 0: > > > Master: ad0 Serial ATA II > > > Slave: ad1 Serial ATA II > > > ATA channel 1: > > > Master: ad2 Serial ATA II > > > Slave: no device present > > > ATA channel 2: > > > Master: ad4 Serial ATA II > > > Slave: no device present > > > > > > The problem is that the info in zpool.cache is diferent from the > > > new disk order and zfs doesn't pick the volume thus no root fs. I > > > jumped on my "let's go for anything" suit and even tried to edit > > > zpool.cache by hand with the new disk order, sadly with no luck. > > > > Run "zpool export" before moving the disks, then "zpool import" after > > rebooting. > > I can export the zpool when I'm running off the ATA ad0 but I can't > import from the SATA ad0, the root fs is on zfs... glabel's are your friend - though you have to redo the pool. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1770616.Gb4IMlRJxC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGHqQqXyyEoT62BG0RAvRjAJ98rrv677C+wBBGw3Y+DPMnt6x94gCfbvhx thdmm4BZSiJs0uyIvE0mwnc= =Y0F1 -----END PGP SIGNATURE----- --nextPart1770616.Gb4IMlRJxC-- From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 05:08:44 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 7F43916A404 for ; Fri, 13 Apr 2007 05:08:44 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from qsrv01ps.mx.bigpond.com (qsrv01ps.mx.bigpond.com [144.140.82.181]) by mx1.freebsd.org (Postfix) with ESMTP id 1A70F13C43E for ; Fri, 13 Apr 2007 05:08:43 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from oaamta07ps.mx.bigpond.com ([144.132.228.157]) by omta05ps.mx.bigpond.com with ESMTP id <20070413031502.GDIS23363.omta05ps.mx.bigpond.com@oaamta07ps.mx.bigpond.com> for ; Fri, 13 Apr 2007 03:15:02 +0000 Received: from areilly.bpa.nu ([144.132.228.157]) by oaamta07ps.mx.bigpond.com with ESMTP id <20070413031501.LNSM27562.oaamta07ps.mx.bigpond.com@areilly.bpa.nu> for ; Fri, 13 Apr 2007 03:15:01 +0000 Received: (qmail 28952 invoked by uid 501); 13 Apr 2007 03:14:22 -0000 Date: Fri, 13 Apr 2007 13:14:22 +1000 From: Andrew Reilly To: Dag-Erling Sm?rgrav Message-ID: <20070413031422.GA27743@duncan.reilly.home> References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070412073605.GB834@turion.vk2pj.dyndns.org> <86ps6aht1i.fsf@dwp.des.no> <20070412160603.GB92079@keira.kiwi-computer.com> <20070412185159.GB95302@nowhere> <86slb5e33a.fsf@dwp.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86slb5e33a.fsf@dwp.des.no> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@FreeBSD.ORG, Craig Boston , "Rick C. Petty" , freebsd-current@FreeBSD.ORG Subject: Re: ZFS committed to the FreeBSD base. 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, 13 Apr 2007 05:08:44 -0000 On Thu, Apr 12, 2007 at 10:43:05PM +0200, Dag-Erling Sm?rgrav wrote: > Craig Boston writes: > > For something this low level my opinion is it's better to stay with > > compile time options. After all, in the above example, cmpxchg8 is a > > single machine instruction. How much overhead does it add to retrieve a > > variable from memory and check it, then jump to the correct place? > > Enough that it outweighs the benefit of using that instruction in the > > first place? > > I don't think it matters. Contrary to popular belief, atomic > operations are *expensive*. In the best case, on a UP machine, they > stall the pipeline. In the worst case, on an SMP machine, they stall > the entire memory bus. Apart from the fact that you are correct, how long is the instruction encoding of cmpxchg8? Perhaps it could be patched in at runtime, in place of the call to the emultaion, the way of on-the-fly linking in shared libraries and some floating point emulation/inline-ers? -- Andrew From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 07:35:01 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 4876C16A408; Fri, 13 Apr 2007 07:35:01 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id D2B8613C44C; Fri, 13 Apr 2007 07:35:00 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id BA28310D312; Fri, 13 Apr 2007 17:34:53 +1000 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id C9B2B8C16; Fri, 13 Apr 2007 17:34:57 +1000 (EST) Date: Fri, 13 Apr 2007 17:34:56 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86slb5e33a.fsf@dwp.des.no> Message-ID: <20070413164840.V31079@besplex.bde.org> References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070412073605.GB834@turion.vk2pj.dyndns.org> <86ps6aht1i.fsf@dwp.des.no> <20070412160603.GB92079@keira.kiwi-computer.com> <20070412185159.GB95302@nowhere> <86slb5e33a.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-579877781-1176449696=:31079" Cc: freebsd-fs@freebsd.org, Craig Boston , "Rick C. Petty" , freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. 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, 13 Apr 2007 07:35:01 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-579877781-1176449696=:31079 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 12 Apr 2007, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > Craig Boston writes: >> On Thu, Apr 12, 2007 at 11:06:03AM -0500, Rick C. Petty wrote: >>> Is there any way we could make the choice at boot time, by checking for >>> presence of the CX8 feature? Either as something like: >>> >>> extern int feature_cx8;=09=09/* or MIB variable */ >>> #define CMPXCHG8(a)=09(feature_cx8 ? { _asm "..." } : emulate_cmpxch8(a= )) >> For something this low level my opinion is it's better to stay with >> compile time options. After all, in the above example, cmpxchg8 is a >> single machine instruction. How much overhead does it add to retrieve a >> variable from memory and check it, then jump to the correct place? >> Enough that it outweighs the benefit of using that instruction in the >> first place? Not for cmpxchg8b, at least. It is a remarkably slow instruction. On AthlonXP's it has an execution latency of 39 cycles. cmpxchg only has an cmpxchg only has an execution latency of 6 cycles (both without a lock prefix). I don't know how to avoid using cmpxchg8b short of using a mutex lock/unlock pair and slightly different semantics, or a generation count and very different semantics, but without lock prefixes the mutex pair would be much faster than the cmpxchg8b. > I don't think it matters. I agree. > Contrary to popular belief, atomic > operations are *expensive*. Doesn't everyone who uses atomic operations knows that they are expensive? = :) > In the best case, on a UP machine, they > stall the pipeline. In the worst case, on an SMP machine, they stall > the entire memory bus. In the UP case, the pipeline stall is tiny or null. Independent instructions can still proceed, but CPUs (that have pipelines) usually can't keep pipelines moving anyway, and atomic instructions just reduce the chance that they can a little. Bruce --0-579877781-1176449696=:31079-- From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 11:24:26 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 A83F916A403; Fri, 13 Apr 2007 11:24:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 61DB413C44C; Fri, 13 Apr 2007 11:24:25 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id BB23E2090; Fri, 13 Apr 2007 13:24:21 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id A5CB72087; Fri, 13 Apr 2007 13:24:21 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id B40C9509A; Fri, 13 Apr 2007 13:24:20 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Bruce Evans References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070412073605.GB834@turion.vk2pj.dyndns.org> <86ps6aht1i.fsf@dwp.des.no> <20070412160603.GB92079@keira.kiwi-computer.com> <20070412185159.GB95302@nowhere> <86slb5e33a.fsf@dwp.des.no> <20070413164840.V31079@besplex.bde.org> Date: Fri, 13 Apr 2007 13:24:20 +0200 In-Reply-To: <20070413164840.V31079@besplex.bde.org> (Bruce Evans's message of "Fri, 13 Apr 2007 17:34:56 +1000 (EST)") Message-ID: <86veg0frff.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Craig Boston , "Rick C. Petty" , freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. 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, 13 Apr 2007 11:24:26 -0000 Bruce Evans writes: > Dag-Erling Sm=F8rgrav writes: > > Contrary to popular belief, atomic operations are *expensive*. > Doesn't everyone who uses atomic operations knows that they are > expensive? :) Everyone who *uses* them, yes, but not everyone does. I recall an interesting conversation at Poul-Henning's Varnish presentation in Milan where someone in the audience relentlessly insisted that [something or other] really wasn't as big an issue as Poul-Henning claimed, since atomic operations were so cheap. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 14:35:53 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 7F12616A401; Fri, 13 Apr 2007 14:35:53 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 648BB13C4B9; Fri, 13 Apr 2007 14:35:51 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id 22905110D6; Fri, 13 Apr 2007 09:35:51 -0500 (CDT) Date: Fri, 13 Apr 2007 09:35:50 -0500 From: Craig Boston To: Bruce Evans Message-ID: <20070413143550.GA19881@nowhere> References: <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070412073605.GB834@turion.vk2pj.dyndns.org> <86ps6aht1i.fsf@dwp.des.no> <20070412160603.GB92079@keira.kiwi-computer.com> <20070412185159.GB95302@nowhere> <86slb5e33a.fsf@dwp.des.no> <20070413164840.V31079@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070413164840.V31079@besplex.bde.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@freebsd.org, Dag-Erling Sm?rgrav , "Rick C. Petty" , freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. 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, 13 Apr 2007 14:35:53 -0000 On Fri, Apr 13, 2007 at 05:34:56PM +1000, Bruce Evans wrote: > Doesn't everyone who uses atomic operations knows that they are expensive? > :) Yes, though hopefully they should at least be faster than using a mutex, though for cmpxchg8b it sounds like that may not necessarily be the case... Craig From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 14:47:53 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 AB9E416A408; Fri, 13 Apr 2007 14:47:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 635E213C4B8; Fri, 13 Apr 2007 14:47:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 2111946DE8; Fri, 13 Apr 2007 10:47:52 -0400 (EDT) Date: Fri, 13 Apr 2007 15:47:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Craig Boston In-Reply-To: <20070413143550.GA19881@nowhere> Message-ID: <20070413154418.M65660@fledge.watson.org> References: <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070412073605.GB834@turion.vk2pj.dyndns.org> <86ps6aht1i.fsf@dwp.des.no> <20070412160603.GB92079@keira.kiwi-computer.com> <20070412185159.GB95302@nowhere> <86slb5e33a.fsf@dwp.des.no> <20070413164840.V31079@besplex.bde.org> <20070413143550.GA19881@nowhere> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, Dag-Erling Sm?rgrav , "Rick C. Petty" , freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. 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, 13 Apr 2007 14:47:53 -0000 On Fri, 13 Apr 2007, Craig Boston wrote: > On Fri, Apr 13, 2007 at 05:34:56PM +1000, Bruce Evans wrote: > >> Doesn't everyone who uses atomic operations knows that they are expensive? >> :) > > Yes, though hopefully they should at least be faster than using a mutex, > though for cmpxchg8b it sounds like that may not necessarily be the case... A common example of this not being the case is statistics updates: it doesn't take too many statistics being updated at once before it makes more sense to use a mutex than individual atomic instructions, as mutex lock and unlock, in the uncontended case, involve an atomic instruction each (with memory barriers). Then it becomes more semantic: is using non-blocking primitives preferable, or are there consistency requirements between "atomically" updated fields? If contention never happens, then maybe you get consistency for free by using a mutex. As a general rule, unless it's a very clear-cut case (a simple counter), I would encourage people to program with mutexes rather than directly with atomic instructions. It prevents them from having to deal with really weird stuff that happens with weaker memory consistency. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 14:53:04 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 04EE416A415; Fri, 13 Apr 2007 14:53:04 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 5AC1113C46C; Fri, 13 Apr 2007 14:52:58 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (fmhmda@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l3DEqjYi040100; Fri, 13 Apr 2007 16:52:51 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l3DEqjXv040099; Fri, 13 Apr 2007 16:52:45 +0200 (CEST) (envelope-from olli) Date: Fri, 13 Apr 2007 16:52:45 +0200 (CEST) Message-Id: <200704131452.l3DEqjXv040099@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, bde@zeta.org.au, des@des.no, freebsd-fs@FreeBSD.ORG, craig@xfoil.gank.org, rick-freebsd@kiwi-computer.com In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 13 Apr 2007 16:52:52 +0200 (CEST) Cc: Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, bde@zeta.org.au, des@des.no, freebsd-fs@FreeBSD.ORG, craig@xfoil.gank.org, rick-freebsd@kiwi-computer.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2007 14:53:04 -0000 Bruce Evans wrote: > Not for cmpxchg8b, at least. It is a remarkably slow instruction. On > AthlonXP's it has an execution latency of 39 cycles. cmpxchg only has an > cmpxchg only has an execution latency of 6 cycles (both without a lock > prefix). I don't know how to avoid using cmpxchg8b short of using a > mutex lock/unlock pair and slightly different semantics, or a generation > count and very different semantics, but without lock prefixes the > mutex pair would be much faster than the cmpxchg8b. Using cmpxchg8b with a lock prefix wouldn't be a good idea anyway. If I remember correctly, the lock cmpxchg8b combination was the cause of the infamous "F00F" bug of old Pentium processors. It causes them to freeze. (FreeBSD has a hack to work around the problem, as you certainly know ... I don't know exactly how it works.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd It's trivial to make fun of Microsoft products, but it takes a real man to make them work, and a God to make them do anything useful. From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 15:20:35 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 C903016A401; Fri, 13 Apr 2007 15:20:35 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 468D313C4AD; Fri, 13 Apr 2007 15:20:35 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (yjgxwf@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l3DFKSgb041555; Fri, 13 Apr 2007 17:20:34 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l3DFKSLs041554; Fri, 13 Apr 2007 17:20:28 +0200 (CEST) (envelope-from olli) Date: Fri, 13 Apr 2007 17:20:28 +0200 (CEST) Message-Id: <200704131520.l3DFKSLs041554@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, pjd@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG, zfs-discuss@opensolaris.org In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 13 Apr 2007 17:20:34 +0200 (CEST) Cc: Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, pjd@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG, zfs-discuss@opensolaris.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2007 15:20:35 -0000 Pawel Jakub Dawidek wrote: > I'm happy to inform that the ZFS file system is now part of the FreeBSD > operating system. ZFS is available in the HEAD branch and will be > available in FreeBSD 7.0-RELEASE as an experimental feature. Great work, Pawel! This is an important milestone for the FreeBSD project. Just a quick question: Does ZFS still work reliable when the write cache for ATA disks is enabled, i.e. with the line "hw.ata.wc=1" in /boot/loader.conf? I can't wait to set up a test machine with FreeBSD -current to start playing with ZFS. :) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I invented Ctrl-Alt-Delete, but Bill Gates made it famous." -- David Bradley, original IBM PC design team From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 15:59:58 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 0809B16A402; Fri, 13 Apr 2007 15:59:58 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id B4EDC13C4BD; Fri, 13 Apr 2007 15:59:57 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id B5D502091; Fri, 13 Apr 2007 17:59:53 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 2E5BC2087; Fri, 13 Apr 2007 17:59:53 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id C7D3850C8; Fri, 13 Apr 2007 17:59:52 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Andrew Reilly References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070412073605.GB834@turion.vk2pj.dyndns.org> <86ps6aht1i.fsf@dwp.des.no> <20070412160603.GB92079@keira.kiwi-computer.com> <20070412185159.GB95302@nowhere> <86slb5e33a.fsf@dwp.des.no> <20070413031422.GA27743@duncan.reilly.home> Date: Fri, 13 Apr 2007 17:59:52 +0200 In-Reply-To: <20070413031422.GA27743@duncan.reilly.home> (Andrew Reilly's message of "Fri, 13 Apr 2007 13:14:22 +1000") Message-ID: <86abxc1czr.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@FreeBSD.ORG, Craig Boston , "Rick C. Petty" , freebsd-current@FreeBSD.ORG Subject: Re: ZFS committed to the FreeBSD base. 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, 13 Apr 2007 15:59:58 -0000 Andrew Reilly writes: > Apart from the fact that you are correct, how long is the > instruction encoding of cmpxchg8? Three bytes (0F C7 m64), four for "lock cmpxchg8" (F0 0F C7 m64). If the top two bits of m64 are set, you may get "interesting" results :) DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 16:16:47 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 37CB216A400; Fri, 13 Apr 2007 16:16:47 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id EB06A13C45A; Fri, 13 Apr 2007 16:16:46 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 04BB02090; Fri, 13 Apr 2007 18:16:41 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id E2E582087; Fri, 13 Apr 2007 18:16:40 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id C7D2850CD; Fri, 13 Apr 2007 18:16:40 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: freebsd-current@FreeBSD.ORG References: <200704131452.l3DEqjXv040099@lurza.secnetix.de> Date: Fri, 13 Apr 2007 18:16:40 +0200 In-Reply-To: <200704131452.l3DEqjXv040099@lurza.secnetix.de> (Oliver Fromme's message of "Fri, 13 Apr 2007 16:52:45 +0200 (CEST)") Message-ID: <8664801c7r.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@FreeBSD.ORG, craig@xfoil.gank.org, rick-freebsd@kiwi-computer.com Subject: Re: ZFS committed to the FreeBSD base. 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, 13 Apr 2007 16:16:47 -0000 Oliver Fromme writes: > Using cmpxchg8b with a lock prefix wouldn't be a good idea anyway. > If I remember correctly, the lock cmpxchg8b combination was the > cause of the infamous "F00F" bug of old Pentium processors. It > causes them to freeze. Only when the operand is invalid. This causes an invalid opcode exception which can not be handled because the memory bus is locked, preventing the handler from beig loaded into cache. > (FreeBSD has a hack to work around the problem, as you certainly > know ... I don't know exactly how it works.) By marking the interrupt descriptor table read-only, the invalid opcode exception triggers a page fault, which unlocks the bus. The page fault handler examines the state of the CPU, determine that an invalid opcode exception occurred, and passes control to the appropriate handler (which sends SIGILL to the offending process). Additionally, to avoid penalizing other exceptions, the IDT is aligned such that it crosses a page boundary immediately after the entry for the invalid opcode exception, so only the first six entries in the IDT needs to be read-only. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 18:13:07 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG 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 B56D016A400; Fri, 13 Apr 2007 18:13:07 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 72C6113C4C5; Fri, 13 Apr 2007 18:13:07 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id DCE912090; Fri, 13 Apr 2007 20:13:03 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 049FE2087; Fri, 13 Apr 2007 20:13:03 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id E18D350E1; Fri, 13 Apr 2007 20:13:02 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: freebsd-current@FreeBSD.ORG References: <200704131520.l3DFKSLs041554@lurza.secnetix.de> Date: Fri, 13 Apr 2007 20:13:02 +0200 In-Reply-To: <200704131520.l3DFKSLs041554@lurza.secnetix.de> (Oliver Fromme's message of "Fri, 13 Apr 2007 17:20:28 +0200 (CEST)") Message-ID: <86veg0kus1.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@FreeBSD.ORG, zfs-discuss@opensolaris.org, pjd@FreeBSD.ORG Subject: Re: ZFS committed to the FreeBSD base. 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, 13 Apr 2007 18:13:07 -0000 Oliver Fromme writes: > Just a quick question: Does ZFS still work reliable when the write > cache for ATA disks is enabled, i.e. with the line "hw.ata.wc=3D1" in > /boot/loader.conf? Yes, as long as the disk doesn't lie about flushing its cache. Some early ATA disks faked the FLUSHCACHE command to improve their benchmark results. I don't know if any still do. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Fri Apr 13 18:55:08 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 C3CB416A401 for ; Fri, 13 Apr 2007 18:55:08 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6A713C45D for ; Fri, 13 Apr 2007 18:55:07 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so538153ugh for ; Fri, 13 Apr 2007 11:55:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=p4eiaQISUVP3UMmiRAGeR1aD7g8qh2F8eMETofUQAJsoJIB2YrvT+YQsPxWeJORe28bZUOooQm6/BWhCzqNg5Nn6RDxsHekeCMqjxbXomMsXgIBDzxZwI/lQ8yLBIO7Tq9yz2hXt3JSs1gMnRqtDaCtHh+B3QLPtXC3ueLId3BA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=jCVb7yKDF7QkUpPQgw61gZ22lZ+SyEmVs40dmL4Bjy0D/ZPKoKcqnLAi3ls3DGbBPW/ccKnOxRIv3fiIitvZh7JGJe+2S9AuLsL/5PrV4k/3pNs+DALYciVeEb/3QdUdYyJNA0shqH0yX8FMoirkiiDnPVKa8PtclA0Y61mYVts= Received: by 10.82.138.6 with SMTP id l6mr4723953bud.1176490506174; Fri, 13 Apr 2007 11:55:06 -0700 (PDT) Received: from roadrunner.q.local ( [85.180.144.87]) by mx.google.com with ESMTP id j2sm1100333mue.2007.04.13.11.54.58; Fri, 13 Apr 2007 11:55:04 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.8/8.13.8) with ESMTP id l3DIiQkx023163; Fri, 13 Apr 2007 20:44:26 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.8/8.13.8/Submit) id l3DIiPRL023159; Fri, 13 Apr 2007 20:44:25 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Fri, 13 Apr 2007 20:44:25 +0200 From: Ulrich Spoerlein To: "Rick C. Petty" Message-ID: <20070413184425.GA6042@roadrunner.q.local> Mail-Followup-To: "Rick C. Petty" , freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070412073605.GB834@turion.vk2pj.dyndns.org> <86ps6aht1i.fsf@dwp.des.no> <20070412160603.GB92079@keira.kiwi-computer.com> <20070412185159.GB95302@nowhere> <20070412195947.GA96935@keira.kiwi-computer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070412195947.GA96935@keira.kiwi-computer.com> Cc: freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: ZFS committed to the FreeBSD base. 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, 13 Apr 2007 18:55:08 -0000 Rick C. Petty wrote: > On Thu, Apr 12, 2007 at 01:51:59PM -0500, Craig Boston wrote: > > For something this low level my opinion is it's better to stay with > > compile time options. After all, in the above example, cmpxchg8 is a > > single machine instruction. How much overhead does it add to retrieve a > > variable from memory and check it, then jump to the correct place? > > Enough that it outweighs the benefit of using that instruction in the > > first place? > > [...] > The problem is that ZFS would be compiled (by default) to work for many > platforms, and thus a majority of systems wouldn't get the nice > optimization. Disclaimer: I have no clue what cmpxchg8 actually does, but ... We are talking about optimizing a filesystem by speeding up the necessary CPU computations. Now, whenever the CPU waits for I/O (which the ZFS threads will do plenty of times) it has literally thousands of cycles to burn. I don't see how this could possibly make ZFS any faster if it does not avoid I/O operations entirely. Ulrich Spoerlein -- "The trouble with the dictionary is you have to know how the word is spelled before you can look it up to see how it is spelled." -- Will Cuppy From owner-freebsd-fs@FreeBSD.ORG Sat Apr 14 02:53:22 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 C99AA16A400; Sat, 14 Apr 2007 02:53:22 +0000 (UTC) (envelope-from fbsd-fs@mawer.org) Received: from fallbackmx01.syd.optusnet.com.au (fallbackmx01.syd.optusnet.com.au [211.29.132.93]) by mx1.freebsd.org (Postfix) with ESMTP id 46B0313C480; Sat, 14 Apr 2007 02:53:21 +0000 (UTC) (envelope-from fbsd-fs@mawer.org) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by fallbackmx01.syd.optusnet.com.au (8.12.11.20060308/8.12.11) with ESMTP id l3CBwxF5020144; Thu, 12 Apr 2007 21:59:06 +1000 Received: from [10.4.0.169] (c211-30-198-155.thorn1.nsw.optusnet.com.au [211.30.198.155]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l3CBws1L009497; Thu, 12 Apr 2007 21:58:55 +1000 Message-ID: <461E1EF5.9010809@mawer.org> Date: Thu, 12 Apr 2007 21:58:45 +1000 From: Antony Mawer User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070412073605.GB834@turion.vk2pj.dyndns.org> <86ps6aht1i.fsf@dwp.des.no> In-Reply-To: <86ps6aht1i.fsf@dwp.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, Peter Jeremy , freebsd-current@freebsd.org, Pawel Jakub Dawidek , ticso@cicely.de Subject: Re: ZFS committed to the FreeBSD base. 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, 14 Apr 2007 02:53:22 -0000 Dag-Erling Smørgrav wrote: > Peter Jeremy writes: >> There's a feature bit (CPUID_CX8) that advertises the availability of >> cmpxchg8b (and maybe some related instructions). My pre-MMX 586 has >> this bit set so I presume anything later than 486 will support it. >> (I'm not sure about the low-end VIA, GEODE etc clones). > > The Geode is a 486, and does not support it. > > The C3 however is a 586. The C3 Ezra and C3 Samuel / Samuel 2 do not > have CX8. I'm not sure about the C3 Nehemiah, I don't have one > running at the moment. The Nehemiah doesn't look like it has CX8.. from one of my systems running a PD10000 board: CPU: VIA C3 Nehemiah+RNG+ACE (1002.28-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x698 Stepping = 8 Features=0x381b83f --Antony From owner-freebsd-fs@FreeBSD.ORG Sat Apr 14 04:06:39 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 9FB0D16A404 for ; Sat, 14 Apr 2007 04:06:39 +0000 (UTC) (envelope-from bp@barryp.org) Received: from eden.barryp.org (host-42-60-230-24.midco.net [24.230.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id 474D313C4BE for ; Sat, 14 Apr 2007 04:06:39 +0000 (UTC) (envelope-from bp@barryp.org) Received: from [10.66.1.10] (helo=barry-pedersons-computer.local) by eden.barryp.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HcZX3-000MKV-W6 for freebsd-fs@FreeBSD.org; Fri, 13 Apr 2007 23:06:38 -0500 Message-ID: <46205338.3090803@barryp.org> Date: Fri, 13 Apr 2007 23:06:16 -0500 From: Barry Pederson User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: ZFS raidz device replacement 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: Sat, 14 Apr 2007 04:06:39 -0000 I've been playing with ZFS (awesome stuff, thanks PJD) and noticed something funny when replacing a device under a raidz pool. It seems that even though ZFS says resilvering is complete, you still need to manually do a "zpool scrub" to really get the pool into a good state. From what I've read in the "Solaris ZFS Administration Guide", it doesn't seem that that step should be required. Is there some kind of auto-scrub being missed? I've tried to show this below with some md devices, creating 4 of them, putting 3 into a raidz and then replacing one. This is with a world and kernel csupped and built earlier today (2007-04-13) ------------------- # truncate -s 128m /tmp/foo0 # truncate -s 128m /tmp/foo1 # truncate -s 128m /tmp/foo2 # truncate -s 128m /tmp/foo3 # mdconfig -a -t vnode -f /tmp/foo0 md0 # mdconfig -a -t vnode -f /tmp/foo1 md1 # mdconfig -a -t vnode -f /tmp/foo2 md2 # mdconfig -a -t vnode -f /tmp/foo3 md3 # zpool create mypool raidz md0 md1 md2 # zpool status mypool pool: mypool state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM mypool ONLINE 0 0 0 raidz1 ONLINE 0 0 0 md0 ONLINE 0 0 0 md1 ONLINE 0 0 0 md2 ONLINE 0 0 0 errors: No known data errors # zpool replace mypool md2 md3 # zpool status mypool pool: mypool state: ONLINE scrub: resilver completed with 0 errors on Fri Apr 13 22:43:19 2007 config: NAME STATE READ WRITE CKSUM mypool ONLINE 0 0 0 raidz1 ONLINE 0 0 0 md0 ONLINE 0 0 0 md1 ONLINE 0 0 0 replacing ONLINE 0 0 0 md2 ONLINE 0 0 0 md3 ONLINE 0 0 0 errors: No known data errors # zpool status mypool pool: mypool state: ONLINE scrub: resilver completed with 0 errors on Fri Apr 13 22:43:19 2007 config: NAME STATE READ WRITE CKSUM mypool ONLINE 0 0 0 raidz1 ONLINE 0 0 0 md0 ONLINE 0 0 0 md1 ONLINE 0 0 0 md3 ONLINE 0 0 0 errors: No known data errors # zpool scrub mypool # zpool status mypool pool: mypool state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub completed with 0 errors on Fri Apr 13 22:43:46 2007 config: NAME STATE READ WRITE CKSUM mypool ONLINE 0 0 0 raidz1 ONLINE 0 0 0 md0 ONLINE 0 0 0 md1 ONLINE 0 0 0 md3 ONLINE 0 0 5 errors: No known data errors -------------------------------- Barry From owner-freebsd-fs@FreeBSD.ORG Sat Apr 14 09:48:32 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 2B1DE16A407 for ; Sat, 14 Apr 2007 09:48:32 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mail.atsec.com (mail.atsec.com [195.30.252.105]) by mx1.freebsd.org (Postfix) with ESMTP id 7111313C46C for ; Sat, 14 Apr 2007 09:48:30 +0000 (UTC) (envelope-from se@freebsd.org) Received: (qmail 14379 invoked by uid 10125); 14 Apr 2007 09:21:49 -0000 X-SpaceNet-Virusscan: Sophos Version: 4.13; Last IDE Update: 2007-04-14 04:30 no information about results Received: from p5087934c.dip0.t-ipconnect.de (HELO ?192.168.0.12?) (80.135.147.76) by mail.atsec.com with SMTP; 14 Apr 2007 09:21:49 -0000 X-SpaceNet-Authentification: SMTP AUTH verified Message-ID: <46209D21.2010704@FreeBSD.org> Date: Sat, 14 Apr 2007 11:21:37 +0200 From: Stefan Esser User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070409011723.GB74547@garage.freebsd.pl> <20070409094319.GB76673@garage.freebsd.pl> In-Reply-To: <20070409094319.GB76673@garage.freebsd.pl> X-Enigmail-Version: 0.94.1.2.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS: amd64, devd, root file system. 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, 14 Apr 2007 09:48:32 -0000 Pawel Jakub Dawidek wrote: > On Mon, Apr 09, 2007 at 03:17:23AM +0200, Pawel Jakub Dawidek wrote: Hi Pawel, great to see ZFS support committed to -current! It is amazingly simple to get a test setup going and it worked fine in my initial simple test cases. But now I've run into problems that probably are not technical but caused by a lack of understanding ... >> 3. It is now possible to have root file system on ZFS. You would still >> need UFS for your /boot/ file system. Hmmm, I yesterday bought a new disk for playing with ZFS and while it worked fine in most of my tests, I could not get the kernel to mount the ZFS based root partition. Maybe there is something wrong in the way I tried it (I did not strictly follow the method you suggested, because of special requirements). > Let me explain how this suppose to work. > > You have ad0 disk. Create one slice covering entire disk: > > # fdisk -BI /dev/ad0 In my case I have a ad0s1a (boot file system) and ad0s1b (swap for core dumps) and planned to have ad0s2 for ZFS. DOS and BSD partitions were created from, within sysinstall (and I have verified with CLI tools that the result looks OK). > Initialize BSDlabel: > > # bsdlabel -wB /dev/ad0s1 > > Edit your label and create small (like 256MB-512MB) 'a' partition and > use the rest for 'd' partition: > > # bsdlabel -e /dev/ad0s1 > > 'd' partition will be used for ZFS: In my case 1GB for ad0s1a (256MB) and ad0s1b (768MB) and 300GB for ad0s2. > # zpool create tank ad0s1d zpool create test ad0s2 > Create UFS file system on /dev/ad0s1a and copy /boot/ directory in > there: > > # newfs /dev/ad0s1a > # mount /dev/ad0s1a /mnt/tmp > # cp -Rp /boot/* /mnt/tmp/ I have copied /boot and /rescue to ad0s1a (and later, to simplify further testing, also /etc, /bin, /sbin, /lib, /libexec, since I wanted to be able to run recovery tools from ad0s1a). > Note that there is no /boot/ directory on ad0s1a yet. This is one of the > two possibilities. You now need to create symlink: > > # cd /mnt/tmp > # ln -s . boot > > From what I checked our loader should handle symlinks just fine. > This will allow us to mount /dev/ad0s1a on /boot directory and use it as > usual. > > Another option is to: > > # cp -Rp /boot /mnt/tmp/ > > and in the future mount /dev/ad0s1a on eg. /bootdisk and create symlink: > > # ln -s bootdisk/boot /boot I decided to habe a /.ufs file system and mount ad0s1a there, with symlinks from /boot and /rescue to /.ufs/boot and /.ufs/rescue ... > All in all, you should see your kernel when you do: > > # ls -l /mnt/tmp/boot/kernel > > Now don't forget to add zfs_load="YES" to /mnt/tmp/boot/loader.conf. > > Ok, you also need to tell your loader where your root file system is. > You can do it by adding: > > vfs.root.mountfrom="zfs:tank" > > to /mnt/tmp/boot/loader.conf or you can create /mnt/tmp/etc/fstab file > with one entry only: > > tank / zfs rw 0 0 Neither of these make the kernel accept the ZFS root file system in my case. (I currently have both, but even when I enter zfs:test at the prompt displayed by the kernel after failure to mount a root fs, it is not accepted). I do then enter ufs:ad0s1a to boot my UFS file system for recovery (with /bin, /sbin, /lib, and /etc besides /boot and /rescue). Then I have access to "zfs" and "zpool" commands, which let me mount the ZFS file system, even overloading the UFS root. I only have to make sure, that I manually mount DEVFS into the ZFS root. But in most of my tests, I need to "export" and "import -f" the ZFS pool, since it is displayed as "FAULTED" at first. This is true even if I manage to mount the UFS partition in such a way, that /boot/zfs/zpool.cache is correctly updated. I assume that file is used to control the automatic ZFS root mounting? Do I need to set the "alternate root" flag on the pool during import to have it accepted as a root FS during boot??? (This will be my next test, I think ...) > On your ZFS file system, your /etc/fstab should contains the line above > and: > > /dev/ad0s1a /boot ufs rw 0 0 I use: /dev/ad0s1a /.ufs ufs rw 1 2 > (and everything else, ie. your swap and other file systems) Hmmm, there are a few points that I do not fully understand: It seems that ZFS "legacy" mounts are not supported under FreeBSD, is this correct? (E.g. if I enter "zfs set mountpoint=legacy test" then "test" can not be mounted with "zfs mount test" and there is no other way to mount it since we do not have a "mount_zfs", yet?) I tried to set the mountpoint of my to-be root file system to "/" with "zfs set mountpoint=/ test" but I'm under the impression that this does not really work. Setting it to "//" does appear to have the desired effect, though, but may lead to a panic during shutdown. (Sorry, I've got no core-dumps but could try producing one later if there is interest. The panic is because of a ref count becoming negative but I did not write down the message.) I decided to have multiple zfs file systems (test/var, test/usr ...) and can see them with zfs list. What is the correct way to get them mounted automatically? (Assuming I get the problem to have the kernel automatically mount the ZFS root solved ...) Do I need fstab entries for for ZFS file systems (e.g. "test/usr") or does ZFS mount them automatically when the pool "test" is mounted? Or do I need a fstab line for each of them? What's supposed to go into /etc/zfs, besides the ZFS exports file? Regards, STefan From owner-freebsd-fs@FreeBSD.ORG Sat Apr 14 10:23:36 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 BF3F316A400; Sat, 14 Apr 2007 10:23:36 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id C1D1C13C45E; Sat, 14 Apr 2007 10:23:35 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 490084569A; Sat, 14 Apr 2007 12:23:34 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id E359D45684; Sat, 14 Apr 2007 12:23:27 +0200 (CEST) Date: Sat, 14 Apr 2007 12:23:13 +0200 From: Pawel Jakub Dawidek To: Stefan Esser Message-ID: <20070414102313.GC10527@garage.freebsd.pl> References: <20070409011723.GB74547@garage.freebsd.pl> <20070409094319.GB76673@garage.freebsd.pl> <46209D21.2010704@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eHhjakXzOLJAF9wJ" Content-Disposition: inline In-Reply-To: <46209D21.2010704@FreeBSD.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS: amd64, devd, root file system. 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, 14 Apr 2007 10:23:36 -0000 --eHhjakXzOLJAF9wJ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 14, 2007 at 11:21:37AM +0200, Stefan Esser wrote: > Pawel Jakub Dawidek wrote: > > On Mon, Apr 09, 2007 at 03:17:23AM +0200, Pawel Jakub Dawidek wrote: >=20 > Hi Pawel, >=20 > great to see ZFS support committed to -current! >=20 > It is amazingly simple to get a test setup going and it worked fine > in my initial simple test cases. But now I've run into problems that > probably are not technical but caused by a lack of understanding ... This is not the first report that it doesn't work as it should. One was that /boot/defaults/loader.conf wasn't fresh enough, and there were no: zpool_cache_load=3D"YES" zpool_cache_type=3D"/boot/zfs/zpool.cache" zpool_cache_name=3D"/boot/zfs/zpool.cache" lines at the end. Can you verify you have them? Can you send me log of full boot process? > Hmmm, there are a few points that I do not fully understand: >=20 > It seems that ZFS "legacy" mounts are not supported under FreeBSD, > is this correct? (E.g. if I enter "zfs set mountpoint=3Dlegacy test" > then "test" can not be mounted with "zfs mount test" and there is > no other way to mount it since we do not have a "mount_zfs", yet?) They are supported. "legacy" means that you no longer use 'zfs mount' to mount them, but simply mount(8) (or /etc/fstab). There is no mount_zfs and there won't be one, because we are moving away from such commands. You should use 'mount -t zfs' instead. > I tried to set the mountpoint of my to-be root file system to "/" > with "zfs set mountpoint=3D/ test" but I'm under the impression that > this does not really work. Setting it to "//" does appear to have > the desired effect, though, but may lead to a panic during shutdown. > (Sorry, I've got no core-dumps but could try producing one later > if there is interest. The panic is because of a ref count becoming > negative but I did not write down the message.) The mount point can be set to whatever you like, but you can still mount it using different mount point by hand (via mount(8)). The most proper way is probably to set mountpoint to "legacy". > I decided to have multiple zfs file systems (test/var, test/usr ...) > and can see them with zfs list. What is the correct way to get them > mounted automatically? (Assuming I get the problem to have the kernel > automatically mount the ZFS root solved ...) zfs_enable=3D"YES" in your /etc/rc.conf. > Do I need fstab entries for for ZFS file systems (e.g. "test/usr") > or does ZFS mount them automatically when the pool "test" is mounted? They are mount via rc.d/zfs script. > Or do I need a fstab line for each of them? > What's supposed to go into /etc/zfs, besides the ZFS exports file? For now only exports file. zpool.cache use to be there as well, but we need it in /boot/zfs/ to be able to have root-on-ZFS. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --eHhjakXzOLJAF9wJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGIKuRForvXbEpPzQRArfeAJwMrRmHTFDd2H76tppk6cdrqRWwigCgozqN Lsf351DGH23timvBwQ+Ikas= =duuc -----END PGP SIGNATURE----- --eHhjakXzOLJAF9wJ-- From owner-freebsd-fs@FreeBSD.ORG Sat Apr 14 14:04:29 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 0222816A400 for ; Sat, 14 Apr 2007 14:04:29 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF9313C46A for ; Sat, 14 Apr 2007 14:04:28 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1088824wxc for ; Sat, 14 Apr 2007 07:04:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OVWITE5Kjqau0ZTjggSB6/cO9iz83Fjc7U+QJGWRJ1pEHvPWDWWzaidYvbq4T5xhFU/xkCBNHLqOtqaCAdCRkDdeZ/qq236ztSE11ruvpKgEd903ivg4OK308yES3s4yolIGEP0GtYSXBw0wdiPyRl9CA+kAU1CQNY5Q5lLBgJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TWtBmPRaYNojmkOmostTCd+GzQQ7wRnwm5KbZSCdkTTeg7miTQU7hsd0O9c7Ijeeb2Hlang0mvd2J7GVzu+U3IHNJhPy8Hfuw/7KzcwQSeKmTFcIBKTJblD+hvMy6h1hdUlZS4Cdz2DJ7Br4LepUn0T0pslKQ37XmcLXJGyk5q0= Received: by 10.78.136.9 with SMTP id j9mr811724hud.1176559466875; Sat, 14 Apr 2007 07:04:26 -0700 (PDT) Received: by 10.78.188.9 with HTTP; Sat, 14 Apr 2007 07:04:26 -0700 (PDT) Message-ID: <70e8236f0704140704v44a1810ft6bf3b7e6c426bb65@mail.gmail.com> Date: Sat, 14 Apr 2007 15:04:26 +0100 From: "Joao Barros" To: "Pawel Jakub Dawidek" In-Reply-To: <70e8236f0704121416h15f398dah479351b7776e8679@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20070409011723.GB74547@garage.freebsd.pl> <20070409094319.GB76673@garage.freebsd.pl> <70e8236f0704090808y5d305175wdc3cee5be1a26a9@mail.gmail.com> <20070409153338.GH76673@garage.freebsd.pl> <70e8236f0704090931v3d62d067kfa25993da10fb331@mail.gmail.com> <86bqhxcifq.fsf@dwp.des.no> <70e8236f0704100852y214dad89g1291bb525f4efc74@mail.gmail.com> <70e8236f0704121130u1262ccb6r571e18ad1a491dd3@mail.gmail.com> <86odlte2rm.fsf@dwp.des.no> <70e8236f0704121416h15f398dah479351b7776e8679@mail.gmail.com> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS: amd64, devd, root file system. 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, 14 Apr 2007 14:04:29 -0000 On 4/12/07, Joao Barros wrote: > On 4/12/07, Dag-Erling Sm=F8rgrav wrote: > > "Joao Barros" writes: > > > The aim is to disconnect the ATA ad0 thus rendering the SATA ad2 to > > > ad0, something like this: > > > > > > ATA channel 0: > > > Master: ad0 Serial ATA II > > > Slave: ad1 Serial ATA II > > > ATA channel 1: > > > Master: ad2 Serial ATA II > > > Slave: no device present > > > ATA channel 2: > > > Master: ad4 Serial ATA II > > > Slave: no device present > > > > > > The problem is that the info in zpool.cache is diferent from the new > > > disk order and zfs doesn't pick the volume thus no root fs. > > > I jumped on my "let's go for anything" suit and even tried to edit > > > zpool.cache by hand with the new disk order, sadly with no luck. > > > > Run "zpool export" before moving the disks, then "zpool import" after > > rebooting. > > I can export the zpool when I'm running off the ATA ad0 but I can't > import from the SATA ad0, the root fs is on zfs... > As a workaround I copied my system from the ATA ad0 to a scsi disk in order to get a zpool.cache with the final configuration. I got my system on zfs :D xeon# mount r4x320 on / (zfs, local) devfs on /dev (devfs, local) /dev/ad0s1a on /bootdisk (ufs, local) xeon# zfs list NAME USED AVAIL REFER MOUNTPOINT r4x320 6.55G 870G 4.55G /r4x320 r4x320/swap 23.9K 872G 23.9K - xeon# cat /etc/fstab # Device Mountpoint FStype Options Dump Pas= s# /dev/zvol/r4x320/swap none swap sw 0 0 /dev/ad0s1a /bootdisk ufs rw 0 0 #/dev/zvol/r4x320 / ufs rw 1 1 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 I only got one problem now: from what I can see swapon runs first that the zfs startup script so I have no swap. Only after booting I can see /dev/zvol/r4x320/swap and swapon works. Here is dmesg: Mar 19 10:59:32 xeon syslogd: kernel boot file is /boot/kernel/kernel Mar 19 10:59:32 xeon kernel: Copyright (c) 1992-2007 The FreeBSD Project. Mar 19 10:59:32 xeon kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Mar 19 10:59:32 xeon kernel: The Regents of the University of California. All rights reserved. Mar 19 10:59:32 xeon kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Mar 19 10:59:32 xeon kernel: FreeBSD 7.0-CURRENT #5: Tue Apr 10 00:06:35 WEST 2007 Mar 19 10:59:32 xeon kernel: root@xeon.bsdtech.org:/usr/obj/usr/src/sys/GEN= ERIC Mar 19 10:59:32 xeon kernel: WARNING: WITNESS option enabled, expect reduced performance. Mar 19 10:59:32 xeon kernel: acpi_alloc_wakeup_handler: can't alloc wake me= mory Mar 19 10:59:32 xeon kernel: ACPI APIC Table: Mar 19 10:59:32 xeon kernel: Timecounter "i8254" frequency 1193182 Hz quali= ty 0 Mar 19 10:59:32 xeon kernel: CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3073.65-MHz 686-class CPU) Mar 19 10:59:32 xeon kernel: Origin =3D "GenuineIntel" Id =3D 0xf29 Stepp= ing =3D 9 Mar 19 10:59:32 xeon kernel: Features=3D0xbfebfbff Mar 19 10:59:32 xeon kernel: Logical CPUs per core: 2 Mar 19 10:59:32 xeon kernel: real memory =3D 1072562176 (1022 MB) Mar 19 10:59:32 xeon kernel: avail memory =3D 1035956224 (987 MB) Mar 19 10:59:32 xeon kernel: FreeBSD/SMP: Multiprocessor System Detected: 2= CPUs Mar 19 10:59:32 xeon kernel: cpu0 (BSP): APIC ID: 0 Mar 19 10:59:32 xeon kernel: cpu1 (AP): APIC ID: 1 Mar 19 10:59:32 xeon kernel: ACPI: RSDP @ 0x0xf7bf0/0x0014 (v 0 IntelR) Mar 19 10:59:32 xeon kernel: ACPI: RSDT @ 0x0x3fee3040/0x002C (v 1 IntelR AWRDACPI 0x42302E31 AWRD 0x00000000) Mar 19 10:59:32 xeon kernel: ACPI: FACP @ 0x0x3fee30c0/0x0074 (v 1 IntelR AWRDACPI 0x42302E31 AWRD 0x00000000) Mar 19 10:59:32 xeon kernel: ACPI: DSDT @ 0x0x3fee3180/0x3FF3 (v 1 INTELR AWRDACPI 0x00001000 MSFT 0x0100000E) Mar 19 10:59:32 xeon kernel: ACPI: FACS @ 0x0x3fee0000/0x0040 Mar 19 10:59:32 xeon kernel: ACPI: APIC @ 0x0x3fee71c0/0x0090 (v 1 IntelR AWRDACPI 0x42302E31 AWRD 0x00000000) Mar 19 10:59:32 xeon kernel: ioapic0: Changing APIC ID to 4 Mar 19 10:59:32 xeon kernel: ioapic0 irqs 0-23 on motherboard Mar 19 10:59:32 xeon kernel: ioapic1 irqs 24-47 on motherboar= d Mar 19 10:59:32 xeon kernel: kbd1 at kbdmux0 Mar 19 10:59:32 xeon kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) Mar 19 10:59:32 xeon kernel: acpi0: on motherboard Mar 19 10:59:32 xeon kernel: acpi0: [ITHREAD] Mar 19 10:59:32 xeon kernel: acpi0: Power Button (fixed) Mar 19 10:59:32 xeon kernel: acpi0: reservation of 0, a0000 (3) failed Mar 19 10:59:32 xeon kernel: acpi0: reservation of 100000, 3fde0000 (3) fai= led Mar 19 10:59:32 xeon kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Mar 19 10:59:32 xeon kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 Mar 19 10:59:32 xeon kernel: cpu0: on acpi0 Mar 19 10:59:32 xeon kernel: cpu1: on acpi0 Mar 19 10:59:32 xeon kernel: acpi_button0: on acpi0 Mar 19 10:59:32 xeon kernel: pcib0: port 0xcf8-0xcff on acpi0 Mar 19 10:59:32 xeon kernel: pci0: on pcib0 Mar 19 10:59:32 xeon kernel: agp0: on hos= tb0 Mar 19 10:59:32 xeon kernel: pcib1: at device 1.0 on pci0 Mar 19 10:59:32 xeon kernel: pci1: on pcib1 Mar 19 10:59:32 xeon kernel: vgapci0: mem 0xf8000000-0xf8ffffff,0xf0000000-0xf7ffffff irq 16 at de Mar 19 10:59:32 xeon kernel: pcib2: at device 3.0 on = pci0 Mar 19 10:59:32 xeon kernel: pci2: on pcib2 Mar 19 10:59:32 xeon kernel: em0: port 0xa000-0xa01f mem 0xfb020000- Mar 19 10:59:32 xeon kernel: em0: Ethernet address: 00:11:d8:a2:21:c8 Mar 19 10:59:32 xeon kernel: em0: [FILTER] Mar 19 10:59:32 xeon kernel: pcib3: at device 28.0 on= pci0 Mar 19 10:59:32 xeon kernel: pci3: on pcib3 Mar 19 10:59:32 xeon kernel: uhci0: port 0xc400-0xc41f irq 16 at device 29.0 on pci0 Mar 19 10:59:32 xeon kernel: uhci0: [GIANT-LOCKED] Mar 19 10:59:32 xeon kernel: uhci0: [ITHREAD] Mar 19 10:59:32 xeon kernel: usb0: on uhci0 Mar 19 10:59:32 xeon kernel: usb0: USB revision 1.0 Mar 19 10:59:32 xeon kernel: uhub0: on usb0 Mar 19 10:59:32 xeon kernel: uhub0: 2 ports with 2 removable, self powered Mar 19 10:59:32 xeon kernel: uhci1: port 0xc000-0xc01f irq 19 at device 29.1 on pci0 Mar 19 10:59:32 xeon kernel: uhci1: [GIANT-LOCKED] Mar 19 10:59:32 xeon kernel: uhci1: [ITHREAD] Mar 19 10:59:32 xeon kernel: usb1: on uhci1 Mar 19 10:59:32 xeon kernel: usb1: USB revision 1.0 Mar 19 10:59:32 xeon kernel: uhub1: on usb1 Mar 19 10:59:32 xeon kernel: uhub1: 2 ports with 2 removable, self powered Mar 19 10:59:32 xeon kernel: pci0: at device 29.4 (no driver attached) Mar 19 10:59:32 xeon kernel: ehci0: mem 0xfc100000-0xfc1003ff irq 23 at device 29.7 on p Mar 19 10:59:32 xeon kernel: ehci0: [GIANT-LOCKED] Mar 19 10:59:32 xeon kernel: ehci0: [ITHREAD] Mar 19 10:59:32 xeon kernel: usb2: EHCI version 1.0 Mar 19 10:59:32 xeon kernel: usb2: companion controllers, 2 ports each: usb0 usb1 Mar 19 10:59:32 xeon kernel: usb2: on eh= ci0 Mar 19 10:59:32 xeon kernel: usb2: USB revision 2.0 Mar 19 10:59:32 xeon kernel: uhub2: on usb2 Mar 19 10:59:32 xeon kernel: uhub2: 4 ports with 4 removable, self powered Mar 19 10:59:32 xeon kernel: pcib4: at device 30.0 on= pci0 Mar 19 10:59:32 xeon kernel: pci4: on pcib4 Mar 19 10:59:32 xeon kernel: fwohci0: mem 0xfc025000-0xfc0257ff,0xfc020000-0xfc023fff irq 2 Mar 19 10:59:32 xeon kernel: fwohci0: [ITHREAD] Mar 19 10:59:32 xeon kernel: fwohci0: OHCI version 1.10 (ROM=3D1) Mar 19 10:59:32 xeon kernel: fwohci0: No. of Isochronous channels is 4. Mar 19 10:59:32 xeon kernel: fwohci0: EUI64 00:11:d8:00:00:18:1b:79 Mar 19 10:59:32 xeon kernel: fwohci0: Phy 1394a available S400, 2 ports. Mar 19 10:59:32 xeon kernel: fwohci0: Link S400, max_rec 2048 bytes. Mar 19 10:59:32 xeon kernel: firewire0: on fwohci0 Mar 19 10:59:32 xeon kernel: fwe0: on firewire0 Mar 19 10:59:32 xeon kernel: if_fwe0: Fake Ethernet address: 02:11:d8:18:1b= :79 Mar 19 10:59:32 xeon kernel: fwe0: Ethernet address: 02:11:d8:18:1b:79 Mar 19 10:59:32 xeon kernel: fwe0: if_start running deferred for Giant Mar 19 10:59:32 xeon kernel: sbp0: on firewire0 Mar 19 10:59:32 xeon kernel: fwohci0: Initiate bus reset Mar 19 10:59:32 xeon kernel: fwohci0: BUS reset Mar 19 10:59:32 xeon kernel: fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode Mar 19 10:59:32 xeon kernel: firewire0: 1 nodes, maxhop <=3D 0, cable IRM = =3D 0 (me) Mar 19 10:59:32 xeon kernel: firewire0: bus manager 0 (me) Mar 19 10:59:32 xeon kernel: atapci0: port 0xb000-0xb03f,0xb400-0xb40f,0xb800-0xb87f Mar 19 10:59:32 xeon kernel: atapci0: [ITHREAD] Mar 19 10:59:32 xeon kernel: atapci0: [ITHREAD] Mar 19 10:59:32 xeon kernel: ata2: on atapci0 Mar 19 10:59:32 xeon kernel: ata2: [ITHREAD] Mar 19 10:59:32 xeon kernel: ata3: on atapci0 Mar 19 10:59:32 xeon kernel: ata3: [ITHREAD] Mar 19 10:59:32 xeon kernel: ata4: on atapci0 Mar 19 10:59:32 xeon kernel: ata4: [ITHREAD] Mar 19 10:59:32 xeon kernel: ata5: on atapci0 Mar 19 10:59:32 xeon kernel: ata5: [ITHREAD] Mar 19 10:59:32 xeon kernel: isab0: at device 31.0 on pci0 Mar 19 10:59:32 xeon kernel: isa0: on isab0 Mar 19 10:59:32 xeon kernel: atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0x Mar 19 10:59:32 xeon kernel: ata0: on atapci1 Mar 19 10:59:32 xeon kernel: ata0: [ITHREAD] Mar 19 10:59:32 xeon kernel: ata1: on atapci1 Mar 19 10:59:32 xeon kernel: ata1: [ITHREAD] Mar 19 10:59:32 xeon kernel: ichsmb0: port 0x500-0x51f irq 17 at device 31.3 on pci0 Mar 19 10:59:32 xeon kernel: ichsmb0: [GIANT-LOCKED] Mar 19 10:59:32 xeon kernel: ichsmb0: [ITHREAD] Mar 19 10:59:32 xeon kernel: smbus0: on ichsmb0 Mar 19 10:59:32 xeon kernel: pcm0: port 0xe000-0xe0ff,0xe400-0xe43f mem 0xfc102000-0xfc1021ff,0xfc103000-0x Mar 19 10:59:32 xeon kernel: pcm0: [ITHREAD] Mar 19 10:59:32 xeon kernel: pcm0: Mar 19 10:59:32 xeon kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Mar 19 10:59:32 xeon kernel: sio0: type 16550A Mar 19 10:59:32 xeon kernel: sio0: [FILTER] Mar 19 10:59:32 xeon kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Mar 19 10:59:32 xeon kernel: atkbd0: irq 1 on atkbdc0 Mar 19 10:59:32 xeon kernel: kbd0 at atkbd0 Mar 19 10:59:32 xeon kernel: atkbd0: [GIANT-LOCKED] Mar 19 10:59:32 xeon kernel: atkbd0: [ITHREAD] Mar 19 10:59:32 xeon kernel: psm0: irq 12 on atkbdc0 Mar 19 10:59:32 xeon kernel: psm0: [GIANT-LOCKED] Mar 19 10:59:32 xeon kernel: psm0: [ITHREAD] Mar 19 10:59:32 xeon kernel: psm0: model IntelliMouse Explorer, device ID 4 Mar 19 10:59:32 xeon kernel: pmtimer0 on isa0 Mar 19 10:59:32 xeon kernel: orm0: at iomem 0xc0000-0xcb7ff pnpid ORM0000 on isa0 Mar 19 10:59:32 xeon kernel: ppc0: parallel port not found. Mar 19 10:59:32 xeon kernel: sc0: at flags 0x100 on isa0 Mar 19 10:59:32 xeon kernel: sc0: VGA <16 virtual consoles, flags=3D0x300> Mar 19 10:59:32 xeon kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Mar 19 10:59:32 xeon kernel: sio1: port may not be enabled Mar 19 10:59:32 xeon kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Mar 19 10:59:32 xeon kernel: Timecounters tick every 1.000 msec Mar 19 10:59:32 xeon kernel: ad0: 305245MB at ata0-master SATA150 Mar 19 10:59:32 xeon kernel: ad1: 305245MB at ata0-slave SATA150 Mar 19 10:59:32 xeon kernel: acd0: DVDROM at ata1-master UDMA66 Mar 19 10:59:32 xeon kernel: ad4: 305245MB at ata2-master SATA150 Mar 19 10:59:32 xeon kernel: ad6: 305245MB at ata3-master SATA150 Mar 19 10:59:32 xeon kernel: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 Mar 19 10:59:32 xeon kernel: ar0: 305245MB status: READY Mar 19 10:59:32 xeon kernel: ar0: disk0 READY using ad4 at ata2-master Mar 19 10:59:32 xeon kernel: ar1: 305245MB status: READY Mar 19 10:59:32 xeon kernel: ar1: disk0 READY using ad6 at ata3-master Mar 19 10:59:32 xeon kernel: WARNING: ZFS is considered to be an experimental feature in FreeBSD. Mar 19 10:59:32 xeon kernel: SMP: AP CPU #1 Launched! Mar 19 10:59:32 xeon kernel: cd0 at ata1 bus 0 target 0 lun 0 Mar 19 10:59:32 xeon kernel: cd0: Removable CD-ROM SCSI-0 device Mar 19 10:59:32 xeon kernel: cd0: 66.000MB/s transfers Mar 19 10:59:32 xeon kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present Mar 19 10:59:32 xeon kernel: ZFS filesystem version 6 Mar 19 10:59:32 xeon kernel: ZFS storage pool version 6 Mar 19 10:59:32 xeon kernel: Trying to mount root from zfs:r4x320 Mar 19 10:59:32 xeon kernel: lock order reversal: Mar 19 10:59:32 xeon kernel: 1st 0xc4bbd520 zfs:&dr->dt.di.dr_mtx (zfs:&dr->dt.di.dr_mtx) @ /usr/src/sys/modules/zfs/../../ Mar 19 10:59:32 xeon kernel: 2nd 0xc4932f00 zfs:&db->db_mtx (zfs:&db->db_mtx) @ /usr/src/sys/modules/zfs/../../contrib/open Mar 19 10:59:32 xeon kernel: KDB: stack backtrace: Mar 19 10:59:32 xeon kernel: db_trace_self_wrapper(c094c217) at db_trace_self_wrapper+0x25 Mar 19 10:59:32 xeon kernel: kdb_backtrace(0,ffffffff,c0a5b5c8,c0a5b6e0,c09f6eac,...) at kdb_backtrace+0x29 Mar 19 10:59:32 xeon kernel: witness_checkorder(c4932f00,9,c0cb54b3,75f) at witness_checkorder+0x586 Mar 19 10:59:32 xeon kernel: _sx_xlock(c4932f00,c0cb54b3,75f,b55,0,...) at _sx_xlock+0x3e Mar 19 10:59:32 xeon kernel: dbuf_sync_list(c4bbd538,c44bdd00,b55,0,c4197800,...) at dbuf_sync_list+0x15b Mar 19 10:59:32 xeon kernel: dbuf_sync_list(c492fb90,c44bdd00,255,14,0,...) at dbuf_sync_list+0xde Mar 19 10:59:32 xeon kernel: dnode_sync(c492fae0,c44bdd00,c4197878,c492fae0,10,...) at dnode_sync+0x3a8 Mar 19 10:59:32 xeon kernel: dmu_objset_sync_dnodes(c492f3a0,c44bdd00,b55,0,c48c9400,...) at dmu_objset_sync_dnodes+0x29 Mar 19 10:59:32 xeon kernel: dmu_objset_sync(c4197800,c48d1000,c44bdd00,c41a2000,0,...) at dmu_objset_sync+0x11d Mar 19 10:59:32 xeon kernel: dsl_pool_sync(c434ea00,b55,0,c41a2000,b55,...) at dsl_pool_sync+0x13e Mar 19 10:59:32 xeon kernel: spa_sync(c41a2000,b55,0,c434eaac,c0cb8db2,...) at spa_sync+0x33f Mar 19 10:59:32 xeon kernel: txg_sync_thread(c434ea00,e6952d38) at txg_sync_thread+0x183 Mar 19 10:59:32 xeon kernel: fork_exit(c0c889bc,c434ea00,e6952d38) at fork_exit+0xac Mar 19 10:59:32 xeon kernel: fork_trampoline() at fork_trampoline+0x8 Mar 19 10:59:32 xeon kernel: --- trap 0, eip =3D 0, esp =3D 0xe6952d70, ebp= =3D 0 --- Loading configuration files. No suitable dump device was found. Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: /dev/zvol/r4x320/swap: No sich file or directory Starting file system checks: Mar 19 10:59:32 xeon kernel: lock order reversal: Mar 19 10:59:32 xeon kernel: 1st 0xc60871e0 zfs:&db->db_mtx (zfs:&db->db_mtx) @ /usr/src/sys/modules/zfs/../../contrib/open Mar 19 10:59:32 xeon kernel: 2nd 0xc60411e8 zfs:&zp->z_lock (zfs:&zp->z_lock) @ /usr/src/sys/modules/zfs/../../contrib/open Mar 19 10:59:32 xeon kernel: KDB: stack backtrace: Mar 19 10:59:32 xeon kernel: db_trace_self_wrapper(c094c217) at db_trace_self_wrapper+0x25 Mar 19 10:59:32 xeon kernel: kdb_backtrace(0,ffffffff,c0a5b6e0,c0a5b578,c09f6eac,...) at kdb_backtrace+0x29 Mar 19 10:59:32 xeon kernel: witness_checkorder(c60411e8,9,c0cb9cda,49) at witness_checkorder+0x586 Mar 19 10:59:32 xeon kernel: _sx_xlock(c60411e8,c0cb9cda,49,c0cb5dd5,e69529d8,...) at _sx_xlock+0x3e Mar 19 10:59:32 xeon kernel: znode_pageout_func(c60871a4,c60411d8,c60871a4,e6952a04,c0c63d01,...) at znode_pageout_func+0x1 Mar 19 10:59:32 xeon kernel: dbuf_evict_user(c6087230,c60871a4,0,c566ee30,e6952a14,...) at dbuf_evict_user+0x31 Mar 19 10:59:32 xeon kernel: dbuf_clear(c60871a4,0,e6952ad4,c0c732bd,c60871a4,...) at dbuf_clear+0x1d Mar 19 10:59:32 xeon kernel: dbuf_evict(c60871a4,c60871e0,c0cb5dd5,1a1,c566ee18,...) at dbuf_evict+0xd Mar 19 10:59:32 xeon kernel: dnode_evict_dbufs(c566ecb0,0,255,28,0,...) at dnode_evict_dbufs+0x1fd Mar 19 10:59:32 xeon kernel: dnode_sync(c566ecb0,c5f37600,c4bb54c8,c566ecb0,20,...) at dnode_sync+0x257 Mar 19 10:59:32 xeon kernel: dmu_objset_sync_dnodes(c4b5f3a0,c5f37600,b56,0,c460bc00,...) at dmu_objset_sync_dnodes+0x29 Mar 19 10:59:32 xeon kernel: dmu_objset_sync(c4bb5400,c47bb400,c5f37600,c434eb4c,c4197800,...) at dmu_objset_sync+0x112 Mar 19 10:59:32 xeon kernel: dsl_pool_sync(c434ea00,b56,0,c41a2000,b56,...) at dsl_pool_sync+0x6d Mar 19 10:59:32 xeon kernel: spa_sync(c41a2000,b56,0,c434eaac,c0cb8db2,...) at spa_sync+0x33f Mar 19 10:59:32 xeon kernel: txg_sync_thread(c434ea00,e6952d38) at txg_sync_thread+0x183 Mar 19 10:59:32 xeon kernel: fork_exit(c0c889bc,c434ea00,e6952d38) at fork_exit+0xac Mar 19 10:59:32 xeon kernel: fork_trampoline() at fork_trampoline+0x8 Mar 19 10:59:32 xeon kernel: --- trap 0, eip =3D 0, esp =3D 0xe6952d70, ebp= =3D 0 --- Mounting local file systems:. Mar 19 10:59:32 xeon kernel: lock order reversal: Mar 19 10:59:32 xeon kernel: 1st 0xc0a4bccc GEOM topology (GEOM topology) @ /usr/src/sys/modules/zfs/../../contrib/opensola Mar 19 10:59:32 xeon kernel: 2nd 0xc0cc9d50 zfs:&spa_namespace_lock (zfs:&spa_namespace_lock) @ /usr/src/sys/modules/zfs/.. Mar 19 10:59:32 xeon kernel: KDB: stack backtrace: Mar 19 10:59:32 xeon kernel: db_trace_self_wrapper(c094c217) at db_trace_self_wrapper+0x25 Mar 19 10:59:32 xeon kernel: kdb_backtrace(0,ffffffff,c0a5cb80,c0a5be10,c09f6eac,...) at kdb_backtrace+0x29 Mar 19 10:59:32 xeon kernel: witness_checkorder(c0cc9d50,9,c0cb70e1,33c) at witness_checkorder+0x586 Mar 19 10:59:32 xeon kernel: _sx_xlock(c0cc9d50,c0cb70e1,33c,0,0,...) at _sx_xlock+0x3e Mar 19 10:59:32 xeon kernel: spa_open_common(c0cb3bcb,0,c0cb3bcb,c144eba0,0,...) at spa_open_common+0x46 Mar 19 10:59:32 xeon kernel: dsl_dir_open_spa(0,c5cc9000,c0cb3c79,e67cfaec,e67cfaf0,...) at dsl_dir_open_spa+0x58 Mar 19 10:59:32 xeon kernel: dsl_dataset_open_spa(0,c5cc9000,2,c43523b0,e67cfb40,...) at dsl_dataset_open_spa+0x28 Mar 19 10:59:32 xeon kernel: dsl_dataset_open(c5cc9000,2,c43523b0,e67cfb40,8,...) at dsl_dataset_open+0x16 Mar 19 10:59:32 xeon kernel: dmu_objset_open(c5cc9000,3,2,e67cfb84,11,...) at dmu_objset_open+0x25 Mar 19 10:59:32 xeon kernel: zvol_create_minor(c5cc9000,c4373200,e67cfbf4,c0ca7988,c5cc9000,...) at zvol_create_minor+0x152 Mar 19 10:59:32 xeon kernel: zfs_ioc_create_minor(c5cc9000,0,cef45a17,c4eef438,e67cfc24,...) at zfs_ioc_create_minor+0x12 Mar 19 10:59:32 xeon kernel: zfsdev_ioctl(c4373200,cef45a17,c5cc9000,3,c44f11b0,...) at zfsdev_ioctl+0x84 Mar 19 10:59:32 xeon kernel: devfs_ioctl_f(c4eef438,cef45a17,c5cc9000,c3f08900,c44f11b0) at devfs_ioctl_f+0xaf Mar 19 10:59:32 xeon kernel: kern_ioctl(c44f11b0,3,cef45a17,c5cc9000) at kern_ioctl+0x1ae Mar 19 10:59:32 xeon kernel: ioctl(c44f11b0,e67cfd00) at ioctl+0xf1 Mar 19 10:59:32 xeon kernel: syscall(e67cfd38) at syscall+0x252 Mar 19 10:59:32 xeon kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Mar 19 10:59:32 xeon kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x281976eb, esp =3D 0xbfbfc70c, ebp =3D 0xbfbfd638 - Mar 19 10:59:32 xeon kernel: em0: link state changed to UP Mar 19 10:59:32 xeon root: /etc/rc: WARNING: Dump device does not exist. Savecore not run. --=20 Joao Barros From owner-freebsd-fs@FreeBSD.ORG Sat Apr 14 14:50:25 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 AD9C716A406 for ; Sat, 14 Apr 2007 14:50:25 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6B5AC13C489 for ; Sat, 14 Apr 2007 14:50:25 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HcjZi-0002rK-KF for freebsd-fs@freebsd.org; Sat, 14 Apr 2007 16:50:02 +0200 Received: from n220246159048.netvigator.com ([220.246.159.48]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Apr 2007 16:50:02 +0200 Received: from gmane by n220246159048.netvigator.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Apr 2007 16:50:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Daniel Cheng Date: Sat, 14 Apr 2007 22:47:11 +0800 Lines: 29 Message-ID: References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU> <20070412073605.GB834@turion.vk2pj.dyndns.org> <86ps6aht1i.fsf@dwp.des.no> <20070412160603.GB92079@keira.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=Big5-HKSCS Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: n220246159048.netvigator.com User-Agent: Icedove 1.5.0.10 (X11/20070329) In-Reply-To: <20070412160603.GB92079@keira.kiwi-computer.com> Sender: news Cc: freebsd-current@freebsd.org Subject: Re: ZFS committed to the FreeBSD base. 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, 14 Apr 2007 14:50:25 -0000 Rick C. Petty wrote: > On Thu, Apr 12, 2007 at 10:54:17AM +0200, Dag-Erling Sm?rgrav wrote: >> Our native atomic operations are all defined as either macros or >> static inline functions in machine/atomic.h, so we can easily make >> this choice at compile time based on a config option. > > Is there any way we could make the choice at boot time, by checking for > presence of the CX8 feature? Either as something like: > > extern int feature_cx8; /* or MIB variable */ > #define CMPXCHG8(a) (feature_cx8 ? { _asm "..." } : emulate_cmpxch8(a)) > In Linux, Two copies of code are compiled: one with cmpxch8, one without. They are placed into different sections. When the computer boot up, it choose the best code, update the pointers then free the unused codes memory. > Otherwise something like ZFS which utilizes this feature a lot could > check the MIB variable and set different fn ptr in its device structure, > or something along those lines. Of course, that would require compiling > the same code twice essentially, but it had the advantage that it would > work on non-CX8 systems and that it would be fast on systems with CX8. > > -- Rick C. Petty -- From owner-freebsd-fs@FreeBSD.ORG Sat Apr 14 20:03:26 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 6518916A40E for ; Sat, 14 Apr 2007 20:03:26 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mail.atsec.com (mail.atsec.com [195.30.252.105]) by mx1.freebsd.org (Postfix) with ESMTP id A5B9913C4C5 for ; Sat, 14 Apr 2007 20:03:25 +0000 (UTC) (envelope-from se@freebsd.org) Received: (qmail 6014 invoked by uid 10125); 14 Apr 2007 20:03:24 -0000 X-SpaceNet-Virusscan: Sophos Version: 4.13; Last IDE Update: 2007-04-14 04:30 no information about results Received: from p5087934c.dip0.t-ipconnect.de (HELO ?192.168.0.12?) (80.135.147.76) by mail.atsec.com with SMTP; 14 Apr 2007 20:03:24 -0000 X-SpaceNet-Authentification: SMTP AUTH verified Message-ID: <46213380.1050209@FreeBSD.org> Date: Sat, 14 Apr 2007 22:03:12 +0200 From: Stefan Esser User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070409011723.GB74547@garage.freebsd.pl> <20070409094319.GB76673@garage.freebsd.pl> <46209D21.2010704@FreeBSD.org> <20070414102313.GC10527@garage.freebsd.pl> In-Reply-To: <20070414102313.GC10527@garage.freebsd.pl> X-Enigmail-Version: 0.94.1.2.0 X-Enigmail-Version: 0.94.1.2.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Stefan Esser Subject: Re: ZFS: amd64, devd, root file system. 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, 14 Apr 2007 20:03:26 -0000 Pawel Jakub Dawidek wrote: > On Sat, Apr 14, 2007 at 11:21:37AM +0200, Stefan Esser wrote: >> It is amazingly simple to get a test setup going and it worked fine >> in my initial simple test cases. But now I've run into problems that >> probably are not technical but caused by a lack of understanding ... > > This is not the first report that it doesn't work as it should. One was > that /boot/defaults/loader.conf wasn't fresh enough, and there were no: Hi Pawel, thanks for the reply, I got it working with some effort, see below ... > zpool_cache_load="YES" This is apparently implied by zfs_load="YES" and redundant. > zpool_cache_type="/boot/zfs/zpool.cache" > zpool_cache_name="/boot/zfs/zpool.cache" These are defined in /boot/defaults/loader.conf ... > lines at the end. Can you verify you have them? > > Can you send me log of full boot process? I even performed a "boot -v" but did not see anything useful. But a "zpool status" gave: pool: test state: UNAVAIL status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-D3 scrub: none requested config: NAME STATE READ WRITE CKSUM test UNAVAIL 0 0 0 insufficient replicas ad0s2 UNAVAIL 0 0 0 cannot open This could be fixed by exporting and then importing the pool (with -f). There after the pool could be mounted and I could manually set up the complete file system hierarchy. I verified that "/boot/zfs/zpool.cache" was updated during the import (written to the boot partition), but the next reboot failed again and I again got the same error status as shown above. I made an attempt to fix it by creating another pool on an (during the tests) unused swap partition on my "normal" UFS system disk (which I had made an IDE slave for these tests). After copying the necessary files over to the newly created "test2" pool on the SWAP partition I got a system that mounted "zfs:test2" and that just worked ... Not working: zpool create test ad0s2 Working: zpool create test2 ad1s1b (I.e. "test2" could be mounted automatically, while "test" required me to boot with an UFS root and to export/import the pool before it could be manually mounted.) Well, after some more testing I destroyed the pool "test" and created it on "ad0s2c" instead of "ad0s2", and voila, I had my problem solved. It appears, that a zpool can be manually mounted if it resides on ad0s2, but in order to make the kernel accept it during boot, it must be in a BSD partition. Does that make sense? (I did not want to try again with another pool in a slice, since I did not want to give up what I had just achieved with so much effort ;-) >> Hmmm, there are a few points that I do not fully understand: >> >> It seems that ZFS "legacy" mounts are not supported under FreeBSD, >> is this correct? (E.g. if I enter "zfs set mountpoint=legacy test" >> then "test" can not be mounted with "zfs mount test" and there is >> no other way to mount it since we do not have a "mount_zfs", yet?) > > They are supported. "legacy" means that you no longer use 'zfs mount' to > mount them, but simply mount(8) (or /etc/fstab). There is no mount_zfs > and there won't be one, because we are moving away from such commands. > You should use 'mount -t zfs' instead. Hmmm, didn't work during some of my tests, but does work now ... This is very nice! >> I tried to set the mountpoint of my to-be root file system to "/" >> with "zfs set mountpoint=/ test" but I'm under the impression that >> this does not really work. Setting it to "//" does appear to have >> the desired effect, though, but may lead to a panic during shutdown. >> (Sorry, I've got no core-dumps but could try producing one later >> if there is interest. The panic is because of a ref count becoming >> negative but I did not write down the message.) > > The mount point can be set to whatever you like, but you can still mount > it using different mount point by hand (via mount(8)). > The most proper way is probably to set mountpoint to "legacy". Ok, this will come next when I have some more spare time (next weekend), I guess. For now I'm testing the system and then I'll decide whether I'll keep it running with ZFS or reconnect the UFS disk that currently is stored in a save place. I think we need a handbook section for ZFS and it could suggest reasonable choices for FreeBSD. >> I decided to have multiple zfs file systems (test/var, test/usr ...) >> and can see them with zfs list. What is the correct way to get them >> mounted automatically? (Assuming I get the problem to have the kernel >> automatically mount the ZFS root solved ...) > > zfs_enable="YES" in your /etc/rc.conf. Yes, that one I got (together with zfs_load="YES" in loader.conf). >> Do I need fstab entries for for ZFS file systems (e.g. "test/usr") >> or does ZFS mount them automatically when the pool "test" is mounted? > > They are mount via rc.d/zfs script. Oh well, I should have looked there instead of asking ;-) Hmmm, I assume that "zfs mount -a" will ignore file systems that are marked as "legacy", and those will instead mounted together with other local file systems? >> Or do I need a fstab line for each of them? >> What's supposed to go into /etc/zfs, besides the ZFS exports file? > > For now only exports file. zpool.cache use to be there as well, but we > need it in /boot/zfs/ to be able to have root-on-ZFS. Yes, I see. It might be useful to make zpool.cache available in /etc/zfs via a symlink, but this might also cause confusion or inconsistencies and I see good reasons to maintain that file in /boot/zfs. Ok, it took me quite a few hours to get ZFS installed the way I wanted it, and it seems that ad0s2 and ad0s2c are quite different with regard to their suitability to hold ZFS pools. Was this to be expected? Or is the diagnosis wrong and something else is responsible that it works for me, now? Regards, STefan From owner-freebsd-fs@FreeBSD.ORG Sat Apr 14 20:29:01 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org 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 D161116A402; Sat, 14 Apr 2007 20:29:01 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 4122413C45A; Sat, 14 Apr 2007 20:29:00 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id AD78348809; Sat, 14 Apr 2007 22:28:59 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 24E0748800; Sat, 14 Apr 2007 22:28:51 +0200 (CEST) Date: Sat, 14 Apr 2007 22:28:31 +0200 From: Pawel Jakub Dawidek To: Stefan Esser Message-ID: <20070414202831.GI10527@garage.freebsd.pl> References: <20070409011723.GB74547@garage.freebsd.pl> <20070409094319.GB76673@garage.freebsd.pl> <46209D21.2010704@FreeBSD.org> <20070414102313.GC10527@garage.freebsd.pl> <46213380.1050209@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dMdWWqg3F2Dv/qfw" Content-Disposition: inline In-Reply-To: <46213380.1050209@FreeBSD.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS: amd64, devd, root file system. 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, 14 Apr 2007 20:29:01 -0000 --dMdWWqg3F2Dv/qfw Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 14, 2007 at 10:03:12PM +0200, Stefan Esser wrote: > Pawel Jakub Dawidek wrote: > > On Sat, Apr 14, 2007 at 11:21:37AM +0200, Stefan Esser wrote: > >> It is amazingly simple to get a test setup going and it worked fine > >> in my initial simple test cases. But now I've run into problems that > >> probably are not technical but caused by a lack of understanding ... > >=20 > > This is not the first report that it doesn't work as it should. One was > > that /boot/defaults/loader.conf wasn't fresh enough, and there were no: >=20 > Hi Pawel, >=20 > thanks for the reply, I got it working with some effort, see below ... >=20 > > zpool_cache_load=3D"YES" >=20 > This is apparently implied by zfs_load=3D"YES" and redundant. No, it isn't. It is absolutely necessary. > > zpool_cache_type=3D"/boot/zfs/zpool.cache" > > zpool_cache_name=3D"/boot/zfs/zpool.cache" >=20 > These are defined in /boot/defaults/loader.conf ... zpool_cache_load=3D"YES" should be as well. I hope you didn't change it. You should not need to touch /boot/defaults/loader.conf. > This could be fixed by exporting and then importing the pool (with -f). > There after the pool could be mounted and I could manually set up the > complete file system hierarchy. I verified that "/boot/zfs/zpool.cache" > was updated during the import (written to the boot partition), but the > next reboot failed again and I again got the same error status as shown > above. Are you sure the updated file is the same file which is loaded on boot? > I made an attempt to fix it by creating another pool on an (during the > tests) unused swap partition on my "normal" UFS system disk (which I > had made an IDE slave for these tests). After copying the necessary > files over to the newly created "test2" pool on the SWAP partition I > got a system that mounted "zfs:test2" and that just worked ... >=20 > Not working: zpool create test ad0s2 > Working: zpool create test2 ad1s1b >=20 > (I.e. "test2" could be mounted automatically, while "test" required me > to boot with an UFS root and to export/import the pool before it could > be manually mounted.) >=20 > Well, after some more testing I destroyed the pool "test" and created > it on "ad0s2c" instead of "ad0s2", and voila, I had my problem solved. >=20 > It appears, that a zpool can be manually mounted if it resides on ad0s2, > but in order to make the kernel accept it during boot, it must be in a > BSD partition. Does that make sense? (I did not want to try again with > another pool in a slice, since I did not want to give up what I had just > achieved with so much effort ;-) I'm sorry, but it doesn't make sense at all:) All GEOM providers should be equal for ZFS, no matter if this is disk, slice, partition, mirror, encrypted provider or anything else. > >> Do I need fstab entries for for ZFS file systems (e.g. "test/usr") > >> or does ZFS mount them automatically when the pool "test" is mounted? > >=20 > > They are mount via rc.d/zfs script. >=20 > Oh well, I should have looked there instead of asking ;-) > Hmmm, I assume that "zfs mount -a" will ignore file systems that are > marked as "legacy", and those will instead mounted together with other > local file systems? That's right. > > For now only exports file. zpool.cache use to be there as well, but we > > need it in /boot/zfs/ to be able to have root-on-ZFS. >=20 > Yes, I see. It might be useful to make zpool.cache available in /etc/zfs > via a symlink, but this might also cause confusion or inconsistencies > and I see good reasons to maintain that file in /boot/zfs. Hmm? What for do you need zpool.cache in /etc/zfs/? This file is for ZFS internal use only, I see no reason to symlink it or do anything with it. ZFS should work in the way that you shouldn't even know it exists and we should be moving into that direction:) > Ok, it took me quite a few hours to get ZFS installed the way I wanted > it, and it seems that ad0s2 and ad0s2c are quite different with regard > to their suitability to hold ZFS pools. Was this to be expected? >=20 > Or is the diagnosis wrong and something else is responsible that it > works for me, now? I don't know what was the reason, but ad0s2/ad0s2c should make no difference... --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --dMdWWqg3F2Dv/qfw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGITlvForvXbEpPzQRAma9AKD3VIafQ1xuDXPQ7xZreJBB5EqCoACcC0UL fMNZZ/awX8I2HD816S/q0jo= =gc7I -----END PGP SIGNATURE----- --dMdWWqg3F2Dv/qfw-- From owner-freebsd-fs@FreeBSD.ORG Sat Apr 14 22:19:30 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 D43A416A420 for ; Sat, 14 Apr 2007 22:19:30 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mail.atsec.com (mail.atsec.com [195.30.252.105]) by mx1.freebsd.org (Postfix) with ESMTP id DBFAA13C46E for ; Sat, 14 Apr 2007 22:19:29 +0000 (UTC) (envelope-from se@freebsd.org) Received: (qmail 18617 invoked by uid 10125); 14 Apr 2007 22:19:28 -0000 X-SpaceNet-Virusscan: Sophos Version: 4.13; Last IDE Update: 2007-04-14 04:30 no information about results Received: from p5087934c.dip0.t-ipconnect.de (HELO ?192.168.0.12?) (80.135.147.76) by mail.atsec.com with SMTP; 14 Apr 2007 22:19:28 -0000 X-SpaceNet-Authentification: SMTP AUTH verified Message-ID: <46215363.8020402@FreeBSD.org> Date: Sun, 15 Apr 2007 00:19:15 +0200 From: Stefan Esser User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20070409011723.GB74547@garage.freebsd.pl> <20070409094319.GB76673@garage.freebsd.pl> <46209D21.2010704@FreeBSD.org> <20070414102313.GC10527@garage.freebsd.pl> <46213380.1050209@FreeBSD.org> <20070414202831.GI10527@garage.freebsd.pl> In-Reply-To: <20070414202831.GI10527@garage.freebsd.pl> X-Enigmail-Version: 0.94.1.2.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ZFS: amd64, devd, root file system. 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, 14 Apr 2007 22:19:30 -0000 Pawel Jakub Dawidek wrote: > On Sat, Apr 14, 2007 at 10:03:12PM +0200, Stefan Esser wrote: >> Pawel Jakub Dawidek wrote: >>> On Sat, Apr 14, 2007 at 11:21:37AM +0200, Stefan Esser wrote: >>>> It is amazingly simple to get a test setup going and it worked fine >>>> in my initial simple test cases. But now I've run into problems that >>>> probably are not technical but caused by a lack of understanding ... >>> This is not the first report that it doesn't work as it should. One was >>> that /boot/defaults/loader.conf wasn't fresh enough, and there were no: >> Hi Pawel, >> >> thanks for the reply, I got it working with some effort, see below ... >> >>> zpool_cache_load="YES" >> This is apparently implied by zfs_load="YES" and redundant. > > No, it isn't. It is absolutely necessary. > >>> zpool_cache_type="/boot/zfs/zpool.cache" >>> zpool_cache_name="/boot/zfs/zpool.cache" >> These are defined in /boot/defaults/loader.conf ... > > zpool_cache_load="YES" should be as well. I hope you didn't change it. > You should not need to touch /boot/defaults/loader.conf. Yes, it is there, I did not change it but missed it when I looked up the other default values. (All files in /{boot,etc}/defaults/ are unmodified and from a very recent -current.) >> This could be fixed by exporting and then importing the pool (with -f). >> There after the pool could be mounted and I could manually set up the >> complete file system hierarchy. I verified that "/boot/zfs/zpool.cache" >> was updated during the import (written to the boot partition), but the >> next reboot failed again and I again got the same error status as shown >> above. > > Are you sure the updated file is the same file which is loaded on boot? Yes, definitely, literally tens of times (I checked the modification date and verified the readable parts matched what I changed, e.g. that the pool name and underlying device where there). One of the problems that I encountered was that mounting /boot (in my recovery root) R/W meant that I could not later mount it within the ZFS root (after the export/import of the pool). But I got around this problem and I'm quite sure that /boot/zfs/zpool.cache was written to and that this file was loaded with the kernel and the zfs module. >> I made an attempt to fix it by creating another pool on an (during the >> tests) unused swap partition on my "normal" UFS system disk (which I >> had made an IDE slave for these tests). After copying the necessary >> files over to the newly created "test2" pool on the SWAP partition I >> got a system that mounted "zfs:test2" and that just worked ... >> >> Not working: zpool create test ad0s2 >> Working: zpool create test2 ad1s1b >> >> (I.e. "test2" could be mounted automatically, while "test" required me >> to boot with an UFS root and to export/import the pool before it could >> be manually mounted.) >> >> Well, after some more testing I destroyed the pool "test" and created >> it on "ad0s2c" instead of "ad0s2", and voila, I had my problem solved. >> >> It appears, that a zpool can be manually mounted if it resides on ad0s2, >> but in order to make the kernel accept it during boot, it must be in a >> BSD partition. Does that make sense? (I did not want to try again with >> another pool in a slice, since I did not want to give up what I had just >> achieved with so much effort ;-) > > I'm sorry, but it doesn't make sense at all:) All GEOM providers should > be equal for ZFS, no matter if this is disk, slice, partition, mirror, > encrypted provider or anything else. Yes, I had read this and for that reason never bothered to change the underlying device. But when I just created a pool in ad1s1b I could enter zfs:test2 at the prompt (after zfs:test had not been found). This was absolutely reproducible (with the boot then failing on test2 since it did not contain a /dev for the devfs mount in the beginning). This made me suspicious and I prepared a ZFS root in test2. That worked, but since it was on the wrong disk (to be removed from the system), I tried to destroy the pool "test" and then created it again on ad0s2. It did fail with identical problems (could be manually mounted but not during the automatic root mount step while booting). Then I made another try and destroyed test and created it on ad0s2c and found that it worked without problem there after. >>>> Do I need fstab entries for for ZFS file systems (e.g. "test/usr") >>>> or does ZFS mount them automatically when the pool "test" is mounted? >>> They are mount via rc.d/zfs script. >> Oh well, I should have looked there instead of asking ;-) >> Hmmm, I assume that "zfs mount -a" will ignore file systems that are >> marked as "legacy", and those will instead mounted together with other >> local file systems? > > That's right. > >>> For now only exports file. zpool.cache use to be there as well, but we >>> need it in /boot/zfs/ to be able to have root-on-ZFS. >> Yes, I see. It might be useful to make zpool.cache available in /etc/zfs >> via a symlink, but this might also cause confusion or inconsistencies >> and I see good reasons to maintain that file in /boot/zfs. > > Hmm? What for do you need zpool.cache in /etc/zfs/? This file is for ZFS > internal use only, I see no reason to symlink it or do anything with it. > ZFS should work in the way that you shouldn't even know it exists and we > should be moving into that direction:) No, I do not need it there ... But /etc/zfs appears to be the logical place (if it was not required for booting). I assume that zpool.cache preserves the pool information over reboots and is not specifically used for the ZFS root configuration (and thus could be in /etc/zfs, if support of a ZFS root was not desirable). >> Ok, it took me quite a few hours to get ZFS installed the way I wanted >> it, and it seems that ad0s2 and ad0s2c are quite different with regard >> to their suitability to hold ZFS pools. Was this to be expected? >> >> Or is the diagnosis wrong and something else is responsible that it >> works for me, now? > > I don't know what was the reason, but ad0s2/ad0s2c should make no > difference... Well, it did in my case, but I'm not going to try it with ad0s2 again right now (ENOTIME). I can not explain it, but ad0s2c made it work for me instantly, while a pool on ad0s2 always resulted in the FAULTED state of the pool because the device ad0s2 could not be opened (see output from "zpool status" in previous mail). My disk drive is partitioned this way: da0 da0s1 (type 165) da0s1a 256MB da0s1b 768MB da0s1c 1024MB (overlapping a and b) da0s2 (type 165) da0s2c 300GB (rest of disk) Regards, STefan