From owner-freebsd-fs@FreeBSD.ORG Sun Jan 16 11:00:35 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 534261065696 for ; Sun, 16 Jan 2011 11:00:35 +0000 (UTC) (envelope-from znek@mulle-kybernetik.com) Received: from muller.mulle-kybernetik.com (port-212-202-151-204.static.qsc.de [212.202.151.204]) by mx1.freebsd.org (Postfix) with ESMTP id 61F948FC12 for ; Sun, 16 Jan 2011 11:00:33 +0000 (UTC) Received: (qmail 77928 invoked from network); 16 Jan 2011 11:00:30 -0000 Received: from unknown (HELO zoidberg.air.z.net) (znek@78.94.79.22) by mail.mulle-kybernetik.com with AES128-SHA encrypted SMTP; 16 Jan 2011 11:00:30 -0000 Mime-Version: 1.0 (Apple Message framework v1082) From: =?iso-8859-1?Q?Marcus_M=FCller?= In-Reply-To: Date: Sun, 16 Jan 2011 12:00:29 +0100 Message-Id: <161324AD-8882-4858-9ABF-3677F708D00B@mulle-kybernetik.com> References: <37C1E643-C7A9-4061-8316-281819AC947E@mulle-kybernetik.com> To: "Ronald Klop" X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: Multiple ZFS pools and booting 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, 16 Jan 2011 11:00:35 -0000 Hi Ronald, > Shouldn't you set the boot device in /boot/loader.conf? > I have this line: > vfs.root.mountfrom=3D"zfs:zroot" that's just about setting the root partition (what get's mounted as = "/"). Interestingly, its mountpoint property doesn't have to be "/", = thus you can have any ZFS filesystem mounted as root (given, that its = contents are suitable for this). My question was more or less from which pool /boot/loader.conf is read = from initially. I suspect that the order of pools on a single disk is = sequentially read, starting from the first partition. In the meantime I've created a virtual machine with the same setup as my = server. I can confirm that any exported or destroyed pools are not = tested, which is as I expected. The only question I have left now is if there is any option/property to = skip an imported pool from being used as a pool to boot from? Cheers, Marcus --=20 Marcus Mueller . . . crack-admin/coder ;-) Mulle kybernetiK . http://www.mulle-kybernetik.com Current projects: http://www.mulle-kybernetik.com/znek/ From owner-freebsd-fs@FreeBSD.ORG Sun Jan 16 19:07:25 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0002106566C for ; Sun, 16 Jan 2011 19:07:24 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 978778FC15 for ; Sun, 16 Jan 2011 19:07:24 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 866AF45E9D; Sun, 16 Jan 2011 20:07:21 +0100 (CET) Received: from localhost (89-73-192-49.dynamic.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4188645E49; Sun, 16 Jan 2011 20:07:16 +0100 (CET) Date: Sun, 16 Jan 2011 20:07:02 +0100 From: Pawel Jakub Dawidek To: Marcus =?iso-8859-1?Q?M=FCller?= Message-ID: <20110116190702.GD82886@garage.freebsd.pl> References: <37C1E643-C7A9-4061-8316-281819AC947E@mulle-kybernetik.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <37C1E643-C7A9-4061-8316-281819AC947E@mulle-kybernetik.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: Multiple ZFS pools and booting 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, 16 Jan 2011 19:07:25 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 14, 2011 at 02:31:11PM +0100, Marcus M=FCller wrote: > Hi all, >=20 > I have a single harddrive with GPT partitioning: >=20 > root@muller:(~)# gpart show > =3D> 34 234441581 ad10 GPT (112G) > 34 128 1 freebsd-boot (64K) > 162 8388608 2 freebsd-swap (4.0G) > 8388770 10485760 3 freebsd-zfs (5.0G) > 18874530 10485760 4 freebsd-zfs (5.0G) > 29360290 102540662 5 freebsd-zfs (49G) > 131900952 102540662 6 freebsd-zfs (49G) > 234441614 1 - free - (512B) >=20 > ad10p3/ad10p4 (tank) and ad10p5/ad10p6 (muller) are two mirror zpools. Th= e root filesystem currently resides on tank. >=20 > I wanted to migrate the root filesystem from tank to muller by changing t= he mountpoints accordingly and resetting the bootfs zpool propery on tank l= ike this: >=20 > root@muller:(~)# zpool get bootfs muller > NAME PROPERTY VALUE SOURCE > muller bootfs muller/roots/8-current local > root@muller:(~)# zpool set bootfs=3D tank > root@muller:(~)# zpool get bootfs tank > NAME PROPERTY VALUE SOURCE > tank bootfs - default >=20 > But when I reboot, BTX loader tries to access tank:/boot/kernel/kernel. >=20 > Why does the loader care about tank at all, after I "removed" the bootfs = property? > Do I have to export tank before I reboot? > How do I tell the loader to just care about muller for booting? There is no way to configure that at this point. The boot code just boots off of first pool it finds - if there is no bootfs property then it will just try to boot from the top level dataset (ie. tank). What you could try is to add /tank/boot.config file containing: muller:/boot/loader and if that doesn't work: muller/roots/8-current:/boot/loader and if that doesn't work I don't know of any other solutions. Exporting the tank pool will work (for now), but it looks like it will be changed to accept exported pools for booting and skip only destroyed pools. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk0zQdYACgkQForvXbEpPzSuHQCg0vp7WzciuIV/6om3Rbp+ipIH gJ8AoMD2Sj/HkRlJkxhM3r4/vzhqPDPf =idaA -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From owner-freebsd-fs@FreeBSD.ORG Sun Jan 16 20:22:52 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0CFA1065675 for ; Sun, 16 Jan 2011 20:22:52 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id C082A8FC0A for ; Sun, 16 Jan 2011 20:22:52 +0000 (UTC) Received: by pzk32 with SMTP id 32so759825pzk.13 for ; Sun, 16 Jan 2011 12:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding; bh=WY3SUEtTL0fb/Htw1RsgF4N5F886qCQApxtrzbBKV1w=; b=QIQMJCY3/7iFX+VgXSClaIdtM9jnDL3UxVwWowbYKs8ZG5CphULNbriRPc35hnqI9i /Ctq8Jx4mgB/whP9mfuvJJv8v6XVeE05uTK6AxK7WNRNdHJAJrVchBdblVzlkRa4DbCA a57+yeLbWuj1r1v2PUsZizXTpLUce16R2Cfqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; b=WGP57GH5AZ/FoqQftj9vk+afvGvrmZztHLum2MCELICjhWXFGlr0iDmQ5BD+yRkabi kBoz6WXBJqliByaXjHmorzkA3c3OTMUGL5yWQFaPbNQVUNnh9sYATqk4Feg8FmoWEmBj IGChEBbDJjdFxhtiSUB9s12iOyhYf1d0Lr92E= Received: by 10.142.237.13 with SMTP id k13mr2817507wfh.324.1295209372306; Sun, 16 Jan 2011 12:22:52 -0800 (PST) Received: from localhost (anonymizer5.torservers.net [174.36.199.202]) by mx.google.com with ESMTPS id w14sm5460858wfd.6.2011.01.16.12.22.49 (version=SSLv3 cipher=RC4-MD5); Sun, 16 Jan 2011 12:22:51 -0800 (PST) From: Anonymous To: Marcus =?utf-8?Q?M=C3=BCller?= References: <37C1E643-C7A9-4061-8316-281819AC947E@mulle-kybernetik.com> Date: Sun, 16 Jan 2011 23:22:28 +0300 In-Reply-To: <37C1E643-C7A9-4061-8316-281819AC947E@mulle-kybernetik.com> ("Marcus =?utf-8?Q?M=C3=BCller=22's?= message of "Fri, 14 Jan 2011 14:31:11 +0100") Message-ID: <86ei8cha4b.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Multiple ZFS pools and booting 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, 16 Jan 2011 20:22:53 -0000 Marcus M=C3=BCller writes: > I have a single harddrive with GPT partitioning: > > root@muller:(~)# gpart show > =3D> 34 234441581 ad10 GPT (112G) > 34 128 1 freebsd-boot (64K) > 162 8388608 2 freebsd-swap (4.0G) > 8388770 10485760 3 freebsd-zfs (5.0G) > 18874530 10485760 4 freebsd-zfs (5.0G) > 29360290 102540662 5 freebsd-zfs (49G) > 131900952 102540662 6 freebsd-zfs (49G) > 234441614 1 - free - (512B) > > ad10p3/ad10p4 (tank) and ad10p5/ad10p6 (muller) are two mirror > zpools. The root filesystem currently resides on tank. gptzfsboot skips any non-zfs partition type such as `freebsd-ufs'. Say, you want to boot from the pool on ad10p5 and $ gpart modify -t freebsd-ufs -i 3 ad10 $ gpart modify -t freebsd-ufs -i 4 ad10 should be enough. Does it work for you? From owner-freebsd-fs@FreeBSD.ORG Sun Jan 16 23:16:06 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F9DD106566B; Sun, 16 Jan 2011 23:16:06 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 464358FC13; Sun, 16 Jan 2011 23:16:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0GNG6nO055175; Sun, 16 Jan 2011 23:16:06 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0GNG6wX055171; Sun, 16 Jan 2011 23:16:06 GMT (envelope-from linimon) Date: Sun, 16 Jan 2011 23:16:06 GMT Message-Id: <201101162316.p0GNG6wX055171@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/153996: [zfs] zfs root mount error while kernel is not located in /boot/kernel 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, 16 Jan 2011 23:16:06 -0000 Old Synopsis: zfs root mount error while kernel is not located in /boot/kernel New Synopsis: [zfs] zfs root mount error while kernel is not located in /boot/kernel Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 16 23:15:52 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=153996 From owner-freebsd-fs@FreeBSD.ORG Mon Jan 17 01:28:00 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09813106564A for ; Mon, 17 Jan 2011 01:28:00 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id A7D9D8FC08 for ; Mon, 17 Jan 2011 01:27:59 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 93C5E45E49; Mon, 17 Jan 2011 02:27:57 +0100 (CET) Received: from localhost (89-73-192-49.dynamic.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 5BFCB45C9C; Mon, 17 Jan 2011 02:27:52 +0100 (CET) Date: Mon, 17 Jan 2011 02:27:39 +0100 From: Pawel Jakub Dawidek To: Emil Smolenski Message-ID: <20110117012739.GF82886@garage.freebsd.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ncSAzJYg3Aa9+CRW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: [ZFS] Booting from zpool created on 4k-sector drive 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, 17 Jan 2011 01:28:00 -0000 --ncSAzJYg3Aa9+CRW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 21, 2010 at 03:29:01PM +0100, Emil Smolenski wrote: > Hello, >=20 > There is a hack to force zpool creation with minimum sector size equal to= =20 > 4k: >=20 > # gnop create -S 4096 ${DEV0} > # zpool create tank ${DEV0}.nop > # zpool export tank > # gnop destroy ${DEV0}.nop > # zpool import tank >=20 > Zpool created this way is much faster on problematic 4k sector drives =20 > which lies about its sector size (like WD EARS). This hack works perfectl= y =20 > fine when system is running. Gnop layer is created only for "zpool create= " =20 > command -- ZFS stores information about sector size in its metadata. Afte= r =20 > zpool creation one can export the pool, remove gnop layer and reimport th= e =20 > pool. Difference can be seen in the output from the zdb command: >=20 > - on 512 sector device (2**9 =3D 512): > % zdb tank |grep ashift > ashift=3D9 >=20 > - on 4096 sector device (2**12 =3D 4096): > % zdb tank |grep ashift > ashift=3D12 >=20 > This change is permanent. The only possibility to change the value of =20 > ashift is: zpool destroy/create and restoring pool from backup. That's a nice hack:) > But there is one problem: I cannot boot from such pool. Error message: >=20 > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS > ZFS: unexpected object set type 0 Tracking it down and fixing took all my free time during this weekend, eh. I fixed this in ZFSv28 and I'm afraid I'm not going to backport the fix to ZFSv15, as I also did many other changes while working on this (booting off of RAIDZ3 is now supported, for example). Here is the patch if someone would like to try it: http://people.freebsd.org/~pjd/patches/zfs_boot_fixes.patch --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ncSAzJYg3Aa9+CRW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk0zmwoACgkQForvXbEpPzQLQwCgqb8zMFwJm7mTmwzk1nI3yqkb Vm8AoJuRxDdvk+b9PNbotrSiNiIwm+xT =9ECW -----END PGP SIGNATURE----- --ncSAzJYg3Aa9+CRW-- From owner-freebsd-fs@FreeBSD.ORG Mon Jan 17 08:40:14 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9CAA106566C for ; Mon, 17 Jan 2011 08:40:14 +0000 (UTC) (envelope-from znek@mulle-kybernetik.com) Received: from muller.mulle-kybernetik.com (port-212-202-151-204.static.qsc.de [212.202.151.204]) by mx1.freebsd.org (Postfix) with ESMTP id EDF4C8FC18 for ; Mon, 17 Jan 2011 08:40:13 +0000 (UTC) Received: (qmail 30820 invoked from network); 17 Jan 2011 08:40:11 -0000 Received: from unknown (HELO zoidberg.z.net) (znek@78.94.79.22) by mail.mulle-kybernetik.com with AES128-SHA encrypted SMTP; 17 Jan 2011 08:40:11 -0000 Mime-Version: 1.0 (Apple Message framework v1082) From: =?iso-8859-1?Q?Marcus_M=FCller?= In-Reply-To: <20110116190702.GD82886@garage.freebsd.pl> Date: Mon, 17 Jan 2011 09:40:06 +0100 Message-Id: <0F00C6FC-518D-43B7-BE95-65BB68E70211@mulle-kybernetik.com> References: <37C1E643-C7A9-4061-8316-281819AC947E@mulle-kybernetik.com> <20110116190702.GD82886@garage.freebsd.pl> To: Pawel Jakub Dawidek , Anonymous X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: Multiple ZFS pools and booting 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, 17 Jan 2011 08:40:14 -0000 Hi Pawel and Anonymous, > There is no way to configure that at this point. The boot code just > boots off of first pool it finds - if there is no bootfs property then > it will just try to boot from the top level dataset (ie. tank). >=20 > What you could try is to add /tank/boot.config file containing: >=20 > muller:/boot/loader >=20 > and if that doesn't work: >=20 > muller/roots/8-current:/boot/loader >=20 > and if that doesn't work I don't know of any other solutions. first thanks for finding the time to answer my question. I've mistaken = the "bootfs" property for a global switch indicating that one can boot = off this pool, as I somehow misinterpreted this troubleshooting section = [http://www.solarisinternals.com/wiki/index.php/ZFS_Troubleshooting_Guide#= Pool_Migration_Issues]. I guess a zpool boolean propery like = freebsd:canboot which defaults to YES would be a welcome enhancement. = Looking at the loader code I believe this isn't too trivial to = implement, though. > Exporting the tank pool will work (for now), but it looks like it will > be changed to accept exported pools for booting and skip only = destroyed > pools. I've read about this and was a bit worried as it would definitely screw = up my server setup. > gptzfsboot skips any non-zfs partition type such as `freebsd-ufs'. > Say, you want to boot from the pool on ad10p5 and >=20 > $ gpart modify -t freebsd-ufs -i 3 ad10 > $ gpart modify -t freebsd-ufs -i 4 ad10 >=20 > should be enough. Does it work for you? This hack does the trick! While I would certainly prefer a property = based solution, I'm fine now. Thanks! Cheers, Marcus --=20 Marcus Mueller . . . crack-admin/coder ;-) Mulle kybernetiK . http://www.mulle-kybernetik.com Current projects: http://www.mulle-kybernetik.com/znek/ From owner-freebsd-fs@FreeBSD.ORG Mon Jan 17 11:06:59 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5524F106564A for ; Mon, 17 Jan 2011 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 28C448FC18 for ; Mon, 17 Jan 2011 11:06:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0HB6x3H048878 for ; Mon, 17 Jan 2011 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0HB6wHi048876 for freebsd-fs@FreeBSD.org; Mon, 17 Jan 2011 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Jan 2011 11:06:58 GMT Message-Id: <201101171106.p0HB6wHi048876@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 11:06:59 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153847 fs [nfs] [panic] Kernel panic from incorrect m_free in nf o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153584 fs [ext2fs] [patch] Performance fix and cleanups for BSD o kern/153552 fs [zfs] zfsboot from 8.2-RC1 freeze at boot time o kern/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152488 fs [tmpfs] [patch] mtime of file updated when only inode o kern/152079 fs [msdosfs] [patch] Small cleanups from the other NetBSD o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o kern/151845 fs [smbfs] [patch] smbfs should be upgraded to support Un o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/151111 fs [zfs] vnodes leakage during zfs unmount o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/150207 fs zpool(1): zpool import -d /dev tries to open weird dev o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149022 fs [hang] File system operations hangs with suspfs state o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o bin/148296 fs [zfs] [loader] [patch] Very slow probe in /usr/src/sys o kern/148204 fs [nfs] UDP NFS causes overload o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147790 fs [zfs] zfs set acl(mode|inherit) fails on existing zfs o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server o kern/146375 fs [nfs] [patch] Typos in macro variables names in sys/fs s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an o bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c o kern/144458 fs [nfs] [patch] nfsd fails as a kld p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142914 fs [zfs] ZFS performance degradation over time o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142401 fs [ntfs] [patch] Minor updates to NTFS from NetBSD o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140134 fs [msdosfs] write and fsck destroy filesystem integrity o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [panic] panic: ffs_truncate: read-only filesystem o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [ffs] [snapshot] System crashes when manipulat o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o bin/94635 fs snapinfo(8)/libufs only works for disk-backed filesyst o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/33464 fs [ufs] soft update inconsistencies after system crash o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 218 problems total. From owner-freebsd-fs@FreeBSD.ORG Tue Jan 18 00:58:28 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98927106564A for ; Tue, 18 Jan 2011 00:58:28 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 274AC8FC12 for ; Tue, 18 Jan 2011 00:58:27 +0000 (UTC) Received: by wwi17 with SMTP id 17so2623489wwi.1 for ; Mon, 17 Jan 2011 16:58:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=YGPEL9Z0XVhMHMnZc59iz8H0wJr0XgmZsFM8hbPdreg=; b=tE2/ak0shAnAL9LGX0aPnIBvGkGk4QG+ceRby2OB/KQK+MZeRj/n70GlYLTqD+OPAN ykH3QIqGIDslWOzHHe8X0UPauxvUkSLA30jlE+9lb0xxBbiwita39WEkikccMXxqhyEX RgzGrwTGiKgxMR17s0Waz60h+prb12EQFVklI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=jLnK3bTlYt3P3bWRYLNeLITsxPfUeLzLoik2ppt9NJFx+OuqXhT2QF8LsKRkoAeOiz uzu95aDe4oYDcWcAGMVeyLNKw7U9CFrkBUnfH6sGdFW0XS3IJF6SbzFVQgDGzfE80gzj yAVYqzohzMor6/bwV6Owbmb0zWznpnmv2jpLA= MIME-Version: 1.0 Received: by 10.216.78.146 with SMTP id g18mr4072126wee.1.1295310739028; Mon, 17 Jan 2011 16:32:19 -0800 (PST) Received: by 10.216.254.226 with HTTP; Mon, 17 Jan 2011 16:32:18 -0800 (PST) Date: Mon, 17 Jan 2011 16:32:18 -0800 Message-ID: From: Garrett Cooper To: fs@freebsd.org Content-Type: multipart/mixed; boundary=000e0cdfd8f8794ebc049a140808 Cc: Subject: Inconsistency and bug with *chflags functions 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, 18 Jan 2011 00:58:28 -0000 --000e0cdfd8f8794ebc049a140808 Content-Type: text/plain; charset=ISO-8859-1 Hi FS folks, Originally I did this to determine why lchflags had an int argument and chflags/fchflags had unsigned long arguments, and I ran into an interesting mini-project (by accident) after I found a few bugs lurking in the vfs_syscalls.c layer of the kernel. So here's the deal... Problems: 1. chflags/fchflags claim that the flags argument is an unsigned long, whereas lchflags claims it's an int. This is inconsistent. 2. The kernel interfaces are all implicitly downcasting the flags argument to int. 3. There's a sizing/signedness discrepancy in a few other structures with fixed-width data types (uint32_t). Solution: 1. I opted to convert fflags_t to uint32_t and convert all references which did direct conversions to and from st_flags to fflags_t to avoid 32-bit / 64-bit biarch issues. I downgraded it to uint32_t as we're no where near the limit for the number of usable flags to *chflags(2). 2. *chflags now uses fflags_t instead of int/unsigned long. 3. c_file_flags in dumprestore.h was changed to be in sync with st_flags. 4. di_flags in ufs/ufs/dinode.h was changed to be in sync with st_flags. Compatibility: 1. NetBSD uses unsigned long in their chflags calls (both in kernel and userland) so they're more consistent than we are by not having mixed flags calling convention like us, but uses uint32_t in their data structures (like we do), so they have a 32-bit/64-bit biarch bug (again like we do). 2. OpenBSD is using unsigned int, so I assume that their kernel layer is also using unsigned int (I am basing this purely off the manpage as I haven't looked at their sources, but I could be wrong). I'm running make universe just to see if it will barf in the build, but would someone please review this change (I made the change as minimal as possible for ease of review) and provide feedback? Thanks, -Garrett PS Please CC me on all replies as I'm not subscribed to the list. --000e0cdfd8f8794ebc049a140808 Content-Type: text/x-patch; charset=US-ASCII; name="chflags-to-fflags_t-fix.patch" Content-Disposition: attachment; filename="chflags-to-fflags_t-fix.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gj22gzh91 SW5kZXg6IGluY2x1ZGUvcHJvdG9jb2xzL2R1bXByZXN0b3JlLmgKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gaW5j bHVkZS9wcm90b2NvbHMvZHVtcHJlc3RvcmUuaAkocmV2aXNpb24gMjE3MzYyKQorKysgaW5jbHVk ZS9wcm90b2NvbHMvZHVtcHJlc3RvcmUuaAkod29ya2luZyBjb3B5KQpAQCAtOTUsNyArOTUsNyBA QAogCQlpbnQ2NF90CWNfbXRpbWU7CSAgICAvKiBsYXN0IG1vZGlmaWVkIHRpbWUsIHNlY29uZHMg Ki8KIAkJaW50MzJfdAljX2V4dHNpemU7CSAgICAvKiBleHRlcm5hbCBhdHRyaWJ1dGUgc2l6ZSAq LwogCQlpbnQzMl90CWNfc3BhcmU0WzZdOwkgICAgLyogb2xkIGJsb2NrIHBvaW50ZXJzICovCi0J CXVfaW50MzJfdCBjX2ZpbGVfZmxhZ3M7CSAgICAvKiBzdGF0dXMgZmxhZ3MgKGNoZmxhZ3MpICov CisJCWZmbGFnc190IGNfZmlsZV9mbGFnczsJICAgIC8qIHN0YXR1cyBmbGFncyAoY2hmbGFncykg Ki8KIAkJaW50MzJfdAljX3NwYXJlNVsyXTsJICAgIC8qIG9sZCBibG9ja3MsIGdlbmVyYXRpb24g bnVtYmVyICovCiAJCXVfaW50MzJfdCBjX3VpZDsJICAgIC8qIGZpbGUgb3duZXIgKi8KIAkJdV9p bnQzMl90IGNfZ2lkOwkgICAgLyogZmlsZSBncm91cCAqLwpJbmRleDogbGliL2xpYmMvc3lzL2No ZmxhZ3MuMgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSBsaWIvbGliYy9zeXMvY2hmbGFncy4yCShyZXZpc2lvbiAy MTczNjIpCisrKyBsaWIvbGliYy9zeXMvY2hmbGFncy4yCSh3b3JraW5nIGNvcHkpCkBAIC00Miwx MSArNDIsMTEgQEAKIC5JbiBzeXMvc3RhdC5oCiAuSW4gdW5pc3RkLmgKIC5GdCBpbnQKLS5GbiBj aGZsYWdzICJjb25zdCBjaGFyICpwYXRoIiAidV9sb25nIGZsYWdzIgorLkZuIGNoZmxhZ3MgImNv bnN0IGNoYXIgKnBhdGgiICJmZmxhZ3NfdCBmbGFncyIKIC5GdCBpbnQKLS5GbiBsY2hmbGFncyAi Y29uc3QgY2hhciAqcGF0aCIgImludCBmbGFncyIKKy5GbiBsY2hmbGFncyAiY29uc3QgY2hhciAq cGF0aCIgImZmbGFnc190IGZsYWdzIgogLkZ0IGludAotLkZuIGZjaGZsYWdzICJpbnQgZmQiICJ1 X2xvbmcgZmxhZ3MiCisuRm4gZmNoZmxhZ3MgImludCBmZCIgImZmbGFnc190IGZsYWdzIgogLlNo IERFU0NSSVBUSU9OCiBUaGUgZmlsZSB3aG9zZSBuYW1lCiBpcyBnaXZlbiBieQpJbmRleDogc2Jp bi9yZXN0b3JlL3RhcGUuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzYmluL3Jlc3RvcmUvdGFwZS5jCShyZXZp c2lvbiAyMTczNjIpCisrKyBzYmluL3Jlc3RvcmUvdGFwZS5jCSh3b3JraW5nIGNvcHkpCkBAIC01 NTgsNyArNTU4LDcgQEAKIGludAogZXh0cmFjdGZpbGUoY2hhciAqbmFtZSkKIHsKLQlpbnQgZmxh Z3M7CisJZmZsYWdzX3QgZmxhZ3M7CiAJdWlkX3QgdWlkOwogCWdpZF90IGdpZDsKIAltb2RlX3Qg bW9kZTsKSW5kZXg6IHN5cy9rZXJuL3Zmc19zeXNjYWxscy5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9r ZXJuL3Zmc19zeXNjYWxscy5jCShyZXZpc2lvbiAyMTczNjIpCisrKyBzeXMva2Vybi92ZnNfc3lz Y2FsbHMuYwkod29ya2luZyBjb3B5KQpAQCAtOTYsNyArOTYsNyBAQAogc3RhdGljIGludCBnZXR1 dGltZXMoY29uc3Qgc3RydWN0IHRpbWV2YWwgKiwgZW51bSB1aW9fc2VnLCBzdHJ1Y3QgdGltZXNw ZWMgKik7CiBzdGF0aWMgaW50IHNldGZvd24oc3RydWN0IHRocmVhZCAqdGQsIHN0cnVjdCB2bm9k ZSAqLCB1aWRfdCwgZ2lkX3QpOwogc3RhdGljIGludCBzZXRmbW9kZShzdHJ1Y3QgdGhyZWFkICp0 ZCwgc3RydWN0IHZub2RlICosIGludCk7Ci1zdGF0aWMgaW50IHNldGZmbGFncyhzdHJ1Y3QgdGhy ZWFkICp0ZCwgc3RydWN0IHZub2RlICosIGludCk7CitzdGF0aWMgaW50IHNldGZmbGFncyhzdHJ1 Y3QgdGhyZWFkICp0ZCwgc3RydWN0IHZub2RlICosIGZmbGFnc190KTsKIHN0YXRpYyBpbnQgc2V0 dXRpbWVzKHN0cnVjdCB0aHJlYWQgKnRkLCBzdHJ1Y3Qgdm5vZGUgKiwKICAgICBjb25zdCBzdHJ1 Y3QgdGltZXNwZWMgKiwgaW50LCBpbnQpOwogc3RhdGljIGludCB2bl9hY2Nlc3Moc3RydWN0IHZu b2RlICp2cCwgaW50IHVzZXJfZmxhZ3MsIHN0cnVjdCB1Y3JlZCAqY3JlZCwKQEAgLTI2NTcsNyAr MjY1Nyw3IEBACiBzZXRmZmxhZ3ModGQsIHZwLCBmbGFncykKIAlzdHJ1Y3QgdGhyZWFkICp0ZDsK IAlzdHJ1Y3Qgdm5vZGUgKnZwOwotCWludCBmbGFnczsKKwlmZmxhZ3NfdCBmbGFnczsKIHsKIAlp bnQgZXJyb3I7CiAJc3RydWN0IG1vdW50ICptcDsKQEAgLTI2OTUsOCArMjY5NSw4IEBACiAgKi8K ICNpZm5kZWYgX1NZU19TWVNQUk9UT19IXwogc3RydWN0IGNoZmxhZ3NfYXJncyB7Ci0JY2hhcgkq cGF0aDsKLQlpbnQJZmxhZ3M7CisJY2hhcgkJKnBhdGg7CisJZmZsYWdzX3QJZmxhZ3M7CiB9Owog I2VuZGlmCiBpbnQKQEAgLTI3MDQsNyArMjcwNCw3IEBACiAJc3RydWN0IHRocmVhZCAqdGQ7CiAJ cmVnaXN0ZXIgc3RydWN0IGNoZmxhZ3NfYXJncyAvKiB7CiAJCWNoYXIgKnBhdGg7Ci0JCWludCBm bGFnczsKKwkJZmZsYWdzX3QgZmxhZ3M7CiAJfSAqLyAqdWFwOwogewogCWludCBlcnJvcjsKQEAg LTI3MzIsNyArMjczMiw3IEBACiAJc3RydWN0IHRocmVhZCAqdGQ7CiAJcmVnaXN0ZXIgc3RydWN0 IGxjaGZsYWdzX2FyZ3MgLyogewogCQljaGFyICpwYXRoOwotCQlpbnQgZmxhZ3M7CisJCWZmbGFn c190IGZsYWdzOwogCX0gKi8gKnVhcDsKIHsKIAlpbnQgZXJyb3I7CkBAIC0yNzU3LDggKzI3NTcs OCBAQAogICovCiAjaWZuZGVmIF9TWVNfU1lTUFJPVE9fSF8KIHN0cnVjdCBmY2hmbGFnc19hcmdz IHsKLQlpbnQJZmQ7Ci0JaW50CWZsYWdzOworCWludAkJZmQ7CisJZmZsYWdzX3QJZmxhZ3M7CiB9 OwogI2VuZGlmCiBpbnQKQEAgLTI3NjYsNyArMjc2Niw3IEBACiAJc3RydWN0IHRocmVhZCAqdGQ7 CiAJcmVnaXN0ZXIgc3RydWN0IGZjaGZsYWdzX2FyZ3MgLyogewogCQlpbnQgZmQ7Ci0JCWludCBm bGFnczsKKwkJZmZsYWdzX3QgZmxhZ3M7CiAJfSAqLyAqdWFwOwogewogCXN0cnVjdCBmaWxlICpm cDsKSW5kZXg6IHN5cy9zeXMvc3RhdC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9zeXMvc3RhdC5oCShy ZXZpc2lvbiAyMTczNjIpCisrKyBzeXMvc3lzL3N0YXQuaAkod29ya2luZyBjb3B5KQpAQCAtMjky LDExICsyOTIsMTEgQEAKICNpZm5kZWYgX0tFUk5FTAogX19CRUdJTl9ERUNMUwogI2lmIF9fQlNE X1ZJU0lCTEUKLWludAljaGZsYWdzKGNvbnN0IGNoYXIgKiwgdW5zaWduZWQgbG9uZyk7CitpbnQJ Y2hmbGFncyhjb25zdCBjaGFyICosIGZmbGFnc190KTsKICNlbmRpZgogaW50CWNobW9kKGNvbnN0 IGNoYXIgKiwgbW9kZV90KTsKICNpZiBfX0JTRF9WSVNJQkxFCi1pbnQJZmNoZmxhZ3MoaW50LCB1 bnNpZ25lZCBsb25nKTsKK2ludAlmY2hmbGFncyhpbnQsIGZmbGFnc190KTsKICNlbmRpZgogI2lm IF9fUE9TSVhfVklTSUJMRSA+PSAyMDAxMTIKIGludAlmY2htb2QoaW50LCBtb2RlX3QpOwpAQCAt MzA2LDcgKzMwNiw3IEBACiAjZW5kaWYKIGludAlmc3RhdChpbnQsIHN0cnVjdCBzdGF0ICopOwog I2lmIF9fQlNEX1ZJU0lCTEUKLWludAlsY2hmbGFncyhjb25zdCBjaGFyICosIGludCk7CitpbnQJ bGNoZmxhZ3MoY29uc3QgY2hhciAqLCBmZmxhZ3NfdCk7CiBpbnQJbGNobW9kKGNvbnN0IGNoYXIg KiwgbW9kZV90KTsKICNlbmRpZgogI2lmIF9fUE9TSVhfVklTSUJMRSA+PSAyMDAxMTIKSW5kZXg6 IHN5cy91ZnMvdWZzL2Rpbm9kZS5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy91ZnMvdWZzL2Rpbm9kZS5o CShyZXZpc2lvbiAyMTczNjIpCisrKyBzeXMvdWZzL3Vmcy9kaW5vZGUuaAkod29ya2luZyBjb3B5 KQpAQCAtMTQwLDcgKzE0MCw3IEBACiAJaW50MzJfdAkJZGlfYmlydGhuc2VjOwkvKiAgNzY6IElu b2RlIGNyZWF0aW9uIHRpbWUuICovCiAJaW50MzJfdAkJZGlfZ2VuOwkJLyogIDgwOiBHZW5lcmF0 aW9uIG51bWJlci4gKi8KIAl1X2ludDMyX3QJZGlfa2VybmZsYWdzOwkvKiAgODQ6IEtlcm5lbCBm bGFncy4gKi8KLQl1X2ludDMyX3QJZGlfZmxhZ3M7CS8qICA4ODogU3RhdHVzIGZsYWdzIChjaGZs YWdzKS4gKi8KKwlmZmxhZ3NfdAlkaV9mbGFnczsJLyogIDg4OiBTdGF0dXMgZmxhZ3MgKGNoZmxh Z3MpLiAqLwogCWludDMyX3QJCWRpX2V4dHNpemU7CS8qICA5MjogRXh0ZXJuYWwgYXR0cmlidXRl cyBibG9jay4gKi8KIAl1ZnMyX2RhZGRyX3QJZGlfZXh0YltOWEFERFJdOy8qICA5NjogRXh0ZXJu YWwgYXR0cmlidXRlcyBibG9jay4gKi8KIAl1ZnMyX2RhZGRyX3QJZGlfZGJbTkRBRERSXTsJLyog MTEyOiBEaXJlY3QgZGlzayBibG9ja3MuICovCkluZGV4OiB0b29scy9yZWdyZXNzaW9uL3BqZGZz dGVzdC9wamRmc3Rlc3QuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9uL3BqZGZzdGVz dC9wamRmc3Rlc3QuYwkocmV2aXNpb24gMjE3MzYyKQorKysgdG9vbHMvcmVncmVzc2lvbi9wamRm c3Rlc3QvcGpkZnN0ZXN0LmMJKHdvcmtpbmcgY29weSkKQEAgLTU3OCwxMiArNTc3LDE0IEBACiAJ CWJyZWFrOwogI2lmZGVmIEhBU19DSEZMQUdTCiAJY2FzZSBBQ1RJT05fQ0hGTEFHUzoKLQkJcnZh bCA9IGNoZmxhZ3MoU1RSKDApLCAodW5zaWduZWQgbG9uZylzdHIyZmxhZ3MoY2hmbGFnc19mbGFn cywgU1RSKDEpKSk7CisJCXJ2YWwgPSBjaGZsYWdzKFNUUigwKSwKKwkJICAgIChmZmxhZ3NfdClz dHIyZmxhZ3MoY2hmbGFnc19mbGFncywgU1RSKDEpKSk7CiAJCWJyZWFrOwogI2VuZGlmCiAjaWZk ZWYgSEFTX0xDSEZMQUdTCiAJY2FzZSBBQ1RJT05fTENIRkxBR1M6Ci0JCXJ2YWwgPSBsY2hmbGFn cyhTVFIoMCksIChpbnQpc3RyMmZsYWdzKGNoZmxhZ3NfZmxhZ3MsIFNUUigxKSkpOworCQlydmFs ID0gbGNoZmxhZ3MoU1RSKDApLAorCQkgICAgKGZmbGFnc190KXN0cjJmbGFncyhjaGZsYWdzX2Zs YWdzLCBTVFIoMSkpKTsKIAkJYnJlYWs7CiAjZW5kaWYKIAljYXNlIEFDVElPTl9UUlVOQ0FURToK --000e0cdfd8f8794ebc049a140808-- From owner-freebsd-fs@FreeBSD.ORG Tue Jan 18 01:00:24 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1C0310656A5 for ; Tue, 18 Jan 2011 01:00:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A092C8FC0C for ; Tue, 18 Jan 2011 01:00:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0I10OZQ044396 for ; Tue, 18 Jan 2011 01:00:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0I10OYh044371; Tue, 18 Jan 2011 01:00:24 GMT (envelope-from gnats) Date: Tue, 18 Jan 2011 01:00:24 GMT Message-Id: <201101180100.p0I10OYh044371@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Garrett Cooper Cc: Subject: Re: kern/153996: [zfs] zfs root mount error while kernel is not located in /boot/kernel X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Garrett Cooper List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 01:00:24 -0000 The following reply was made to PR kern/153996; it has been noted by GNATS. From: Garrett Cooper To: bug-followup@FreeBSD.org, alexander.naumochkin@gmail.com Cc: Subject: Re: kern/153996: [zfs] zfs root mount error while kernel is not located in /boot/kernel Date: Mon, 17 Jan 2011 16:56:27 -0800 Alexander, Have you tried setting kernelname to GCAM in your loader.conf before booting (it's not documented in loader.conf but it's a part of boot)? Another item I use to switch between kernels is symlink the suckers: $ ls -l /boot/kernel lrwxr-xr-x 1 root wheel 17 Jan 13 17:35 /boot/kernel -> BAYONETTA.r217362 This works well. HTH, -Garrett From owner-freebsd-fs@FreeBSD.ORG Tue Jan 18 01:35:29 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BD54106566B for ; Tue, 18 Jan 2011 01:35:29 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [64.81.247.49]) by mx1.freebsd.org (Postfix) with ESMTP id ADD178FC08 for ; Tue, 18 Jan 2011 01:35:28 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id p0I1G47e064477; Mon, 17 Jan 2011 17:16:04 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201101180116.p0I1G47e064477@chez.mckusick.com> To: Garrett Cooper In-reply-to: Date: Mon, 17 Jan 2011 17:16:04 -0800 From: Kirk McKusick Cc: fs@freebsd.org Subject: Re: Inconsistency and bug with *chflags functions 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, 18 Jan 2011 01:35:29 -0000 Your change looks like a step forward to me. My recommendation is to do it. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Tue Jan 18 04:40:21 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85D33106566B for ; Tue, 18 Jan 2011 04:40:21 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 122718FC16 for ; Tue, 18 Jan 2011 04:40:20 +0000 (UTC) Received: by fxm16 with SMTP id 16so6881788fxm.13 for ; Mon, 17 Jan 2011 20:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=QkqRDc0oqru7h7O1OiKwSAAzGi8oJq2D0BOdFcxSGi4=; b=m3DicMiP8dNfNhuN29UMV8ONy+wn0w02+/81l1XUu9FF2Xuw3IUq747rMaGZpfdy2O g1h8pp5kJurlvfKAqQI/lIDbwFx0YRzECAof7yassFitn17cc1bXTU9Rv9LPEFz2GCHY bEn4vSsy5u4LEArBJplF2BQGYk0h9xauEvfc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ghUq/8HhNbkp4EZBEdWyXPQt4fwi72Z56ij057iBCaNru7FE9dNX+jd732hqFQDQND mB3utJdn3wX8tNGKiTBaRTA8RCmAmu6CA9un7p1V7HW8pOGBzRCLWIktgh1sM7XL5Coe t0ZwY8aHu4wUJrVq7tzaue2xUiW8EuN8k96Yo= Received: by 10.223.114.14 with SMTP id c14mr5564793faq.103.1295324109720; Mon, 17 Jan 2011 20:15:09 -0800 (PST) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id 21sm1925616fav.41.2011.01.17.20.15.08 (version=SSLv3 cipher=RC4-MD5); Mon, 17 Jan 2011 20:15:09 -0800 (PST) Date: Tue, 18 Jan 2011 06:14:47 +0200 From: Gleb Kurtsou To: Garrett Cooper Message-ID: <20110118041447.GA2087@tops.skynet.lt> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: fs@freebsd.org Subject: Re: Inconsistency and bug with *chflags functions 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, 18 Jan 2011 04:40:21 -0000 On (17/01/2011 16:32), Garrett Cooper wrote: > Hi FS folks, > > Originally I did this to determine why lchflags had an int > argument and chflags/fchflags had unsigned long arguments, and I ran > into an interesting mini-project (by accident) after I found a few > bugs lurking in the vfs_syscalls.c layer of the kernel. > > So here's the deal... > > Problems: > 1. chflags/fchflags claim that the flags argument is an unsigned long, > whereas lchflags claims it's an int. This is inconsistent. > 2. The kernel interfaces are all implicitly downcasting the flags > argument to int. > 3. There's a sizing/signedness discrepancy in a few other structures > with fixed-width data types (uint32_t). > > Solution: > 1. I opted to convert fflags_t to uint32_t and convert all references > which did direct conversions to and from st_flags to fflags_t to avoid > 32-bit / 64-bit biarch issues. I downgraded it to uint32_t as we're no > where near the limit for the number of usable flags to *chflags(2). > 2. *chflags now uses fflags_t instead of int/unsigned long. > 3. c_file_flags in dumprestore.h was changed to be in sync with st_flags. > 4. di_flags in ufs/ufs/dinode.h was changed to be in sync with st_flags. > > Compatibility: > 1. NetBSD uses unsigned long in their chflags calls (both in kernel > and userland) so they're more consistent than we are by not having > mixed flags calling convention like us, but uses uint32_t in their > data structures (like we do), so they have a 32-bit/64-bit biarch bug > (again like we do). > 2. OpenBSD is using unsigned int, so I assume that their kernel layer > is also using unsigned int (I am basing this purely off the manpage as > I haven't looked at their sources, but I could be wrong). Hi Garrett, You've changed syscalls definitions but didn't add backward compatibility shims for kernel, libc and freebsd32. I'm working on changing ino_t to 64 bits and nlink_t to 32 bits, we could join the effort, as projects look related. My old patch is available here: https://github.com/downloads/glk/freebsd-ino64/freebsd-ino64-patch.tgz Please find comments to the patch below. > > I'm running make universe just to see if it will barf in the > build, but would someone please review this change (I made the change > as minimal as possible for ease of review) and provide feedback? > Thanks, > -Garrett > > PS Please CC me on all replies as I'm not subscribed to the list. > Index: include/protocols/dumprestore.h > =================================================================== > --- include/protocols/dumprestore.h (revision 217362) > +++ include/protocols/dumprestore.h (working copy) > @@ -95,7 +95,7 @@ > int64_t c_mtime; /* last modified time, seconds */ > int32_t c_extsize; /* external attribute size */ > int32_t c_spare4[6]; /* old block pointers */ > - u_int32_t c_file_flags; /* status flags (chflags) */ > + fflags_t c_file_flags; /* status flags (chflags) */ The struct represents on-disk protocol description, and thus shouldn't be changed. > int32_t c_spare5[2]; /* old blocks, generation number */ > u_int32_t c_uid; /* file owner */ > u_int32_t c_gid; /* file group */ > Index: lib/libc/sys/chflags.2 > =================================================================== > --- lib/libc/sys/chflags.2 (revision 217362) > +++ lib/libc/sys/chflags.2 (working copy) > @@ -42,11 +42,11 @@ > .In sys/stat.h > .In unistd.h > .Ft int > -.Fn chflags "const char *path" "u_long flags" > +.Fn chflags "const char *path" "fflags_t flags" > .Ft int > -.Fn lchflags "const char *path" "int flags" > +.Fn lchflags "const char *path" "fflags_t flags" > .Ft int > -.Fn fchflags "int fd" "u_long flags" > +.Fn fchflags "int fd" "fflags_t flags" > .Sh DESCRIPTION > The file whose name > is given by > Index: sbin/restore/tape.c > =================================================================== > --- sbin/restore/tape.c (revision 217362) > +++ sbin/restore/tape.c (working copy) > @@ -558,7 +558,7 @@ > int > extractfile(char *name) > { > - int flags; > + fflags_t flags; > uid_t uid; > gid_t gid; > mode_t mode; > Index: sys/kern/vfs_syscalls.c > =================================================================== > --- sys/kern/vfs_syscalls.c (revision 217362) > +++ sys/kern/vfs_syscalls.c (working copy) > @@ -96,7 +96,7 @@ > static int getutimes(const struct timeval *, enum uio_seg, struct timespec *); > static int setfown(struct thread *td, struct vnode *, uid_t, gid_t); > static int setfmode(struct thread *td, struct vnode *, int); > -static int setfflags(struct thread *td, struct vnode *, int); > +static int setfflags(struct thread *td, struct vnode *, fflags_t); > static int setutimes(struct thread *td, struct vnode *, > const struct timespec *, int, int); > static int vn_access(struct vnode *vp, int user_flags, struct ucred *cred, > @@ -2657,7 +2657,7 @@ > setfflags(td, vp, flags) > struct thread *td; > struct vnode *vp; > - int flags; > + fflags_t flags; > { > int error; > struct mount *mp; > @@ -2695,8 +2695,8 @@ > */ > #ifndef _SYS_SYSPROTO_H_ > struct chflags_args { > - char *path; > - int flags; > + char *path; > + fflags_t flags; > }; > #endif > int > @@ -2704,7 +2704,7 @@ > struct thread *td; > register struct chflags_args /* { > char *path; > - int flags; > + fflags_t flags; > } */ *uap; > { > int error; > @@ -2732,7 +2732,7 @@ > struct thread *td; > register struct lchflags_args /* { > char *path; > - int flags; > + fflags_t flags; > } */ *uap; > { > int error; > @@ -2757,8 +2757,8 @@ > */ > #ifndef _SYS_SYSPROTO_H_ > struct fchflags_args { > - int fd; > - int flags; > + int fd; > + fflags_t flags; > }; > #endif > int > @@ -2766,7 +2766,7 @@ > struct thread *td; > register struct fchflags_args /* { > int fd; > - int flags; > + fflags_t flags; > } */ *uap; > { > struct file *fp; > Index: sys/sys/stat.h > =================================================================== > --- sys/sys/stat.h (revision 217362) > +++ sys/sys/stat.h (working copy) > @@ -292,11 +292,11 @@ > #ifndef _KERNEL > __BEGIN_DECLS > #if __BSD_VISIBLE > -int chflags(const char *, unsigned long); > +int chflags(const char *, fflags_t); > #endif > int chmod(const char *, mode_t); > #if __BSD_VISIBLE > -int fchflags(int, unsigned long); > +int fchflags(int, fflags_t); > #endif > #if __POSIX_VISIBLE >= 200112 > int fchmod(int, mode_t); > @@ -306,7 +306,7 @@ > #endif > int fstat(int, struct stat *); > #if __BSD_VISIBLE > -int lchflags(const char *, int); > +int lchflags(const char *, fflags_t); > int lchmod(const char *, mode_t); > #endif > #if __POSIX_VISIBLE >= 200112 > Index: sys/ufs/ufs/dinode.h > =================================================================== > --- sys/ufs/ufs/dinode.h (revision 217362) > +++ sys/ufs/ufs/dinode.h (working copy) > @@ -140,7 +140,7 @@ > int32_t di_birthnsec; /* 76: Inode creation time. */ > int32_t di_gen; /* 80: Generation number. */ > u_int32_t di_kernflags; /* 84: Kernel flags. */ > - u_int32_t di_flags; /* 88: Status flags (chflags). */ > + fflags_t di_flags; /* 88: Status flags (chflags). */ Please revert for the same reason. > int32_t di_extsize; /* 92: External attributes block. */ > ufs2_daddr_t di_extb[NXADDR];/* 96: External attributes block. */ > ufs2_daddr_t di_db[NDADDR]; /* 112: Direct disk blocks. */ > Index: tools/regression/pjdfstest/pjdfstest.c > =================================================================== > --- tools/regression/pjdfstest/pjdfstest.c (revision 217362) > +++ tools/regression/pjdfstest/pjdfstest.c (working copy) > @@ -578,12 +577,14 @@ > break; > #ifdef HAS_CHFLAGS > case ACTION_CHFLAGS: > - rval = chflags(STR(0), (unsigned long)str2flags(chflags_flags, STR(1))); > + rval = chflags(STR(0), > + (fflags_t)str2flags(chflags_flags, STR(1))); > break; > #endif > #ifdef HAS_LCHFLAGS > case ACTION_LCHFLAGS: > - rval = lchflags(STR(0), (int)str2flags(chflags_flags, STR(1))); > + rval = lchflags(STR(0), > + (fflags_t)str2flags(chflags_flags, STR(1))); > break; > #endif > case ACTION_TRUNCATE: > _______________________________________________ > 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 Jan 18 04:47:48 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C014106566B for ; Tue, 18 Jan 2011 04:47:48 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 935628FC1A for ; Tue, 18 Jan 2011 04:47:47 +0000 (UTC) Received: by wwf26 with SMTP id 26so5966722wwf.31 for ; Mon, 17 Jan 2011 20:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gLKShVgqvWGIIa5LWJuGSDI481Adf9DtghTPy0skJPs=; b=nXpdqkQISh3i/uBoKclIPL9mK0ZjAfR9TbRRL4GR5r38PFROgU0NMwTmNRthIAogku K4rXt5I46QTVhfqo0dg+U/r0E93j7nuTrHUWhu6yAOAUZ+k+hfruZyhil9zBFZkDM4Cs VMEZJGq5fdtRqKCAWXw99+JWG0kB7KZxrMpRY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WYVCTcb5HdskAmmY4DcEhDkutCln8B0US0KAGJLC08OKg42ohCP+0y01Dr8NTNGXWe 1Wqr9pWRA31x8KOHHihSlAWT/HKNi8Ibgu9ZjdYtXlK41yYJPiQmPWve6CgKPpTxrmg2 M7n3H5Y6BaWW6hJ/d0GNwtitT9gU7aVuK6sTI= MIME-Version: 1.0 Received: by 10.216.141.75 with SMTP id f53mr4202386wej.16.1295326066420; Mon, 17 Jan 2011 20:47:46 -0800 (PST) Received: by 10.216.254.226 with HTTP; Mon, 17 Jan 2011 20:47:46 -0800 (PST) In-Reply-To: <20110118041447.GA2087@tops.skynet.lt> References: <20110118041447.GA2087@tops.skynet.lt> Date: Mon, 17 Jan 2011 20:47:46 -0800 Message-ID: From: Garrett Cooper To: Gleb Kurtsou Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fs@freebsd.org Subject: Re: Inconsistency and bug with *chflags functions 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, 18 Jan 2011 04:47:48 -0000 Hi Gleb! On Mon, Jan 17, 2011 at 8:14 PM, Gleb Kurtsou wrot= e: > On (17/01/2011 16:32), Garrett Cooper wrote: >> Hi FS folks, >> >> =A0 =A0 Originally I did this to determine why lchflags had an int >> argument and chflags/fchflags had unsigned long arguments, and I ran >> into an interesting mini-project (by accident) after I found a few >> bugs lurking in the vfs_syscalls.c layer of the kernel. >> >> =A0 =A0 So here's the deal... >> >> Problems: >> 1. chflags/fchflags claim that the flags argument is an unsigned long, >> whereas lchflags claims it's an int. This is inconsistent. >> 2. The kernel interfaces are all implicitly downcasting the flags >> argument to int. >> 3. There's a sizing/signedness discrepancy in a few other structures >> with fixed-width data types (uint32_t). >> >> Solution: >> 1. I opted to convert fflags_t to uint32_t and convert all references >> which did direct conversions to and from st_flags to fflags_t to avoid >> 32-bit / 64-bit biarch issues. I downgraded it to uint32_t as we're no >> where near the limit for the number of usable flags to *chflags(2). >> 2. *chflags now uses fflags_t instead of int/unsigned long. >> 3. c_file_flags in dumprestore.h was changed to be in sync with st_flags= . >> 4. di_flags in ufs/ufs/dinode.h was changed to be in sync with st_flags. >> >> Compatibility: >> 1. NetBSD uses unsigned long in their chflags calls (both in kernel >> and userland) so they're more consistent than we are by not having >> mixed flags calling convention like us, but uses uint32_t in their >> data structures (like we do), so they have a 32-bit/64-bit biarch bug >> (again like we do). >> 2. OpenBSD is using unsigned int, so I assume that their kernel layer >> is also using unsigned int (I am basing this purely off the manpage as >> I haven't looked at their sources, but I could be wrong). > > Hi Garrett, > > You've changed syscalls definitions but didn't add backward > compatibility shims for kernel, libc and freebsd32. Please enlighten me on how to do that (docs are fine) and I'll go ahead and add the compatibility shims. I'm not a committer so I don't yet know these things :). The only thing is that the old behavior on biarch platforms like amd64 with COMPAT_FREEBSD32, etc was broken so I don't know if there's any value in emulating broken behavior. Straight 32-bit and straight 64-bit archs didn't have this problem. > I'm working on changing ino_t to 64 bits and nlink_t to 32 bits, we > could join the effort, as projects look related. My old patch is > available here: > https://github.com/downloads/glk/freebsd-ino64/freebsd-ino64-patch.tgz Hmmm... I'll take a look at that. FWIW, I was avoiding bumping fflags_t to uint64_t because it would change alignment of kernel structures, but I'll take your advice in kind for resolving this problem. There are other ways to avoid this by downcasting (or just casting between types in general), which is fine today but I thought this solution was simple because it was easier to root out affected areas. Either way, I know that this method is a bit of a damned if you do, damned if you don't because it restricts us from future additions if fflags_t goes exceeds 2^32, but that's still the case today if the field changes in the on-disk structures anyhow. > Please find comments to the patch below. Ok :)! >> =A0 =A0 I'm running make universe just to see if it will barf in the >> build, but would someone please review this change (I made the change >> as minimal as possible for ease of review) and provide feedback? ... >> - =A0 =A0 =A0 =A0 =A0 =A0 u_int32_t c_file_flags; =A0 =A0 /* status flag= s (chflags) */ >> + =A0 =A0 =A0 =A0 =A0 =A0 fflags_t c_file_flags; =A0 =A0 =A0/* status fl= ags (chflags) */ > The struct represents on-disk protocol description, and thus shouldn't be= changed. fflags_t in this case is uint32_t, so this is a drop-in-place replacement -- or are you arguing the type more than the width of the type? >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 int32_t c_spare5[2]; =A0 =A0 =A0 =A0/* old b= locks, generation number */ ... >> - =A0 =A0 u_int32_t =A0 =A0 =A0 di_flags; =A0 =A0 =A0 /* =A088: Status f= lags (chflags). */ >> + =A0 =A0 fflags_t =A0 =A0 =A0 =A0di_flags; =A0 =A0 =A0 /* =A088: Status= flags (chflags). */ > Please revert for the same reason. My response here is the same as above. Thanks! -Garrett From owner-freebsd-fs@FreeBSD.ORG Tue Jan 18 04:52:15 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 133911065674 for ; Tue, 18 Jan 2011 04:52:15 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9E42E8FC17 for ; Tue, 18 Jan 2011 04:52:14 +0000 (UTC) Received: by wwf26 with SMTP id 26so5969096wwf.31 for ; Mon, 17 Jan 2011 20:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=E8zIpKyWMqv3Fp8SU02/GiBvsZQ57RUqIx0dU41mHxU=; b=o3ANDflXKIaL0rrDyEsfvrgZkXDxGcOAhNlCWMnGPS2X+3LIYupp90kpF1FRWOGPvF eeevDQ+fdBIJ+XKzLKqSdmAAJGE7hGJQxMLOoGDWAa8vrq5+MTZ3U98JIsL+AbuPgmXi NaF3165g2xBOtfTSenUeNvTRuDDGhn9P/b1z0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=R8fLTIDWEG6SyJdiqbpB3jHHREDBV0VhUFSlPVoTB4Doqc/JjhM94KnCVmV8JOlpmt P7CauVUC8lPTUupBybIRaUcXiAV577aGMKMEx1smKSM86f6l8sHRU06PNsCfcduRgi39 sfF+R1gZuJWNdzEPzqjAvCtFyCHqv1niyC6xA= MIME-Version: 1.0 Received: by 10.216.78.146 with SMTP id g18mr4240322wee.1.1295326333510; Mon, 17 Jan 2011 20:52:13 -0800 (PST) Received: by 10.216.254.226 with HTTP; Mon, 17 Jan 2011 20:52:13 -0800 (PST) In-Reply-To: <201101180116.p0I1G47e064477@chez.mckusick.com> References: <201101180116.p0I1G47e064477@chez.mckusick.com> Date: Mon, 17 Jan 2011 20:52:13 -0800 Message-ID: From: Garrett Cooper To: Kirk McKusick Content-Type: text/plain; charset=ISO-8859-1 Cc: fs@freebsd.org Subject: Re: Inconsistency and bug with *chflags functions 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, 18 Jan 2011 04:52:15 -0000 On Mon, Jan 17, 2011 at 5:16 PM, Kirk McKusick wrote: > Your change looks like a step forward to me. My recommendation > is to do it. Hi Kirk! Thanks for the review! FWIW, I completely overlooked fflagstostr and strtofflags so unfortunately my patch has grown a bit (a few hundred lines). Once I have things squared away (amd64 and i386 passes make tinderbox without issues), I'll resubmit another patch just for review. Thanks! -Garrett From owner-freebsd-fs@FreeBSD.ORG Tue Jan 18 10:54:43 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A6A21065694 for ; Tue, 18 Jan 2011 10:54:43 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0EC778FC19 for ; Tue, 18 Jan 2011 10:54:42 +0000 (UTC) Received: by gyf3 with SMTP id 3so2331478gyf.13 for ; Tue, 18 Jan 2011 02:54:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=4MglhvI1MPCFFrFhIR/paHx9U7eDwfLC4c5wLM9ZrA8=; b=ETkcxx0AXuLuuj+D6v0KC+tPrZQRhPbEOK79xl725acc7PVE1mNVzoBh9IC9LF28Ir pHa9D5mAsNNR92EHj93qptYEI6g2K5YdUv9/E6NY4dBfc1y4OUJBdBBhmN/92VuvG2jv /lYeHUxxk6VP3V4Sqr4Ytsx4L2fb0HyWF/4wk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=tN2nxi/VWd5rh+ApESWG9/5GjLfX12qbXD/JSUoOERA4lVRWz+XRWF052h662cATB/ DBBgpwyjglSGofwgUxgTc9WN+O8cZlZWCklgkTKdVPj+5No/MGoD60f5Y9td3oYxRk0w 1GLcS/oa1QD0CDzTJedfSSknizHVOj87AnbZ8= Received: by 10.151.84.8 with SMTP id m8mr795644ybl.276.1295348080943; Tue, 18 Jan 2011 02:54:40 -0800 (PST) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id r24sm2889054yba.6.2011.01.18.02.54.38 (version=SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 02:54:39 -0800 (PST) Date: Tue, 18 Jan 2011 12:54:15 +0200 From: Gleb Kurtsou To: Garrett Cooper Message-ID: <20110118105415.GA73120@tops.skynet.lt> References: <20110118041447.GA2087@tops.skynet.lt> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: fs@freebsd.org Subject: Re: Inconsistency and bug with *chflags functions 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, 18 Jan 2011 10:54:43 -0000 On (17/01/2011 20:47), Garrett Cooper wrote: > Hi Gleb! > > On Mon, Jan 17, 2011 at 8:14 PM, Gleb Kurtsou wrote: > > On (17/01/2011 16:32), Garrett Cooper wrote: > >> Hi FS folks, > >> > >>     Originally I did this to determine why lchflags had an int > >> argument and chflags/fchflags had unsigned long arguments, and I ran > >> into an interesting mini-project (by accident) after I found a few > >> bugs lurking in the vfs_syscalls.c layer of the kernel. > >> > >>     So here's the deal... > >> > >> Problems: > >> 1. chflags/fchflags claim that the flags argument is an unsigned long, > >> whereas lchflags claims it's an int. This is inconsistent. > >> 2. The kernel interfaces are all implicitly downcasting the flags > >> argument to int. > >> 3. There's a sizing/signedness discrepancy in a few other structures > >> with fixed-width data types (uint32_t). > >> > >> Solution: > >> 1. I opted to convert fflags_t to uint32_t and convert all references > >> which did direct conversions to and from st_flags to fflags_t to avoid > >> 32-bit / 64-bit biarch issues. I downgraded it to uint32_t as we're no > >> where near the limit for the number of usable flags to *chflags(2). > >> 2. *chflags now uses fflags_t instead of int/unsigned long. > >> 3. c_file_flags in dumprestore.h was changed to be in sync with st_flags. > >> 4. di_flags in ufs/ufs/dinode.h was changed to be in sync with st_flags. > >> > >> Compatibility: > >> 1. NetBSD uses unsigned long in their chflags calls (both in kernel > >> and userland) so they're more consistent than we are by not having > >> mixed flags calling convention like us, but uses uint32_t in their > >> data structures (like we do), so they have a 32-bit/64-bit biarch bug > >> (again like we do). > >> 2. OpenBSD is using unsigned int, so I assume that their kernel layer > >> is also using unsigned int (I am basing this purely off the manpage as > >> I haven't looked at their sources, but I could be wrong). > > > > Hi Garrett, > > > > You've changed syscalls definitions but didn't add backward > > compatibility shims for kernel, libc and freebsd32. > > Please enlighten me on how to do that (docs are fine) and I'll go > ahead and add the compatibility shims. I'm not a committer so I don't > yet know these things :). It's unlikely to be documented. You can't just change syscall definition, you should add a new one and mark old COMPAT8 (in this particular case). Implement kernel level wrappers, etc. Symbol versioning within libc is rather different story, I'd suggest you take a look at my patch it should be straightforward. > The only thing is that the old behavior on biarch platforms like amd64 > with COMPAT_FREEBSD32, etc was broken so I don't know if there's any > value in emulating broken behavior. Straight 32-bit and straight > 64-bit archs didn't have this problem. Yes, they are broken, but due to amd64 being little ending and flag argument being bit mask, I think both chflags and fchaflags actually work, although it should also be fixed, imho. Wrapper won't be needed for the new version (with fflags_t). > > I'm working on changing ino_t to 64 bits and nlink_t to 32 bits, we > > could join the effort, as projects look related. My old patch is > > available here: > > https://github.com/downloads/glk/freebsd-ino64/freebsd-ino64-patch.tgz > > Hmmm... I'll take a look at that. FWIW, I was avoiding bumping > fflags_t to uint64_t because it would change alignment of kernel > structures, but I'll take your advice in kind for resolving this > problem. There are other ways to avoid this by downcasting (or just > casting between types in general), which is fine today but I thought > this solution was simple because it was easier to root out affected > areas. Either way, I know that this method is a bit of a damned if you > do, damned if you don't because it restricts us from future additions > if fflags_t goes exceeds 2^32, but that's still the case today if the > field changes in the on-disk structures anyhow. 32 bits should be good enough. Extended attributes are getting more widely used nowadays. > > Please find comments to the patch below. > > Ok :)! > > >>     I'm running make universe just to see if it will barf in the > >> build, but would someone please review this change (I made the change > >> as minimal as possible for ease of review) and provide feedback? > > ... > > >> -             u_int32_t c_file_flags;     /* status flags (chflags) */ > >> +             fflags_t c_file_flags;      /* status flags (chflags) */ > > The struct represents on-disk protocol description, and thus shouldn't be changed. > > fflags_t in this case is uint32_t, so this is a drop-in-place > replacement -- or are you arguing the type more than the width of the > type? It's common practice, this way fflags_t could be changed to different type in the future, but binary compatibility (dump/restore protocol here) will be preserved. As it happened with uid_t, pid_t, off_t, or taking place with ino_t and nlink_t. No typedefs are used in struct ufs2_dinode or protocols/dumprestore.h (ino_t is being fixed). > >>               int32_t c_spare5[2];        /* old blocks, generation number */ > > ... > > >> -     u_int32_t       di_flags;       /*  88: Status flags (chflags). */ > >> +     fflags_t        di_flags;       /*  88: Status flags (chflags). */ > > Please revert for the same reason. > > My response here is the same as above. > > Thanks! > -Garrett From owner-freebsd-fs@FreeBSD.ORG Tue Jan 18 14:11:53 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CEA91065670 for ; Tue, 18 Jan 2011 14:11:53 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 34B5F8FC15 for ; Tue, 18 Jan 2011 14:11:52 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAH8uNU2DaFvO/2dsb2JhbACEC6FBsmePHYEkgzh0BIRvhi8 X-IronPort-AV: E=Sophos;i="4.60,339,1291611600"; d="scan'208";a="107468849" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 18 Jan 2011 09:11:52 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 5D7D7B3F58; Tue, 18 Jan 2011 09:11:52 -0500 (EST) Date: Tue, 18 Jan 2011 09:11:52 -0500 (EST) From: Rick Macklem To: Attila Nagy Message-ID: <1571522098.399734.1295359912372.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4C614A7D.8030509@fsn.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: NFS problem: file doesn't appear in file listing, but can be accessed directly 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, 18 Jan 2011 14:11:53 -0000 > On 08/08/2010 02:06 AM, Rick Macklem wrote: > >> On 07.08.2010, at 02:35, Rick Macklem wrote: > >> > >> I agree, this must be some kind of server issue then. Still, I > >> wonder > >> why the solaris client didn't show the problem... > >> > >> > > 2 things: > > 1 - the solaris client uses ReaddirPlus and not Readdir RPCs by > > default (I can't remember if that default can be overridden?). > I don't know whether this counts or not, but I've tried with an old > Solaris (x86) 8 (uname says it's Generic_108529-06). > > > ps: I don't recall the previous emails mentioning that the "ls" > > was ok for a solaris client. > > > It was in 4C582968.9000303@fsn.hu: > "I've mounted the share from an old Solaris box, which sees the file." > > This means, when I issue an ls | grep problematic_fname, I can see the > filename. > BTW, this turned out to be incorrect, because I've tested with the > same > (one of the missing) filename. > Doing a find . in the directory on both FreeBSD and Solaris client > shows > some differences. > So what I have now is: both the normal and the experimental NFSD show > the problem on both FreeBSD and Solaris clients (only the missing file > names are different). > > On Solaris there are 78 files missing, on FreeBSD there are 193, I > haven't checked that they are persistent across reboots or not. I believe that this problem might be fixed by r216774 in head (for the regular NFS server) and r216691 in head (for the experimental NFS server). The above patches fixes a problem that would occur when ZFS generated non monotonically increasing directory offset cookies and readdir in the server would skip over some directory entries. rick From owner-freebsd-fs@FreeBSD.ORG Tue Jan 18 15:01:47 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC3C11065672 for ; Tue, 18 Jan 2011 15:01:46 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7AE748FC19 for ; Tue, 18 Jan 2011 15:01:46 +0000 (UTC) Received: by wyf19 with SMTP id 19so6392401wyf.13 for ; Tue, 18 Jan 2011 07:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BR8o7UsqtYeEpCbskzmINJTBvd7Lv361e9//59doJ9Q=; b=AVoi3HxrbH0Z23wvs6vT4CybYN8967hdMzL/Wh0QMj0BG9wfoL6BNKq1rlGceKurGQ HyP6IZSWou94Dluk71DlHCXw2RcFwx1oAn7j/EeiWTdEgyon1Wx4wSxsfVJzRC1zdqKg KIpC+MIT7IhHwp+5ukI9XCu35MVSGjVKab1mg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=e9U+G9ynDHLBBOyg/Li0AVBOV9xFHtLJIKuor2RWOof1q02HjmP8qJAGMkbJbGce+3 KjluWX7ITZ2ekSyXeo/Kby4u8OQOL80tuCAxMzoIUncXKkHTKgm4jn/8YCObNinADU7i 1lkCpvor/IQ/YOBAg2mJmp1CyG16sFxXGByxw= MIME-Version: 1.0 Received: by 10.216.35.82 with SMTP id t60mr1252022wea.46.1295362905278; Tue, 18 Jan 2011 07:01:45 -0800 (PST) Received: by 10.216.254.226 with HTTP; Tue, 18 Jan 2011 07:01:44 -0800 (PST) In-Reply-To: <20110118234350.R1077@besplex.bde.org> References: <20110118041447.GA2087@tops.skynet.lt> <20110118234350.R1077@besplex.bde.org> Date: Tue, 18 Jan 2011 07:01:44 -0800 Message-ID: From: Garrett Cooper To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fs@freebsd.org Subject: Re: Inconsistency and bug with *chflags functions 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, 18 Jan 2011 15:01:47 -0000 On Tue, Jan 18, 2011 at 6:18 AM, Bruce Evans wrote: > On Tue, 18 Jan 2011, Gleb Kurtsou wrote: > ... > As you found, the kernel wants everything to be an int, and setfflags() > still only accepts an int. =A0Thus it is an error to pretend that the > syscalls take args of other types. =A0Larger types would be handled > correctly if syscalls.master actually pseudo-declared ths syscalls > correctly, but it still says int as in 4.4BSD-Lite for chflags/fchflags()= . > FreeBSD generates args structs containing the actual types from the > data in syscalls.master. =A0If the latter is correct, then the correct > conversions will be done without further type puns, by normal C > conversions, e.g., setfflags(..., uap->flag), where `flags' has whatever > type it has and the function call converts to int. =A0Plain ints work > correctly except possibly for invalid args since the sign bit is not > used by any supported flags value. Signedness isn't important for this flag. Only width and data alignment as you suggested elsewhere. >>> into an interesting mini-project (by accident) after I found a few >>> bugs lurking in the vfs_syscalls.c layer of the kernel. >>> >>> =A0 =A0So here's the deal... >>> >>> Problems: >>> 1. chflags/fchflags claim that the flags argument is an unsigned long, >>> whereas lchflags claims it's an int. This is inconsistent. >>> 2. The kernel interfaces are all implicitly downcasting the flags >>> argument to int. > > The downcast in the call to setfflags() is safe, but the type puns given > by the wrong types in syscalls.master are not. =A0I think the big-endian > 64-bit long case is the only case seriously broken by these puns, but > FreeBSD doesn't notice since it doesn't support any big-endian 64-bit > arches. This is incorrect unfortunately. The newest port of the PowerPC family (Sony's PS3) is actually Big Endian, and many of the other archs like ARM and MIPS of course are mixed endian :(... so I think that bugs like these will become more apparent as time goes on. >>> 3. There's a sizing/signedness discrepancy in a few other structures >>> with fixed-width data types (uint32_t). > > There are zillions of these, and with missing consts. =A0Not a single > vfs syscall supports its path arg being declared as const in > syscalls.master. =A0Adding consts there would cause more problems than > fixing type mismatches like the ones for fflags, since lower layers > are almost perfectly devoid of "const", and "downcasting" for "const" > involves removing it, and gcc would complain about that although it > is even safer than downcasting to int for vfs syscalls. > >>> Solution: >>> ... >>> >>> Compatibility: >>> 1. NetBSD uses unsigned long in their chflags calls (both in kernel >>> and userland) so they're more consistent than we are by not having >>> mixed flags calling convention like us, but uses uint32_t in their >>> data structures (like we do), so they have a 32-bit/64-bit biarch bug >>> (again like we do). > > No, NetBSD has data in syscalls.master that actually matches the arg > types for the user API for *chflags() (it even has "const" for open()), > so, it does all the downcasting correctly and doesn't have any serious > 64-bit problems. =A0At least in 2005, its set_fflags() is spelled > change_flags() and takes a u_long flags, and this seems to reach > VOP_SETATTR() correctly via "u_long va_flags;" (even 4.4BSD-Lite and > FreeBSD have "u_long va_flags"). =A0Even if the top flags bits were > clipped early as in FreeBSD, there would only be minor problems from > not detecting garbage in these bits (including the ability of application= s > to invoke undefined behaviour in the kernel, by passing garbage top > bits that cause integer overflow on blind conversion to int). =A0Everone > uses u_int32_t for st_flags, except u_int32_t is spelled fflags_t in > FreeBSD, but this doesn't cause annoy problems since it is large enough > and read-only. Hmmm... >>> 2. OpenBSD is using unsigned int, so I assume that their kernel layer >>> is also using unsigned int (I am basing this purely off the manpage as >>> I haven't looked at their sources, but I could be wrong). > > Was consistently u_long in 2005, except where it must be spelled > "unsigned long" for namespace reasons. > >> You've changed syscalls definitions but didn't add backward >> compatibility shims for kernel, libc and freebsd32. > > Probably not needed, especially of garbage in top bits is not checked > for (and checking that is not really needed. =A0There are SF_SETTABLE > and UF_SETTABLE masks which would cause garbage top bits to be silently > ignored if they are masked before checking). =A0Bit the patch doesn't > seem to touch syscalls.master. =A0That risks increasing the problem > unless everything is changed to int to match there. =A0Even if you change > like that, old 64-bit binaries still passing u_long will continue to > work, since there are no big-endian ones and ints are padded to 64 > bits in the ABI (the big-endian case breaks by padding at the wrong > end). > >> I'm working on changing ino_t to 64 bits and nlink_t to 32 bits, we >> could join the effort, as projects look related. My old patch is >> available here: >> https://github.com/downloads/glk/freebsd-ino64/freebsd-ino64-patch.tgz > > Enlarging sizes is harder :-). ... >> The struct represents on-disk protocol description, and thus shouldn't b= e >> changed. > > Indeed. =A0fflags_t is essentially only the type used in struct stat's AP= I and > ABI. =A0It started as u_int32_t too. =A0Changing the API and ABI for all > *chflags() to use it is probably safe too. Which was my reasoning, but I was a bit uneasy about this. >>> Index: sbin/restore/tape.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 >>> --- sbin/restore/tape.c (revision 217362) >>> +++ sbin/restore/tape.c (working copy) >>> @@ -558,7 +558,7 @@ >>> =A0int >>> =A0extractfile(char *name) >>> =A0{ >>> - =A0 =A0 =A0 int flags; >>> + =A0 =A0 =A0 fflags_t flags; >>> =A0 =A0 =A0 =A0uid_t uid; >>> =A0 =A0 =A0 =A0gid_t gid; >>> =A0 =A0 =A0 =A0mode_t mode; > > Unclear from the patch alone if it needs to match dump's ABI. =A0Probably= not. It does (there were some bits missing that I need to submit in a new patch)= . >>> Index: sys/kern/vfs_syscalls.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 >>> --- sys/kern/vfs_syscalls.c =A0 =A0 (revision 217362) >>> +++ sys/kern/vfs_syscalls.c =A0 =A0 (working copy) >>> @@ -96,7 +96,7 @@ >>> =A0static int getutimes(const struct timeval *, enum uio_seg, struct >>> timespec *); >>> =A0static int setfown(struct thread *td, struct vnode *, uid_t, gid_t); >>> =A0static int setfmode(struct thread *td, struct vnode *, int); >>> -static int setfflags(struct thread *td, struct vnode *, int); >>> +static int setfflags(struct thread *td, struct vnode *, fflags_t); >>> =A0static int setutimes(struct thread *td, struct vnode *, >>> =A0 =A0 const struct timespec *, int, int); >>> =A0static int vn_access(struct vnode *vp, int user_flags, struct ucred >>> *cred, > > Better to change this to whatever va_flags is. =A0The latter can remain a= s > u_long. But silent value truncation is bad, right :(? ... > Now has excessive indentation. =A0This was consistently broken with > syscalls.master. =A0Similarly for others. Eh...? Wouldn't it be worse if fflags_t >>> Index: sys/ufs/ufs/dinode.h >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- sys/ufs/ufs/dinode.h =A0 =A0 =A0 =A0(revision 217362) >>> +++ sys/ufs/ufs/dinode.h =A0 =A0 =A0 =A0(working copy) >>> @@ -140,7 +140,7 @@ >>> =A0 =A0 =A0 =A0int32_t =A0 =A0 =A0 =A0 di_birthnsec; =A0 /* =A076: Inod= e creation time. */ >>> =A0 =A0 =A0 =A0int32_t =A0 =A0 =A0 =A0 di_gen; =A0 =A0 =A0 =A0 /* =A080= : Generation number. */ >>> =A0 =A0 =A0 =A0u_int32_t =A0 =A0 =A0 di_kernflags; =A0 /* =A084: Kernel= flags. */ >>> - =A0 =A0 =A0 u_int32_t =A0 =A0 =A0 di_flags; =A0 =A0 =A0 /* =A088: Sta= tus flags (chflags). >>> */ >>> + =A0 =A0 =A0 fflags_t =A0 =A0 =A0 =A0di_flags; =A0 =A0 =A0 /* =A088: S= tatus flags (chflags). >>> */ >> >> Please revert for the same reason. > > Indeed. I'm still confused as to why silent type [width] parity issues with UFS is a good thing, especially when this change serves to unite everything under the same bit-width type (well, minus the syscalls, but that was done because it's easier to deal with function call breakage as opposed to data interpretation breakage when reading off the disk. Thanks, -Garrett From owner-freebsd-fs@FreeBSD.ORG Tue Jan 18 16:06:40 2011 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE4DF1065672 for ; Tue, 18 Jan 2011 16:06:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 554528FC18 for ; Tue, 18 Jan 2011 16:06:39 +0000 (UTC) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0IEIB23004885 for ; Wed, 19 Jan 2011 01:18:11 +1100 Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0IEI8jq027597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jan 2011 01:18:09 +1100 Date: Wed, 19 Jan 2011 01:18:08 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Gleb Kurtsou In-Reply-To: <20110118041447.GA2087@tops.skynet.lt> Message-ID: <20110118234350.R1077@besplex.bde.org> References: <20110118041447.GA2087@tops.skynet.lt> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Garrett Cooper , fs@FreeBSD.org Subject: Re: Inconsistency and bug with *chflags functions 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, 18 Jan 2011 16:06:40 -0000 On Tue, 18 Jan 2011, Gleb Kurtsou wrote: > On (17/01/2011 16:32), Garrett Cooper wrote: >> Hi FS folks, >> >> Originally I did this to determine why lchflags had an int >> argument and chflags/fchflags had unsigned long arguments, and I ran chflags/fchflags() have unsigned long args since these were wrong in 4.4BSD-Lite, and they still have unsigned long args since it is easier not to disturb sleeping bugs. lchflags() has an int arg since it was implemented in FreeBSD much later than the others, and the type error in the others was apparently intentionally avoided. (I thought the non-error for lchflags() was copied from NetBSD, but NetBSD seems to have always had u_long for all three). As you found, the kernel wants everything to be an int, and setfflags() still only accepts an int. Thus it is an error to pretend that the syscalls take args of other types. Larger types would be handled correctly if syscalls.master actually pseudo-declared ths syscalls correctly, but it still says int as in 4.4BSD-Lite for chflags/fchflags(). FreeBSD generates args structs containing the actual types from the data in syscalls.master. If the latter is correct, then the correct conversions will be done without further type puns, by normal C conversions, e.g., setfflags(..., uap->flag), where `flags' has whatever type it has and the function call converts to int. Plain ints work correctly except possibly for invalid args since the sign bit is not used by any supported flags value. >> into an interesting mini-project (by accident) after I found a few >> bugs lurking in the vfs_syscalls.c layer of the kernel. >> >> So here's the deal... >> >> Problems: >> 1. chflags/fchflags claim that the flags argument is an unsigned long, >> whereas lchflags claims it's an int. This is inconsistent. >> 2. The kernel interfaces are all implicitly downcasting the flags >> argument to int. The downcast in the call to setfflags() is safe, but the type puns given by the wrong types in syscalls.master are not. I think the big-endian 64-bit long case is the only case seriously broken by these puns, but FreeBSD doesn't notice since it doesn't support any big-endian 64-bit arches. >> 3. There's a sizing/signedness discrepancy in a few other structures >> with fixed-width data types (uint32_t). There are zillions of these, and with missing consts. Not a single vfs syscall supports its path arg being declared as const in syscalls.master. Adding consts there would cause more problems than fixing type mismatches like the ones for fflags, since lower layers are almost perfectly devoid of "const", and "downcasting" for "const" involves removing it, and gcc would complain about that although it is even safer than downcasting to int for vfs syscalls. >> Solution: >> ... >> >> Compatibility: >> 1. NetBSD uses unsigned long in their chflags calls (both in kernel >> and userland) so they're more consistent than we are by not having >> mixed flags calling convention like us, but uses uint32_t in their >> data structures (like we do), so they have a 32-bit/64-bit biarch bug >> (again like we do). No, NetBSD has data in syscalls.master that actually matches the arg types for the user API for *chflags() (it even has "const" for open()), so, it does all the downcasting correctly and doesn't have any serious 64-bit problems. At least in 2005, its set_fflags() is spelled change_flags() and takes a u_long flags, and this seems to reach VOP_SETATTR() correctly via "u_long va_flags;" (even 4.4BSD-Lite and FreeBSD have "u_long va_flags"). Even if the top flags bits were clipped early as in FreeBSD, there would only be minor problems from not detecting garbage in these bits (including the ability of applications to invoke undefined behaviour in the kernel, by passing garbage top bits that cause integer overflow on blind conversion to int). Everone uses u_int32_t for st_flags, except u_int32_t is spelled fflags_t in FreeBSD, but this doesn't cause annoy problems since it is large enough and read-only. >> 2. OpenBSD is using unsigned int, so I assume that their kernel layer >> is also using unsigned int (I am basing this purely off the manpage as >> I haven't looked at their sources, but I could be wrong). Was consistently u_long in 2005, except where it must be spelled "unsigned long" for namespace reasons. > You've changed syscalls definitions but didn't add backward > compatibility shims for kernel, libc and freebsd32. Probably not needed, especially of garbage in top bits is not checked for (and checking that is not really needed. There are SF_SETTABLE and UF_SETTABLE masks which would cause garbage top bits to be silently ignored if they are masked before checking). Bit the patch doesn't seem to touch syscalls.master. That risks increasing the problem unless everything is changed to int to match there. Even if you change like that, old 64-bit binaries still passing u_long will continue to work, since there are no big-endian ones and ints are padded to 64 bits in the ABI (the big-endian case breaks by padding at the wrong end). > I'm working on changing ino_t to 64 bits and nlink_t to 32 bits, we > could join the effort, as projects look related. My old patch is > available here: > https://github.com/downloads/glk/freebsd-ino64/freebsd-ino64-patch.tgz Enlarging sizes is harder :-). >> Index: include/protocols/dumprestore.h >> =================================================================== >> --- include/protocols/dumprestore.h (revision 217362) >> +++ include/protocols/dumprestore.h (working copy) >> @@ -95,7 +95,7 @@ >> int64_t c_mtime; /* last modified time, seconds */ >> int32_t c_extsize; /* external attribute size */ >> int32_t c_spare4[6]; /* old block pointers */ >> - u_int32_t c_file_flags; /* status flags (chflags) */ >> + fflags_t c_file_flags; /* status flags (chflags) */ > The struct represents on-disk protocol description, and thus shouldn't be changed. Indeed. fflags_t is essentially only the type used in struct stat's API and ABI. It started as u_int32_t too. Changing the API and ABI for all *chflags() to use it is probably safe too. >> Index: sbin/restore/tape.c >> =================================================================== >> --- sbin/restore/tape.c (revision 217362) >> +++ sbin/restore/tape.c (working copy) >> @@ -558,7 +558,7 @@ >> int >> extractfile(char *name) >> { >> - int flags; >> + fflags_t flags; >> uid_t uid; >> gid_t gid; >> mode_t mode; Unclear from the patch alone if it needs to match dump's ABI. Probably not. >> Index: sys/kern/vfs_syscalls.c >> =================================================================== >> --- sys/kern/vfs_syscalls.c (revision 217362) >> +++ sys/kern/vfs_syscalls.c (working copy) >> @@ -96,7 +96,7 @@ >> static int getutimes(const struct timeval *, enum uio_seg, struct timespec *); >> static int setfown(struct thread *td, struct vnode *, uid_t, gid_t); >> static int setfmode(struct thread *td, struct vnode *, int); >> -static int setfflags(struct thread *td, struct vnode *, int); >> +static int setfflags(struct thread *td, struct vnode *, fflags_t); >> static int setutimes(struct thread *td, struct vnode *, >> const struct timespec *, int, int); >> static int vn_access(struct vnode *vp, int user_flags, struct ucred *cred, Better to change this to whatever va_flags is. The latter can remain as u_long. >> @@ -2695,8 +2695,8 @@ >> */ >> #ifndef _SYS_SYSPROTO_H_ >> struct chflags_args { >> - char *path; >> - int flags; >> + char *path; >> + fflags_t flags; >> }; >> #endif >> int Now has excessive indentation. This was consistently broken with syscalls.master. Similarly for others. >> Index: sys/ufs/ufs/dinode.h >> =================================================================== >> --- sys/ufs/ufs/dinode.h (revision 217362) >> +++ sys/ufs/ufs/dinode.h (working copy) >> @@ -140,7 +140,7 @@ >> int32_t di_birthnsec; /* 76: Inode creation time. */ >> int32_t di_gen; /* 80: Generation number. */ >> u_int32_t di_kernflags; /* 84: Kernel flags. */ >> - u_int32_t di_flags; /* 88: Status flags (chflags). */ >> + fflags_t di_flags; /* 88: Status flags (chflags). */ > Please revert for the same reason. Indeed. Bruce From owner-freebsd-fs@FreeBSD.ORG Tue Jan 18 16:48:13 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE1BE1065673 for ; Tue, 18 Jan 2011 16:48:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 528428FC12 for ; Tue, 18 Jan 2011 16:48:12 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p0IGGbQi076806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 18:16:37 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p0IGGbUx010780; Tue, 18 Jan 2011 18:16:37 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p0IGGbs6010779; Tue, 18 Jan 2011 18:16:37 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 18 Jan 2011 18:16:37 +0200 From: Kostik Belousov To: Bruce Evans Message-ID: <20110118161637.GS2518@deviant.kiev.zoral.com.ua> References: <20110118041447.GA2087@tops.skynet.lt> <20110118234350.R1077@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6QoWHXajryvO0ZWw" Content-Disposition: inline In-Reply-To: <20110118234350.R1077@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: fs@freebsd.org Subject: Re: Inconsistency and bug with *chflags functions 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, 18 Jan 2011 16:48:14 -0000 --6QoWHXajryvO0ZWw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jan 19, 2011 at 01:18:08AM +1100, Bruce Evans wrote: > The downcast in the call to setfflags() is safe, but the type puns given > by the wrong types in syscalls.master are not. I think the big-endian > 64-bit long case is the only case seriously broken by these puns, but > FreeBSD doesn't notice since it doesn't support any big-endian 64-bit > arches. Just a note, do you consider sparc64/mips64/powerpc64 unsupported ? --6QoWHXajryvO0ZWw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk01vOUACgkQC3+MBN1Mb4h45QCfYEnSzBwnyzODmxQF2/V1szut QZwAn1M7r6UCgz3mTmtNRXQB84iPHcuy =+lgk -----END PGP SIGNATURE----- --6QoWHXajryvO0ZWw-- From owner-freebsd-fs@FreeBSD.ORG Tue Jan 18 16:49:10 2011 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 500791065675 for ; Tue, 18 Jan 2011 16:49:10 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id CC7758FC0A for ; Tue, 18 Jan 2011 16:49:09 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0IGn3dV011048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jan 2011 03:49:07 +1100 Date: Wed, 19 Jan 2011 03:49:03 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Garrett Cooper In-Reply-To: Message-ID: <20110119030959.I2099@besplex.bde.org> References: <20110118041447.GA2087@tops.skynet.lt> <20110118234350.R1077@besplex.bde.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-781286865-1295369343=:2099" Cc: fs@FreeBSD.org Subject: Re: Inconsistency and bug with *chflags functions 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, 18 Jan 2011 16:49:10 -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-781286865-1295369343=:2099 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 18 Jan 2011, Garrett Cooper wrote: > On Tue, Jan 18, 2011 at 6:18 AM, Bruce Evans wrote= : >> On Tue, 18 Jan 2011, Gleb Kurtsou wrote: > > ... > >> As you found, the kernel wants everything to be an int, and setfflags() >> still only accepts an int. ... [Quote trimmed at the first hard \xa0] > Signedness isn't important for this flag. Only width and data > alignment as you suggested elsewhere. Not important, but it allows undefined behaviour. >>>> 2. The kernel interfaces are all implicitly downcasting the flags >>>> argument to int. >> >> The downcast in the call to setfflags() is safe, but the type puns given >> by the wrong types in syscalls.master are not. =A0I think the big-endian >> 64-bit long case is the only case seriously broken by these puns, but >> FreeBSD doesn't notice since it doesn't support any big-endian 64-bit >> arches. > > This is incorrect unfortunately. The newest port of the PowerPC family > (Sony's PS3) is actually Big Endian, and many of the other archs like > ARM and MIPS of course are mixed endian :(... so I think that bugs > like these will become more apparent as time goes on. I think these are still unsupported, since chflags() cannot work on them :-= ). >>> The struct represents on-disk protocol description, and thus shouldn't = be >>> changed. >> >> Indeed. =A0fflags_t is essentially only the type used in struct stat's A= PI and >> ABI. =A0It started as u_int32_t too. =A0Changing the API and ABI for all >> *chflags() to use it is probably safe too. > > Which was my reasoning, but I was a bit uneasy about this. You can't really start from 1 read-only API. This API only tells us that there are at most 32 flags. > >>>> Index: sbin/restore/tape.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 >>>> --- sbin/restore/tape.c (revision 217362) >>>> +++ sbin/restore/tape.c (working copy) >>>> @@ -558,7 +558,7 @@ >>>> =A0int >>>> =A0extractfile(char *name) >>>> =A0{ >>>> - =A0 =A0 =A0 int flags; >>>> + =A0 =A0 =A0 fflags_t flags; >>>> =A0 =A0 =A0 =A0uid_t uid; >>>> =A0 =A0 =A0 =A0gid_t gid; >>>> =A0 =A0 =A0 =A0mode_t mode; >> >> Unclear from the patch alone if it needs to match dump's ABI. =A0Probabl= y not. > > It does (there were some bits missing that I need to submit in a new patc= h). I checked it and don't see any problems except possibly compiler warnings about type matches that turn out to be harmless. The value just gets converted to int when read from the dump (was u_int32_t there) and from int when passed to chflags() (was u_long there). "int" is large enough unless the dump has garbage flags. >>>> Index: sys/kern/vfs_syscalls.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 >>>> --- sys/kern/vfs_syscalls.c =A0 =A0 (revision 217362) >>>> +++ sys/kern/vfs_syscalls.c =A0 =A0 (working copy) >>>> @@ -96,7 +96,7 @@ >>>> =A0static int getutimes(const struct timeval *, enum uio_seg, struct >>>> timespec *); >>>> =A0static int setfown(struct thread *td, struct vnode *, uid_t, gid_t)= ; >>>> =A0static int setfmode(struct thread *td, struct vnode *, int); >>>> -static int setfflags(struct thread *td, struct vnode *, int); >>>> +static int setfflags(struct thread *td, struct vnode *, fflags_t); >>>> =A0static int setutimes(struct thread *td, struct vnode *, >>>> =A0 =A0 const struct timespec *, int, int); >>>> =A0static int vn_access(struct vnode *vp, int user_flags, struct ucred >>>> *cred, >> >> Better to change this to whatever va_flags is. =A0The latter can remain = as >> u_long. > > But silent value truncation is bad, right :(? Yes, but we always did it. You don't want to make ABI problems larger by adding strictness now. I checked what ufs does. It is sloppy for root -- allows anything in the user-supplied to be put into on-disk flags (after truncation to 32 bits). For non-root, it only allows user flags to be changed, but the mask for this includes 11 flags that have no assigned meaning. Users can use this to store 11 bits of data in an empty file :-). %=20 % Script started on Wed Jan 19 03:36:19 2011 % ttyv6:bde@besplex:/tmp/q> >z % ttyv6:bde@besplex:/tmp/q> chflags 177777 z % ttyv6:bde@besplex:/tmp/q> ls -lo z % -rw-r--r-- 1 bde wheel uappnd,uchg,nodump,opaque,uunlnk 0 Jan 19 03:36= z % ttyv6:bde@besplex:/tmp/q> /usr/bin/stat z % 256768 1186 -rw-r--r-- 1 bde wheel 0 0 "Jan 19 03:36:21 2011" "Jan 19 03:= 36:21 2011" "Jan 19 03:36:29 2011" "Jan 1 10:00:00 1970" 8192 0 0xffff z 0xffff is my 11 bites of data (5 flags and 11 bits not reported by ls or flagstostr() generally. % ttyv6:bde@besplex:/tmp/q> chflags 377777 z % chflags: z: Operation not permitted Setting 1 system bit is correctly not allowed. % ttyv6:bde@besplex:/tmp/q> chflags 0 z % ttyv6:bde@besplex:/tmp/q> rm z % ttyv6:bde@besplex:/tmp/q> exit %=20 % Script done on Wed Jan 19 03:37:00 2011 > ... > >> Now has excessive indentation. =A0This was consistently broken with >> syscalls.master. =A0Similarly for others. > > Eh...? Wouldn't it be worse if fflags_t The quote isn't there and the reply is truncated :-). Indentation is 8 columns after a type. I don't like indenting all the variable names because 1 type name is too verbose. >>>> Index: sys/ufs/ufs/dinode.h >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- sys/ufs/ufs/dinode.h =A0 =A0 =A0 =A0(revision 217362) >>>> +++ sys/ufs/ufs/dinode.h =A0 =A0 =A0 =A0(working copy) >>>> @@ -140,7 +140,7 @@ >>>> =A0 =A0 =A0 =A0int32_t =A0 =A0 =A0 =A0 di_birthnsec; =A0 /* =A076: Ino= de creation time. */ >>>> =A0 =A0 =A0 =A0int32_t =A0 =A0 =A0 =A0 di_gen; =A0 =A0 =A0 =A0 /* =A08= 0: Generation number. */ >>>> =A0 =A0 =A0 =A0u_int32_t =A0 =A0 =A0 di_kernflags; =A0 /* =A084: Kerne= l flags. */ >>>> - =A0 =A0 =A0 u_int32_t =A0 =A0 =A0 di_flags; =A0 =A0 =A0 /* =A088: St= atus flags (chflags). >>>> */ >>>> + =A0 =A0 =A0 fflags_t =A0 =A0 =A0 =A0di_flags; =A0 =A0 =A0 /* =A088: = Status flags (chflags). >>>> */ Unreadble due to MUA mangling of spaces. >>> Please revert for the same reason. >> >> Indeed. > > I'm still confused as to why silent type [width] parity issues with > UFS is a good thing, especially when this change serves to unite > everything under the same bit-width type (well, minus the syscalls, > but that was done because it's easier to deal with function call > breakage as opposed to data interpretation breakage when reading off > the disk. ffs can only hold 32-bit flags no matter what fflags_t is. If you want to change this in ffs, then you have to write ffs3, and there are more important things to change in it then. OTOH, changing fflags_t wont affect ffs, even if some new bits in it are actually used. ffs just won't understand these bits and will return an error for attempts to set them, at least when it is fixed to not silently ignore them. (Actually using old bits is more of a problem. Users may already be using them for storing data :-)). Bruce --0-781286865-1295369343=:2099-- From owner-freebsd-fs@FreeBSD.ORG Tue Jan 18 17:10:09 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54D82106564A for ; Tue, 18 Jan 2011 17:10:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 393BC8FC13 for ; Tue, 18 Jan 2011 17:10:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0IHA9Zm018606 for ; Tue, 18 Jan 2011 17:10:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0IHA9PL018605; Tue, 18 Jan 2011 17:10:09 GMT (envelope-from gnats) Date: Tue, 18 Jan 2011 17:10:09 GMT Message-Id: <201101181710.p0IHA9PL018605@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Alexander Naumochkin Cc: Subject: Re: kern/153996: [zfs] zfs root mount error while kernel is not located in /boot/kernel X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Naumochkin List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 17:10:09 -0000 The following reply was made to PR kern/153996; it has been noted by GNATS. From: Alexander Naumochkin To: Garrett Cooper Cc: bug-followup@freebsd.org Subject: Re: kern/153996: [zfs] zfs root mount error while kernel is not located in /boot/kernel Date: Tue, 18 Jan 2011 19:37:11 +0300 --0016362851685385ff049a2184a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Garrett, now I have two kernels on my box: 1. /boot/kernel/kernel =E2=80=94 my working customized kernel 2. /boot/GENERIC/kernel =E2=80=94 GENERIC kernel I tried the following expreriment: # shutdown -r now wait for loader menu and choose 6 - Escape to loader prompt OK unload kernel OK set kernelname=3D/boot/GENERIC/kernel OK set module_path=3D/boot/GENERIC OK load opensolaris OK load zfs OK boot and got the same result: "MOUNT ROOT ERROR" while "Trying to mount root fro= m zfs:zroot" BTW, even if your method would work, it could not help in case of install misconfigured unbootable kernel. Let's say I install misconfigured kernel: # make installkernel KERNCONF=3DBADKRNL After this I get: 1. bad kernel in /boot/kernel/kernel 2. previous working kernel in /boot/kernel.old/kernel 3. GENERIC kernel in /boot/GENERIC/kernel I reboot and faced with unbootable system (because of BADKRNL as default). In fact we have now completely unbootable system due the bug I've reported with this PR. Also this bug means that from now on we have no possibility t= o test custom kernels by installing it to alternate directory (with KODIR variable) =E2=80=94 it will not boot anyway. Regards, /Alexander On Tue, Jan 18, 2011 at 3:56 AM, Garrett Cooper wrote= : > Alexander, > Have you tried setting kernelname to GCAM in your loader.conf > before booting (it's not documented in loader.conf but it's a part of > boot)? > Another item I use to switch between kernels is symlink the suckers: > > $ ls -l /boot/kernel > lrwxr-xr-x 1 root wheel 17 Jan 13 17:35 /boot/kernel -> > BAYONETTA.r217362 > > This works well. > HTH, > -Garrett > --=20 /ash --0016362851685385ff049a2184a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Garrett,

now I have two kernels on my box:
1. = /boot/kernel/kernel =E2=80=94 my working customized kernel
2. /bo= ot/GENERIC/kernel =E2=80=94 GENERIC kernel

I tried= the following expreriment:

# shutdown -r now

wait for loa= der menu and choose 6 - Escape to loader prompt

OK= unload kernel
OK set kernelname=3D/boot/GENERIC/kernel
OK set module_path=3D/boot/GENERIC
OK load opensolaris
= OK load zfs
OK boot

and got the same res= ult: "MOUNT ROOT ERROR" while "Trying to mount root from zfs= :zroot"

BTW, even if your method would work, it could not help = in case of install misconfigured unbootable kernel. Let's say I install= misconfigured kernel:

# make installkernel KERNCO= NF=3DBADKRNL

After this I get:

1. bad kerne= l in /boot/kernel/kernel
2. previous working kernel in /boot/kern= el.old/kernel
3. GENERIC kernel in /boot/GENERIC/kernel

I reboot and faced with unbootable system (because of B= ADKRNL as default). In fact we have now completely unbootable system due th= e bug I've reported with this PR. Also this bug means that from now on = we have no possibility to test custom kernels by installing it to alternate= directory (with KODIR variable) =E2=80=94 it will not boot anyway.

Regards,
/Alexander

On Tue, Jan 18, 2011 at 3:56 AM, Garrett Cooper <gcooper@freebsd.org> wrote:
Alexander,
=C2=A0 =C2=A0Have you tried setting kernelname to GCAM in your loader.conf=
before booting (it's not documented in loader.conf but it's a part = of
boot)?
=C2=A0 =C2=A0Another item I use to switch between kernels is symlink the s= uckers:

$ ls -l /boot/kernel
lrwxr-xr-x =C2=A01 root =C2=A0wheel =C2=A017 Jan 13 17:35 /boot/kernel ->= ; BAYONETTA.r217362

=C2=A0 =C2=A0This works well.
HTH,
-Garrett



--
/ash
--0016362851685385ff049a2184a1-- From owner-freebsd-fs@FreeBSD.ORG Tue Jan 18 18:06:22 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0A24106566C for ; Tue, 18 Jan 2011 18:06:22 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 449658FC08 for ; Tue, 18 Jan 2011 18:06:21 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0II6JBi018272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jan 2011 05:06:20 +1100 Date: Wed, 19 Jan 2011 05:06:19 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kostik Belousov In-Reply-To: <20110118161637.GS2518@deviant.kiev.zoral.com.ua> Message-ID: <20110119045713.N2631@besplex.bde.org> References: <20110118041447.GA2087@tops.skynet.lt> <20110118234350.R1077@besplex.bde.org> <20110118161637.GS2518@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: fs@freebsd.org Subject: Re: Inconsistency and bug with *chflags functions 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, 18 Jan 2011 18:06:22 -0000 On Tue, 18 Jan 2011, Kostik Belousov wrote: > On Wed, Jan 19, 2011 at 01:18:08AM +1100, Bruce Evans wrote: >> The downcast in the call to setfflags() is safe, but the type puns given >> by the wrong types in syscalls.master are not. I think the big-endian >> 64-bit long case is the only case seriously broken by these puns, but >> FreeBSD doesn't notice since it doesn't support any big-endian 64-bit >> arches. > Just a note, do you consider sparc64/mips64/powerpc64 unsupported ? No. I forget that sparc64 is big-endian so this has been tested for long enough to find any bugs, and didn't worry about the others since they are relatively new. In fact, there seems to be no problem with unsigned long fflags on 64-bit bit-endian either, since the least significant bits end up in the top bits of each arg in the args struct no matter how syscalls.master (mis)declares them. Little-endian is of course exactly the opposite. Bruce From owner-freebsd-fs@FreeBSD.ORG Tue Jan 18 21:30:11 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1DED1065672 for ; Tue, 18 Jan 2011 21:30:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7591F8FC13 for ; Tue, 18 Jan 2011 21:30:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0ILUBRo095316 for ; Tue, 18 Jan 2011 21:30:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0ILUBeF095310; Tue, 18 Jan 2011 21:30:11 GMT (envelope-from gnats) Date: Tue, 18 Jan 2011 21:30:11 GMT Message-Id: <201101182130.p0ILUBeF095310@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Pedro F. Giffuni" Cc: Subject: Re: kern/153584: [ext2fs] [patch] Performance fix and cleanups for BSD licensed ext2fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Pedro F. Giffuni" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 21:30:11 -0000 The following reply was made to PR kern/153584; it has been noted by GNATS. From: "Pedro F. Giffuni" To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/153584: [ext2fs] [patch] Performance fix and cleanups for BSD licensed ext2fs Date: Tue, 18 Jan 2011 13:24:51 -0800 (PST) --0-1498478816-1295385891=:52958 Content-Type: text/plain; charset=us-ascii Oops.. cleanup some comments that were not supposed to be there. While here, I should mention that Bruce Evans' patch has been giving some great results with blogbench: http://blogs.freebsdish.org/liuzheng/2011/01/10/ext2fs-performance-benchmark-blogbench/ and bonnie++ http://blogs.freebsdish.org/liuzheng/2011/01/18/ext2fs-performance-benchmark-bonnie/ --0-1498478816-1295385891=:52958 Content-Type: text/plain; name="patch-ext2fs.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-ext2fs.txt" ZGlmZiAtcnUgZXh0MmZzLm9yaWcvZXh0Ml9hbGxvYy5jIGV4dDJmcy9leHQy X2FsbG9jLmMKLS0tIGV4dDJmcy5vcmlnL2V4dDJfYWxsb2MuYwkyMDExLTAx LTE4IDE1OjQwOjMyLjAwMDAwMDAwMCArMDAwMAorKysgZXh0MmZzL2V4dDJf YWxsb2MuYwkyMDExLTAxLTE4IDE1OjUwOjM1LjAwMDAwMDAwMCArMDAwMApA QCAtNTksNiArNTksMTAgQEAKIAkJCQkJCWludCkpOwogc3RhdGljIGRhZGRy X3QJZXh0Ml9ub2RlYWxsb2NjZyhzdHJ1Y3QgaW5vZGUgKiwgaW50LCBkYWRk cl90LCBpbnQpOwogc3RhdGljIGRhZGRyX3QgIGV4dDJfbWFwc2VhcmNoKHN0 cnVjdCBtX2V4dDJmcyAqLCBjaGFyICosIGRhZGRyX3QpOworI2lmZGVmIEZB TkNZX1JFQUxMT0MKK3N0YXRpYyBpbnQJZXh0Ml9yZWFsbG9jYmxrcyhzdHJ1 Y3Qgdm9wX3JlYWxsb2NibGtzX2FyZ3MgKik7CisjZW5kaWYKKwogLyoKICAq IEFsbG9jYXRlIGEgYmxvY2sgaW4gdGhlIGZpbGUgc3lzdGVtLgogICoKQEAg LTc2LDcgKzgwLDYgQEAKICAqICAgMikgcXVhZHJhZGljYWxseSByZWhhc2gg aW50byBvdGhlciBjeWxpbmRlciBncm91cHMsIHVudGlsIGFuCiAgKiAgICAg ICAgYXZhaWxhYmxlIGJsb2NrIGlzIGxvY2F0ZWQuCiAgKi8KLQogaW50CiBl eHQyX2FsbG9jKGlwLCBsYm4sIGJwcmVmLCBzaXplLCBjcmVkLCBibnApCiAJ c3RydWN0IGlub2RlICppcDsKQEAgLTExNiw2ICsxMTksMTAgQEAKICAgICAg ICAgYm5vID0gKGRhZGRyX3QpZXh0Ml9oYXNoYWxsb2MoaXAsIGNnLCBicHJl ZiwgZnMtPmUyZnNfYnNpemUsCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgZXh0Ml9hbGxvY2NnKTsKICAgICAg ICAgaWYgKGJubyA+IDApIHsKKwkJLyogc2V0IG5leHRfYWxsb2MgZmllbGRz IGFzIGRvbmUgaW4gYmxvY2tfZ2V0YmxrICovCisJCWlwLT5pX25leHRfYWxs b2NfYmxvY2sgPSBsYm47CisJCWlwLT5pX25leHRfYWxsb2NfZ29hbCA9IGJu bzsKKwogICAgICAgICAgICAgICAgIGlwLT5pX2Jsb2NrcyArPSBidG9kYihm cy0+ZTJmc19ic2l6ZSk7CiAgICAgICAgICAgICAgICAgaXAtPmlfZmxhZyB8 PSBJTl9DSEFOR0UgfCBJTl9VUERBVEU7CiAgICAgICAgICAgICAgICAgKmJu cCA9IGJubzsKQEAgLTE0NCw5ICsxNTEsMTMgQEAKICAqLwogCiAjaWZkZWYg RkFOQ1lfUkVBTExPQwotI2luY2x1ZGUgPHN5cy9zeXNjdGwuaD4KK1NZU0NU TF9OT0RFKF92ZnMsIE9JRF9BVVRPLCBleHQyLCBDVExGTEFHX1JXLCAwLCAi RVhUMkZTIGZpbGVzeXN0ZW0iKTsKKwogc3RhdGljIGludCBkb2FzeW5jZnJl ZSA9IDE7CitTWVNDVExfSU5UKF92ZnNfZXh0MiwgT0lEX0FVVE8sIGRvYXN5 bmNmcmVlLCBDVExGTEFHX1JXLCAmZG9hc3luY2ZyZWUsIDAsICIiKTsKKwog c3RhdGljIGludCBkb3JlYWxsb2NibGtzID0gMTsKK1NZU0NUTF9JTlQoX3Zm c19leHQycywgT0lEX0FVVE8sIGRvcmVhbGxvY2Jsa3MsIENUTEZMQUdfUlcs ICZkb3JlYWxsb2NibGtzLCAwLCAiIik7CiAKICNpZmRlZglPUFRfREVCVUcK IFNZU0NUTF9JTlQoX2RlYnVnLCAxNCwgZG9hc3luY2ZyZWUsIENUTEZMQUdf UlcsICZkb2FzeW5jZnJlZSwgMCwgIiIpOwpAQCAtMjIyLDcgKzIzMyw3IEBA CiAJLyoKIAkgKiBGaW5kIHRoZSBwcmVmZXJyZWQgbG9jYXRpb24gZm9yIHRo ZSBjbHVzdGVyLgogCSAqLwotCUVYVDJfTE9DSyh1bXApOyAKKwlFWFQyX0xP Q0sodW1wKTsKIAlwcmVmID0gZXh0Ml9ibGtwcmVmKGlwLCBzdGFydF9sYm4s IHNvZmYsIHNiYXAsIGJsa25vKTsKIAkvKgogCSAqIElmIHRoZSBibG9jayBy YW5nZSBzcGFucyB0d28gYmxvY2sgbWFwcywgZ2V0IHRoZSBzZWNvbmQgbWFw LgpAQCAtNjI1LDcgKzYzNiw3IEBACiAJc3RydWN0IG1fZXh0MmZzICpmczsK IAlzdHJ1Y3QgYnVmICpicDsKIAlzdHJ1Y3QgZXh0Mm1vdW50ICp1bXA7Ci0J aW50IGVycm9yLCBibm8sIHN0YXJ0LCBlbmQsIGxvYzsKKwlpbnQgZXJyb3Is IGJubzsKIAljaGFyICpiYnA7CiAJLyogWFhYIG9uZGlzazMyICovCiAJZnMg PSBpcC0+aV9lMmZzOwpAQCAtNjU4LDI2ICs2NjksNyBAQAogCS8qCiAJICog bm8gYmxvY2tzIGluIHRoZSByZXF1ZXN0ZWQgY3lsaW5kZXIsIHNvIHRha2Ug bmV4dAogCSAqIGF2YWlsYWJsZSBvbmUgaW4gdGhpcyBjeWxpbmRlciBncm91 cC4KLQkgKiBmaXJzdCB0cnkgdG8gZ2V0IDggY29udGlnb3VzIGJsb2Nrcywg dGhlbiBmYWxsIGJhY2sgdG8gYSBzaW5nbGUKLQkgKiBibG9jay4KIAkgKi8K LQlpZiAoYnByZWYpCi0JCXN0YXJ0ID0gZHRvZ2QoZnMsIGJwcmVmKSAvIE5C Qlk7Ci0JZWxzZQotCQlzdGFydCA9IDA7Ci0JZW5kID0gaG93bWFueShmcy0+ ZTJmcy0+ZTJmc19mcGcsIE5CQlkpIC0gc3RhcnQ7Ci0JZm9yIChsb2MgPSBz dGFydDsgbG9jIDwgZW5kOyBsb2MrKykgewotCQlpZiAoYmJwW2xvY10gPT0g MCkgewotCQkJYm5vID0gbG9jICogTkJCWTsKLQkJCWdvdG8gZ290aXQ7Ci0J CX0KLQl9Ci0JZm9yIChsb2MgPSAwOyBsb2MgPCBzdGFydDsgbG9jKyspIHsK LQkJaWYgKGJicFtsb2NdID09IDApIHsKLQkJCWJubyA9IGxvYyAqIE5CQlk7 Ci0JCQlnb3RvIGdvdGl0OwotCQl9Ci0JfQogCiAJYm5vID0gZXh0Ml9tYXBz ZWFyY2goZnMsIGJicCwgYnByZWYpOwogCWlmIChibm8gPCAwKXsKT25seSBp biBleHQyZnM6IGV4dDJfYWxsb2MuY34KZGlmZiAtcnUgZXh0MmZzLm9yaWcv ZXh0Ml9kaW5vZGUuaCBleHQyZnMvZXh0Ml9kaW5vZGUuaAotLS0gZXh0MmZz Lm9yaWcvZXh0Ml9kaW5vZGUuaAkyMDExLTAxLTE4IDE1OjQwOjMyLjAwMDAw MDAwMCArMDAwMAorKysgZXh0MmZzL2V4dDJfZGlub2RlLmgJMjAxMS0wMS0x OCAxNTo0Mjo0NS4wMDAwMDAwMDAgKzAwMDAKQEAgLTMyLDYgKzMyLDE4IEBA CiAjZGVmaW5lIGUyZGlfc2l6ZV9oaWdoCWUyZGlfZGFjbAogCiAvKgorICog U3BlY2lhbCBpbm9kZSBudW1iZXJzCisgKiBUaGUgcm9vdCBpbm9kZSBpcyB0 aGUgcm9vdCBvZiB0aGUgZmlsZSBzeXN0ZW0uICBJbm9kZSAwIGNhbid0IGJl IHVzZWQgZm9yCisgKiBub3JtYWwgcHVycG9zZXMgYW5kIGJhZCBibG9ja3Mg YXJlIG5vcm1hbGx5IGxpbmtlZCB0byBpbm9kZSAxLCB0aHVzCisgKiB0aGUg cm9vdCBpbm9kZSBpcyAyLgorICogSW5vZGUgMyB0byAxMCBhcmUgcmVzZXJ2 ZWQgaW4gZXh0MmZzLgorICovCisjZGVmaW5lIEVYVDJfQkFEX0lOTwkJIDEJ LyogQmFkIGJsb2NrcyBpbm9kZSAqLworI2RlZmluZSBFWFQyX1JPT1RfSU5P CQkgMgkvKiBSb290IGlub2RlICovCisjZGVmaW5lIEVYVDJfQk9PVF9MT0FE RVJfSU5PCSA1CS8qIEJvb3QgbG9hZGVyIGlub2RlICovCisjZGVmaW5lIEVY VDJfVU5ERUxfRElSX0lOTwkgNgkvKiBVbmRlbGV0ZSBkaXJlY3RvcnkgaW5v ZGUgKi8KKworLyoKICAqIElub2RlIGZsYWdzCiAgKiBUaGUgY3VycmVudCBp bXBsZW1lbnRhdGlvbiB1c2VzIG9ubHkgRVhUMl9JTU1VVEFCTEUgYW5kIEVY VDJfQVBQRU5EIGZsYWdzCiAgKi8KQEAgLTc0LDUgKzg2LDUgQEAKIAl1X2lu dDMyX3QJZTJkaV9saW51eF9yZXNlcnZlZDM7IC8qIDEyNCAqLwogfTsKIAot I2VuZGlmIC8qIF9GU19FWFQyRlNfRVhUMl9ESU5PREVfSF8gKi8KKyNlbmRp ZiAvKiAhX0ZTX0VYVDJGU19FWFQyX0RJTk9ERV9IXyAqLwogCmRpZmYgLXJ1 IGV4dDJmcy5vcmlnL2V4dDJfbG9va3VwLmMgZXh0MmZzL2V4dDJfbG9va3Vw LmMKLS0tIGV4dDJmcy5vcmlnL2V4dDJfbG9va3VwLmMJMjAxMS0wMS0xOCAx NTo0MDozMi4wMDAwMDAwMDAgKzAwMDAKKysrIGV4dDJmcy9leHQyX2xvb2t1 cC5jCTIwMTEtMDEtMTggMTU6NDI6NDUuMDAwMDAwMDAwICswMDAwCkBAIC0z NDcsNiArMzQ3LDcgQEAKIAkJc2xvdG5lZWRlZCA9IChzaXplb2Yoc3RydWN0 IGRpcmVjdCkgLSBNQVhOQU1MRU4gKwogCQkJY25wLT5jbl9uYW1lbGVuICsg MykgJn4gMzsgKi8KIAl9CisJYm1hc2sgPSBWRlNUT0VYVDIodmRwLT52X21v dW50KS0+dW1fbW91bnRwLT5tbnRfc3RhdC5mX2lvc2l6ZSAtIDE7CiAKIAkv KgogCSAqIElmIHRoZXJlIGlzIGNhY2hlZCBpbmZvcm1hdGlvbiBvbiBhIHBy ZXZpb3VzIHNlYXJjaCBvZgpAQCAtMzU5LDcgKzM2MCw2IEBACiAJICogcHJv ZmlsaW5nIHRpbWUgYW5kIGhlbmNlIGhhcyBiZWVuIHJlbW92ZWQgaW4gdGhl IGludGVyZXN0CiAJICogb2Ygc2ltcGxpY2l0eS4KIAkgKi8KLQlibWFzayA9 IFZGU1RPRVhUMih2ZHAtPnZfbW91bnQpLT51bV9tb3VudHAtPm1udF9zdGF0 LmZfaW9zaXplIC0gMTsKIAlpZiAobmFtZWlvcCAhPSBMT09LVVAgfHwgaV9k aXJvZmYgPT0gMCB8fAogCSAgICBpX2Rpcm9mZiA+IGRwLT5pX3NpemUpIHsK IAkJZW50cnlvZmZzZXRpbmJsb2NrID0gMDsKZGlmZiAtcnUgZXh0MmZzLm9y aWcvZXh0Ml9zdWJyLmMgZXh0MmZzL2V4dDJfc3Vici5jCi0tLSBleHQyZnMu b3JpZy9leHQyX3N1YnIuYwkyMDExLTAxLTE4IDE1OjQwOjMyLjAwMDAwMDAw MCArMDAwMAorKysgZXh0MmZzL2V4dDJfc3Vici5jCTIwMTEtMDEtMTggMTU6 NDI6NDUuMDAwMDAwMDAwICswMDAwCkBAIC0xMDUsNyArMTA1LDcgQEAKIAlm b3IgKGVwID0gYnVmOyBlcCA8IGVicDsgZXArKykgewogCQlpZiAoZXAgPT0g YnAgfHwgKGVwLT5iX2ZsYWdzICYgQl9JTlZBTCkpCiAJCQljb250aW51ZTsK LQkJdnAgPSBpcC0+aV9kZXZ2cDsKKwkJdnAgPSBpcC0+aV91bXAtPnVtX2Rl dnZwOwogCQkvKiBsb29rIGZvciBvdmVybGFwICovCiAJCWlmIChlcC0+Yl9i Y291bnQgPT0gMCB8fCBlcC0+Yl9ibGtubyA+IGxhc3QgfHwKIAkJICAgIGVw LT5iX2Jsa25vICsgYnRvZGIoZXAtPmJfYmNvdW50KSA8PSBzdGFydCkKZGlm ZiAtcnUgZXh0MmZzLm9yaWcvZXh0Ml92ZnNvcHMuYyBleHQyZnMvZXh0Ml92 ZnNvcHMuYwotLS0gZXh0MmZzLm9yaWcvZXh0Ml92ZnNvcHMuYwkyMDExLTAx LTE4IDE1OjQwOjMyLjAwMDAwMDAwMCArMDAwMAorKysgZXh0MmZzL2V4dDJf dmZzb3BzLmMJMjAxMS0wMS0xOCAxNTo0Mjo0NS4wMDAwMDAwMDAgKzAwMDAK QEAgLTk1LDkgKzk1LDkgQEAKIHN0YXRpYyBpbnQJY29tcHV0ZV9zYl9kYXRh KHN0cnVjdCB2bm9kZSAqIGRldnZwLAogCQkgICAgc3RydWN0IGV4dDJmcyAq IGVzLCBzdHJ1Y3QgbV9leHQyZnMgKiBmcyk7CiAKLXN0YXRpYyBjb25zdCBj aGFyICpleHQyX29wdHNbXSA9IHsgImZyb20iLCAiZXhwb3J0IiwgImFjbHMi LCAibm9leGVjIiwKLSAgICAibm9hdGltZSIsICJ1bmlvbiIsICJzdWlkZGly IiwgIm11bHRpbGFiZWwiLCAibm9zeW1mb2xsb3ciLAotICAgICJub2NsdXN0 ZXJyIiwgIm5vY2x1c3RlcnciLCAiZm9yY2UiLCBOVUxMIH07CitzdGF0aWMg Y29uc3QgY2hhciAqZXh0Ml9vcHRzW10gPSB7ICJhY2xzIiwgImFzeW5jIiwg Im5vYXRpbWUiLCAibm9jbHVzdGVyciIsIAorICAgICJub2NsdXN0ZXJ3Iiwg Im5vZXhlYyIsICJleHBvcnQiLCAiZm9yY2UiLCAiZnJvbSIsICJtdWx0aWxh YmVsIiwKKyAgICAic3VpZGRpciIsICJub3N5bWZvbGxvdyIsICJzeW5jIiwg InVuaW9uIiwgTlVMTCB9OwogCiAvKgogICogVkZTIE9wZXJhdGlvbnMuCkBA IC05NDUsOSArOTQ1LDggQEAKIAl9CiAKIAkvKgotCSAqIEZpbmlzaCBpbm9k ZSBpbml0aWFsaXphdGlvbiBub3cgdGhhdCBhbGlhc2luZyBoYXMgYmVlbiBy ZXNvbHZlZC4KKwkgKiBGaW5pc2ggaW5vZGUgaW5pdGlhbGl6YXRpb24uCiAJ ICovCi0JaXAtPmlfZGV2dnAgPSB1bXAtPnVtX2RldnZwOwogCiAJLyoKIAkg KiBTZXQgdXAgYSBnZW5lcmF0aW9uIG51bWJlciBmb3IgdGhpcyBpbm9kZSBp ZiBpdCBkb2VzIG5vdApkaWZmIC1ydSBleHQyZnMub3JpZy9leHQyZnMuaCBl eHQyZnMvZXh0MmZzLmgKLS0tIGV4dDJmcy5vcmlnL2V4dDJmcy5oCTIwMTEt MDEtMTggMTU6NDA6MzIuMDAwMDAwMDAwICswMDAwCisrKyBleHQyZnMvZXh0 MmZzLmgJMjAxMS0wMS0xOCAxNTo1NTozNC4wMDAwMDAwMDAgKzAwMDAKQEAg LTM5LDIyICszOSw2IEBACiAKICNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KIAot LyoKLSAqIFNwZWNpYWwgaW5vZGUgbnVtYmVycwotICovCi0jZGVmaW5lCUVY VDJfQkFEX0lOTwkJIDEJLyogQmFkIGJsb2NrcyBpbm9kZSAqLwotI2RlZmlu ZSBFWFQyX1JPT1RfSU5PCQkgMgkvKiBSb290IGlub2RlICovCi0jZGVmaW5l IEVYVDJfQk9PVF9MT0FERVJfSU5PCSA1CS8qIEJvb3QgbG9hZGVyIGlub2Rl ICovCi0jZGVmaW5lIEVYVDJfVU5ERUxfRElSX0lOTwkgNgkvKiBVbmRlbGV0 ZSBkaXJlY3RvcnkgaW5vZGUgKi8KLQotLyogRmlyc3Qgbm9uLXJlc2VydmVk IGlub2RlIGZvciBvbGQgZXh0MiBmaWxlc3lzdGVtcyAqLwotI2RlZmluZSBF MkZTX1JFVjBfRklSU1RfSU5PCTExCi0KLS8qCi0gKiBUaGUgc2Vjb25kIGV4 dGVuZGVkIGZpbGUgc3lzdGVtIG1hZ2ljIG51bWJlcgotICovCi0jZGVmaW5l IEUyRlNfTUFHSUMJCTB4RUY1MwotCiAjaWYgZGVmaW5lZChfS0VSTkVMKQog LyoKICAqIEZyZWVCU0QgcGFzc2VzIHRoZSBwb2ludGVyIHRvIHRoZSBpbi1j b3JlIHN0cnVjdCB3aXRoIHJlbGV2YW50CkBAIC0xNTMsOCArMTM3LDggQEAK IAl1aW50MzJfdCBlMmZzX2JzaGlmdDsgICAgIC8qIGNhbGMgb2YgbG9naWNh bCBibG9jayBubyAqLwogCWludDMyX3QgZTJmc19ibWFzazsgICAgICAgLyog Y2FsYyBvZiBibG9jayBvZmZzZXQgKi8KIAlpbnQzMl90IGUyZnNfYnBnOyAg ICAgICAgIC8qIE51bWJlciBvZiBibG9ja3MgcGVyIGdyb3VwICovCi0JaW50 NjRfdCBlMmZzX3FibWFzazsgICAgICAgLyogPSBzX2Jsb2Nrc2l6ZSAtMSAq LwotCXVpbnQzMl90IGUyZnNfZnNidG9kYjsgICAgIC8qIFNoaWZ0IHRvIGdl dCBkaXNrIGJsb2NrICovCisJaW50NjRfdCBlMmZzX3FibWFzazsgICAgICAv KiA9IHNfYmxvY2tzaXplIC0xICovCisJdWludDMyX3QgZTJmc19mc2J0b2Ri OyAgICAvKiBTaGlmdCB0byBnZXQgZGlzayBibG9jayAqLwogCXVpbnQzMl90 IGUyZnNfaXBnOyAgICAgICAgLyogTnVtYmVyIG9mIGlub2RlcyBwZXIgZ3Jv dXAgKi8KIAl1aW50MzJfdCBlMmZzX2lwYjsgICAgICAgIC8qIE51bWJlciBv ZiBpbm9kZXMgcGVyIGJsb2NrICovCiAJdWludDMyX3QgZTJmc19pdHBnOyAg ICAgICAvKiBOdW1iZXIgb2YgaW5vZGUgdGFibGUgcGVyIGdyb3VwICovCkBA IC0xNjksOCArMTUzLDggQEAKIAlpbnQzMl90ICBlMmZzX2lzaXplOyAgICAg IC8qIFNpemUgb2YgaW5vZGUgKi8KIAl1aW50MzJfdCBlMmZzX21vdW50X29w dDsKIAl1aW50MzJfdCBlMmZzX2Jsb2Nrc2l6ZV9iaXRzOworCXVpbnQ4X3QJ KmUyZnNfY29udGlnZGlyczsgLyogKHUpICMgb2YgY29udGlnLiBhbGxvY2F0 ZWQgZGlycyAqLwogCXVpbnQzMl90IGUyZnNfdG90YWxfZGlyOyAgLyogVG90 YWwgbnVtYmVyIG9mIGRpcmVjdG9yaWVzICovCi0JdWludDhfdAkqZTJmc19j b250aWdkaXJzOwogCWNoYXIgZTJmc193YXN2YWxpZDsgICAgICAgLyogdmFs aWQgYXQgbW91bnQgdGltZSAqLwogCW9mZl90IGUyZnNfbWF4ZmlsZXNpemU7 CiAJc3RydWN0IGV4dDJfZ2QgKmUyZnNfZ2Q7IC8qIEdyb3VwIERlc2NyaXB0 b3JzICovCkBAIC0xODIsNiArMTY2LDE0IEBACiAjZGVmaW5lIEUyRlNfREFU RQkJIjk1LzA4LzA5IgogI2RlZmluZSBFMkZTX1ZFUlNJT04JCSIwLjViIgog CisvKiBGaXJzdCBub24tcmVzZXJ2ZWQgaW5vZGUgZm9yIG9sZCBleHQyIGZp bGVzeXN0ZW1zICovCisjZGVmaW5lIEUyRlNfUkVWMF9GSVJTVF9JTk8JMTEK KworLyoKKyAqIFRoZSBzZWNvbmQgZXh0ZW5kZWQgZmlsZSBzeXN0ZW0gbWFn aWMgbnVtYmVyCisgKi8KKyNkZWZpbmUgRTJGU19NQUdJQwkJMHhFRjUzCisK IC8qCiAgKiBSZXZpc2lvbiBsZXZlbHMKICAqLwpAQCAtMTk3LDYgKzE4OSw3 IEBACiAgKiBjb21wYXRpYmxlL2luY29tcGF0aWJsZSBmZWF0dXJlcwogICov CiAjZGVmaW5lIEVYVDJGX0NPTVBBVF9QUkVBTExPQwkJMHgwMDAxCisjZGVm aW5lIEVYVDJGX0NPTVBBVF9IQVNKT1VSTkFMCQkweDAwMDQKICNkZWZpbmUg RVhUMkZfQ09NUEFUX1JFU0laRQkJMHgwMDEwCiAKICNkZWZpbmUgRVhUMkZf Uk9DT01QQVRfU1BBUlNFU1VQRVIJMHgwMDAxCkBAIC0zMjYsNCArMzE5LDQg QEAKIAogI2VuZGlmCiAKLSNlbmRpZgkvKiBfTElOVVhfRVhUMl9GU19IICov CisjZW5kaWYJLyogIV9GU19FWFQyRlNfRVhUMkZTX0ggKi8KT25seSBpbiBl eHQyZnM6IGV4dDJmcy5ofgpkaWZmIC1ydSBleHQyZnMub3JpZy9pbm9kZS5o IGV4dDJmcy9pbm9kZS5oCi0tLSBleHQyZnMub3JpZy9pbm9kZS5oCTIwMTEt MDEtMTggMTU6NDA6MzIuMDAwMDAwMDAwICswMDAwCisrKyBleHQyZnMvaW5v ZGUuaAkyMDExLTAxLTE4IDE1OjQyOjQ1LjAwMDAwMDAwMCArMDAwMApAQCAt NjIsNyArNjIsNiBAQAogICovCiBzdHJ1Y3QgaW5vZGUgewogCXN0cnVjdAl2 bm9kZSAgKmlfdm5vZGU7LyogVm5vZGUgYXNzb2NpYXRlZCB3aXRoIHRoaXMg aW5vZGUuICovCi0Jc3RydWN0CXZub2RlICAqaV9kZXZ2cDsvKiBWbm9kZSBm b3IgYmxvY2sgSS9PLiAqLwogCXN0cnVjdAlleHQybW91bnQgKmlfdW1wOwog CXVfaW50MzJfdCBpX2ZsYWc7CS8qIGZsYWdzLCBzZWUgYmVsb3cgKi8KIAlp bm9fdAkgIGlfbnVtYmVyOwkvKiBUaGUgaWRlbnRpdHkgb2YgdGhlIGlub2Rl LiAqLwpAQCAtMTQzLDYgKzE0Miw5IEBACiAjZGVmaW5lCUlOX1NQQUNFQ09V TlRFRAkweDAwODAJCS8qIEJsb2NrcyB0byBiZSBmcmVlZCBpbiBmcmVlIGNv dW50LiAqLwogI2RlZmluZSBJTl9MQVpZQUNDRVNTICAgMHgwMTAwCQkvKiBQ cm9jZXNzIElOX0FDQ0VTUyBhZnRlciB0aGUKIAkJCQkJICAgIHN1c3BlbnNp b24gZmluaXNoZWQgKi8KKworI2RlZmluZSBpX2RldnZwIGlfdW1wLT51bV9k ZXZ2cAorCiAjaWZkZWYgX0tFUk5FTAogLyoKICAqIFN0cnVjdHVyZSB1c2Vk IHRvIHBhc3MgYXJvdW5kIGxvZ2ljYWwgYmxvY2sgcGF0aHMgZ2VuZXJhdGVk IGJ5Cg== --0-1498478816-1295385891=:52958-- From owner-freebsd-fs@FreeBSD.ORG Wed Jan 19 08:37:39 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94779106566B; Wed, 19 Jan 2011 08:37:39 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id E64828FC20; Wed, 19 Jan 2011 08:37:38 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 84BC7713AEB; Wed, 19 Jan 2011 09:37:36 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.001727, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 8.9332] X-CRM114-CacheID: sfid-20110119_09373_73DC5698 X-CRM114-Status: Good ( pR: 8.9332 ) X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 2BE94713AE2; Wed, 19 Jan 2011 09:37:36 +0100 (CET) Message-ID: <4D36A2CF.1080508@fsn.hu> Date: Wed, 19 Jan 2011 09:37:35 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: freebsd-stable , freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: tmpfs is zero bytes (no free space), maybe a zfs bug? 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, 19 Jan 2011 08:37:39 -0000 Hi, I first noticed this problem on machines with more memory (32GB eg.), but now it happens on 4G machines too: tmpfs 0B 0B 0B 100% /tmp FreeBSD builder 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Sat Jan 8 22:11:54 CET 2011 Maybe it's related, that I use zfs on these machines... Sometimes it grows and shrinks, but generally there is no space even for a small file, or a socket to create. From owner-freebsd-fs@FreeBSD.ORG Wed Jan 19 08:46:50 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE75C1065674 for ; Wed, 19 Jan 2011 08:46:50 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id 9C5478FC08 for ; Wed, 19 Jan 2011 08:46:50 +0000 (UTC) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA11.westchester.pa.mail.comcast.net with comcast id xLmD1f0020EZKEL5BLmq2J; Wed, 19 Jan 2011 08:46:50 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta01.westchester.pa.mail.comcast.net with comcast id xLmp1f0092tehsa3MLmqSq; Wed, 19 Jan 2011 08:46:50 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 54C6F9B422; Wed, 19 Jan 2011 00:46:48 -0800 (PST) Date: Wed, 19 Jan 2011 00:46:48 -0800 From: Jeremy Chadwick To: Attila Nagy Message-ID: <20110119084648.GA28278@icarus.home.lan> References: <4D36A2CF.1080508@fsn.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D36A2CF.1080508@fsn.hu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-stable Subject: Re: tmpfs is zero bytes (no free space), maybe a zfs bug? 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, 19 Jan 2011 08:46:51 -0000 On Wed, Jan 19, 2011 at 09:37:35AM +0100, Attila Nagy wrote: > I first noticed this problem on machines with more memory (32GB > eg.), but now it happens on 4G machines too: > tmpfs 0B 0B 0B > 100% /tmp > FreeBSD builder 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Sat Jan 8 > 22:11:54 CET 2011 > > Maybe it's related, that I use zfs on these machines... > > Sometimes it grows and shrinks, but generally there is no space even > for a small file, or a socket to create. http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/060867.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Wed Jan 19 10:09:34 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58A16106564A; Wed, 19 Jan 2011 10:09:34 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id AC22A8FC2A; Wed, 19 Jan 2011 10:09:33 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 24ADC7131F2; Wed, 19 Jan 2011 11:09:32 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 13.7157] X-CRM114-CacheID: sfid-20110119_11093_E244C374 X-CRM114-Status: Good ( pR: 13.7157 ) X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id C1F9D7131E7; Wed, 19 Jan 2011 11:09:31 +0100 (CET) Message-ID: <4D36B85B.8070201@fsn.hu> Date: Wed, 19 Jan 2011 11:09:31 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D36A2CF.1080508@fsn.hu> <20110119084648.GA28278@icarus.home.lan> In-Reply-To: <20110119084648.GA28278@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable Subject: Re: tmpfs is zero bytes (no free space), maybe a zfs bug? 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, 19 Jan 2011 10:09:34 -0000 On 01/19/11 09:46, Jeremy Chadwick wrote: > On Wed, Jan 19, 2011 at 09:37:35AM +0100, Attila Nagy wrote: >> I first noticed this problem on machines with more memory (32GB >> eg.), but now it happens on 4G machines too: >> tmpfs 0B 0B 0B >> 100% /tmp >> FreeBSD builder 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Sat Jan 8 >> 22:11:54 CET 2011 >> >> Maybe it's related, that I use zfs on these machines... >> >> Sometimes it grows and shrinks, but generally there is no space even >> for a small file, or a socket to create. > http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/060867.html > Oh crap. :( I hope somebody can find the time to look into this, it's pretty annoying... From owner-freebsd-fs@FreeBSD.ORG Wed Jan 19 15:02:05 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A85ED1065674; Wed, 19 Jan 2011 15:02:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 232438FC14; Wed, 19 Jan 2011 15:02:04 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p0JF206q096768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jan 2011 17:02:00 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p0JF20wt018365; Wed, 19 Jan 2011 17:02:00 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p0JF20U8018364; Wed, 19 Jan 2011 17:02:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 19 Jan 2011 17:02:00 +0200 From: Kostik Belousov To: Ivan Voras Message-ID: <20110119150200.GY2518@deviant.kiev.zoral.com.ua> References: <4D36A2CF.1080508@fsn.hu> <20110119084648.GA28278@icarus.home.lan> <4D36B85B.8070201@fsn.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SoGQxgZEULAMOcJz" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: tmpfs is zero bytes (no free space), maybe a zfs bug? 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, 19 Jan 2011 15:02:05 -0000 --SoGQxgZEULAMOcJz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 19, 2011 at 11:39:41AM +0100, Ivan Voras wrote: > On 19/01/2011 11:09, Attila Nagy wrote: > >On 01/19/11 09:46, Jeremy Chadwick wrote: > >>On Wed, Jan 19, 2011 at 09:37:35AM +0100, Attila Nagy wrote: > >>>I first noticed this problem on machines with more memory (32GB > >>>eg.), but now it happens on 4G machines too: > >>>tmpfs 0B 0B 0B > >>>100% /tmp > >>>FreeBSD builder 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Sat Jan 8 > >>>22:11:54 CET 2011 > >>> > >>>Maybe it's related, that I use zfs on these machines... > >>> > >>>Sometimes it grows and shrinks, but generally there is no space even > >>>for a small file, or a socket to create. > >>http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/060867.h= tml > >> > >> > >Oh crap. :( > > > >I hope somebody can find the time to look into this, it's pretty > >annoying... >=20 > http://people.freebsd.org/~ivoras/diffs/tmpfs.h.patch >=20 > I don't think this is a complete solution but it's a start. If you can,= =20 > try it and see if it helps. This is not a start, and actually a step in the wrong direction. Tmpfs is wrong now, but the patch would make the wrongness even bigger. Issue is that the current tmpfs calculation should not depend on the length of the inactive queue or the amount of free pages. This data only measures the pressure on the pagedaemon, and has absolutely no relation to the amount of data that can be put into anonymous objects before the system comes out of swap. vm_lowmem handler is invoked in two situations: - when KVA cannot satisfy the request for the space allocation; - when pagedaemon have to start the scan. None of the situations has any direct correlation with the fact that tmpfs needs to check, that is "Is there enough swap to keep all my future anonymous memory requests ?". Might be, swap reservation numbers can be useful to the tmpfs reporting. Also might be, tmpfs should reserve the swap explicitely on start, instead of making attempts to guess how much can be allocated at random moment. --SoGQxgZEULAMOcJz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk02/OgACgkQC3+MBN1Mb4gbqACcCcdPv4prz3YTuFFXcJdjgXtC xs4AoIpe5GpZ9t49sjimGrOvG382V2of =EWf5 -----END PGP SIGNATURE----- --SoGQxgZEULAMOcJz-- From owner-freebsd-fs@FreeBSD.ORG Wed Jan 19 15:20:10 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90E1C1065670 for ; Wed, 19 Jan 2011 15:20:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 807FF8FC08 for ; Wed, 19 Jan 2011 15:20:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0JFKAxv077835 for ; Wed, 19 Jan 2011 15:20:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0JFKAZp077834; Wed, 19 Jan 2011 15:20:10 GMT (envelope-from gnats) Date: Wed, 19 Jan 2011 15:20:10 GMT Message-Id: <201101191520.p0JFKAZp077834@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Simmons Cc: Subject: Re: kern/153996: [zfs] zfs root mount error while kernel is not located in /boot/kernel X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Simmons List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 15:20:10 -0000 The following reply was made to PR kern/153996; it has been noted by GNATS. From: Martin Simmons To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/153996: [zfs] zfs root mount error while kernel is not located in /boot/kernel Date: Wed, 19 Jan 2011 15:16:03 GMT The same happens in 8.0 (with LOADER_ZFS_SUPPORT=YES). I suspect the problem is that unload removes the zpool.cache from memory, so zfs can't find the pool any more. You can see that by doing lsmod before unload. Either reload it like this before boot: load -t /boot/zfs/zpool.cache /boot/zfs/zpool.cache or reload everything with boot's kernel & module loader: unload set module_path=/boot/GCAM boot /boot/GCAM/kernel The second way assumes your loader.conf contains zfs_load="YES", which it probably does in this case. From owner-freebsd-fs@FreeBSD.ORG Wed Jan 19 16:28:29 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA66A106564A for ; Wed, 19 Jan 2011 16:28:29 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 77A1C8FC1A for ; Wed, 19 Jan 2011 16:28:29 +0000 (UTC) Received: by qwj9 with SMTP id 9so1050665qwj.13 for ; Wed, 19 Jan 2011 08:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Wauvl66oUnUCkGH3YnladgRZHUFuOr13Tfkg3Ekshig=; b=SMwJ/NqpEUUPnu9/JoYNMfKlEZRxjvqHzlX+Hdq93h0PQUaoiECofg3cm6+QPs3+DW x53S3IavbP+rINArCfvL2ngwci3GEnhYeZVwnRYOT+IaRGRXt5wnf68M+epa5qwISwT/ x2qcfV/JIfont8q96bnmJPuWcZ8EZ/TZPx5ZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=qPw3DkSXqAcQBWCth4Bunzoy81KaqZSJ3ftw3AcRfj4SnKDuphQoagC8adTL5g0rkW V1I6lkuNgav5Nh097sKrFhG3dP+tp/O3PjB2HXxv9yo0fBAysP4+t33HH+oHgpa1hXZT 9XtAp8RiEHh53XYed7PvjmeWZWZKVQei7SMdU= Received: by 10.229.43.195 with SMTP id x3mr742241qce.291.1295454507645; Wed, 19 Jan 2011 08:28:27 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.44.70 with HTTP; Wed, 19 Jan 2011 08:27:38 -0800 (PST) In-Reply-To: <20110119150200.GY2518@deviant.kiev.zoral.com.ua> References: <4D36A2CF.1080508@fsn.hu> <20110119084648.GA28278@icarus.home.lan> <4D36B85B.8070201@fsn.hu> <20110119150200.GY2518@deviant.kiev.zoral.com.ua> From: Ivan Voras Date: Wed, 19 Jan 2011 17:27:38 +0100 X-Google-Sender-Auth: 8boe6dnzih0kqc3YGI2n35yPzzQ Message-ID: To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: tmpfs is zero bytes (no free space), maybe a zfs bug? 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, 19 Jan 2011 16:28:29 -0000 On 19 January 2011 16:02, Kostik Belousov wrote: >> http://people.freebsd.org/~ivoras/diffs/tmpfs.h.patch >> >> I don't think this is a complete solution but it's a start. If you can, >> try it and see if it helps. > This is not a start, and actually a step in the wrong direction. > Tmpfs is wrong now, but the patch would make the wrongness even bigger. > > Issue is that the current tmpfs calculation should not depend on the > length of the inactive queue or the amount of free pages. This data only > measures =C2=A0the pressure on the pagedaemon, and has absolutely no rela= tion > to the amount of data that can be put into anonymous objects before the > system comes out of swap. > > vm_lowmem handler is invoked in two situations: > - when KVA cannot satisfy the request for the space allocation; > - when pagedaemon have to start the scan. > None of the situations has any direct correlation with the fact that > tmpfs needs to check, that is "Is there enough swap to keep all my > future anonymous memory requests ?". > > Might be, swap reservation numbers can be useful to the tmpfs reporting. > Also might be, tmpfs should reserve the swap explicitely on start, instea= d > of making attempts to guess how much can be allocated at random moment. Thank you for your explanation! I'm still not very familiar with VM and VFS. Could you also read my report at http://www.mail-archive.com/freebsd-current@freebsd.org/msg126491.html ? I'm curious about the fact that there is lots of 'free' memory here in the same situation. Do you think that there is something which can be done as a band-aid without a major modification to tmpfs? From owner-freebsd-fs@FreeBSD.ORG Wed Jan 19 18:00:22 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCCB51065695 for ; Wed, 19 Jan 2011 18:00:22 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A1A698FC12 for ; Wed, 19 Jan 2011 18:00:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0JI0M8W045896 for ; Wed, 19 Jan 2011 18:00:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0JI0M4L045894; Wed, 19 Jan 2011 18:00:22 GMT (envelope-from gnats) Date: Wed, 19 Jan 2011 18:00:22 GMT Message-Id: <201101191800.p0JI0M4L045894@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Garrett Cooper Cc: Subject: Re: kern/153996: [zfs] zfs root mount error while kernel is not located in /boot/kernel X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Garrett Cooper List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 18:00:22 -0000 The following reply was made to PR kern/153996; it has been noted by GNATS. From: Garrett Cooper To: Alexander Naumochkin Cc: bug-followup Subject: Re: kern/153996: [zfs] zfs root mount error while kernel is not located in /boot/kernel Date: Wed, 19 Jan 2011 09:54:45 -0800 On Wed, Jan 19, 2011 at 9:17 AM, Alexander Naumochkin wrote: > Wow! It starts! I've just typed boot GENERIC, and it starts and works! > Thank you very much Garrett! > > This will continue forever in next releases? I think it should be > documented in Handbook. How can I participate? If I can ever :) > > On Wed, Jan 19, 2011 at 12:20 PM, Garrett Cooper wr= ote: >> >> On Tue, Jan 18, 2011 at 8:37 AM, Alexander Naumochkin >> wrote: >> > Garrett, >> > now I have two kernels on my box: >> > 1. /boot/kernel/kernel =97 my working customized kernel >> > 2. /boot/GENERIC/kernel =97 GENERIC kernel >> > I tried the following expreriment: >> > # shutdown -r now >> > wait for loader menu and choose 6 - Escape to loader prompt >> > OK unload kernel >> > OK set kernelname=3D/boot/GENERIC/kernel >> > OK set module_path=3D/boot/GENERIC >> > OK load opensolaris >> > OK load zfs >> > OK boot >> > and got the same result: "MOUNT ROOT ERROR" while "Trying to mount roo= t from >> > zfs:zroot" >> > BTW, even if your method would work, it could not help in case of inst= all >> > misconfigured unbootable kernel. Let's say I install misconfigured ker= nel: >> > # make installkernel KERNCONF=3DBADKRNL >> > After this I get: >> > 1. bad kernel in /boot/kernel/kernel >> > 2. previous working kernel in /boot/kernel.old/kernel >> > 3. GENERIC kernel in /boot/GENERIC/kernel >> > I reboot and faced with unbootable system (because of BADKRNL as defau= lt). >> > In fact we have now completely unbootable system due the bug I've repo= rted >> > with this PR. Also this bug means that from now on we have no possibil= ity to >> > test custom kernels by installing it to alternate directory (with KODI= R >> > variable) =97 it will not boot anyway. >> >> Try set kernelname=3DGENERIC , etc. Or... just load the kernel modules >> and do: boot GENERIC, etc on the loader command line. It's been this way for ages with loader(8), so I doubt it's going to change too dramatically anytime soon :). That being said, the handbook [1] might need to be updated a bit with a working process (or unload needs to be properly fixed to unload everything if it's broken -- not sure). I'll have to see what happens when I issue those commands sometime on the command line. Regardless though -- if the process doesn't work as-is you should submit a doc update for the handbook so that a working process is available for end-users :). Cheers! -Garrett 1. http://www.freebsd.org/doc/handbook/boot-blocks.html From owner-freebsd-fs@FreeBSD.ORG Thu Jan 20 13:11:50 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A7DD106564A for ; Thu, 20 Jan 2011 13:11:50 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 903068FC13 for ; Thu, 20 Jan 2011 13:11:49 +0000 (UTC) Received: by fxm16 with SMTP id 16so586923fxm.13 for ; Thu, 20 Jan 2011 05:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=//kHEesk4WocBhk742DglXc7OZo3TtdhJpoGWQRNgNw=; b=g4ymA2fP0XFJwxrIJ/RZyJhnG7rmEmXpwiWU5o24z+1EbUsG521tGnP+Ypf7HMSkD5 a8I3wNJ0H2w/sxPLcVrpbIW3QzxdVvj9wKin6QRtGjBvzdvFRV8oXgGz12ueVFUW36dp y5L5DocWESRQMbhmQvIQDindtBqo0+j30foPc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=KaVLA3ZWwCbH8tHRqQB4MeQ3VrBDfScH2+vXPtzeIIYyqemwYiFFAOOrxVGX9rFiTo dumwEva0+QcM0xC5p7LmhunWQ332F21MxU+qYGcc6s87283pKYv/Kf0JAJmiowu19hDN +PNrH7/4Fchws25Rbk8+vADTMEGnvtYdXBLXc= Received: by 10.223.95.202 with SMTP id e10mr2050359fan.32.1295527295387; Thu, 20 Jan 2011 04:41:35 -0800 (PST) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id r24sm3096246fax.27.2011.01.20.04.41.33 (version=SSLv3 cipher=RC4-MD5); Thu, 20 Jan 2011 04:41:34 -0800 (PST) Date: Thu, 20 Jan 2011 14:41:08 +0200 From: Gleb Kurtsou To: Kostik Belousov Message-ID: <20110120124108.GA32866@tops.skynet.lt> References: <20101201091203.GA3933@tops> <20110104175558.GR3140@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110104175558.GR3140@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: [rfc] 64-bit inode numbers 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, 20 Jan 2011 13:11:50 -0000 I've updated the patch. New version is available here: https://github.com/downloads/glk/freebsd-ino64/freebsd-ino64-patch-2011-01-20.tgz Changelog: * Add fts, ftw, nftw compat shims in libc * Place libc compat shims in separate files, don't hack original implementations. * Fix dump/restore * Use ino_t in UFS code (suggested by Kirk McKusick) * Keep ufs_ino_t (32 bit) for boot2 not to increase size On (04/01/2011 19:55), Kostik Belousov wrote: > I think some more comments for each patch in the set, in addition to > the one-line title, would be useful. > > No need to add regen patches, they only confuse the reader. Just add a > note to other patches where the regen is needed. > > I have big doubts about 0009, since struct inoref is not on-disk struct. Thanks. > My impression is that the issue of extending ino_t to 64 bit is much bigger > then presented in your patch. E.g. FTSENT (include/fts.h) explicitely > include ino_t member. As result, there are more ABI changes that handled. > Or, did I missed this in the patchset ? I've missed this one, and also ftw/nftw. > Might be, libarchive and libufs are also affected. Not sure about struct > pidfh from libutil. There is no symbol versioning in these libraries, SHLIB_MAJOR should be dumped (for all libraries in the tree). Thanks, Gleb. From owner-freebsd-fs@FreeBSD.ORG Thu Jan 20 14:27:53 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B44DE106566C for ; Thu, 20 Jan 2011 14:27:53 +0000 (UTC) (envelope-from jackieit@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6AFA18FC0C for ; Thu, 20 Jan 2011 14:27:53 +0000 (UTC) Received: by vws9 with SMTP id 9so181242vws.13 for ; Thu, 20 Jan 2011 06:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=/5e2QnBoElyEScn+S1/48KV18KjmbY/hu9DP8ufFVlQ=; b=bBTlGHFRQRY1nVW6oc5QgVXwRdiHJQOtnqNXl40EYTH03qr4XuP2Vu2YYCqwIkKDwI K+cwG0/trCKD10a9bbB2j154dXUuUGPDO2yQQ+YMNX9/q5nFxlwkNiA8YalIZlMcD9tQ n/LV5i/7H2oIKpQhuzL4sqFtsa6vjr9DaXp44= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JMW347v7RDWr2qsRsZXlnpMDSwWI8Oyz1IsT6yQtpHA5Pmlh/lLn7EtUqYZ/cPDF/f /1JD/O+b8bUqIefX6fcR0mI5FcfA3f8PBaXiXpfla+hy/l7erGOEhuIi53Sd9oGhgdc9 8JPoBwn6WviPGbhw5tF1/wBcfCUMl/DA4N0Nw= MIME-Version: 1.0 Received: by 10.229.213.13 with SMTP id gu13mr1737163qcb.196.1295531853206; Thu, 20 Jan 2011 05:57:33 -0800 (PST) Received: by 10.220.177.1 with HTTP; Thu, 20 Jan 2011 05:57:33 -0800 (PST) Date: Thu, 20 Jan 2011 21:57:33 +0800 Message-ID: From: jackie wang To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Freebsd8.1 ZFS with mfi driver performance 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, 20 Jan 2011 14:27:53 -0000 hello ,I have a question.Sorry I have google a lot and have no answer. I run freebsd 8.1 with zfs file system and mfi driver . And my problem is when the system started , the speed is fast ,but after one or two days the system began to slow . My server main used as a web server ,the ram is 8G. my uname -a output FreeBSD xxx 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Dec 20 20:50:20 CST 2010 root@VS001.vlongbiz.com:/usr/obj/usr/src/sys/xxxCore amd64 zpool status -v VS001# zpool status -v pool: backup state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM backup ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk7 ONLINE 0 0 0 gpt/disk8 ONLINE 0 0 0 gpt/disk9 ONLINE 0 0 0 gpt/disk10 ONLINE 0 0 0 gpt/disk11 ONLINE 0 0 0 errors: No known data errors pool: wwwroot state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM wwwroot ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 gpt/disk3 ONLINE 0 0 0 gpt/disk4 ONLINE 0 0 0 gpt/disk5 ONLINE 0 0 0 gpt/disk6 ONLINE 0 0 0 errors: No known data errors pool: zroot state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 errors: No known data errors ------------------------------------------------------------- mfiutil show list output VS001# mfiutil show config mfi0 Configuration: 12 arrays, 12 volumes, 0 spares array 0 of 1 drives: drive 0 ( 932G) ONLINE SATA enclosure 1, slot 0 array 1 of 1 drives: drive 1 ( 932G) ONLINE SATA enclosure 1, slot 1 array 2 of 1 drives: drive 2 ( 932G) ONLINE SATA enclosure 1, slot 2 array 3 of 1 drives: drive 3 ( 932G) ONLINE SATA enclosure 1, slot 3 array 4 of 1 drives: drive 4 ( 932G) ONLINE SATA enclosure 1, slot 4 array 5 of 1 drives: drive 5 ( 932G) ONLINE SATA enclosure 1, slot 5 array 6 of 1 drives: drive 6 ( 932G) ONLINE SATA enclosure 1, slot 6 array 7 of 1 drives: drive 7 ( 932G) ONLINE SATA enclosure 1, slot 7 array 8 of 1 drives: drive 8 ( 932G) ONLINE SATA enclosure 1, slot 8 array 9 of 1 drives: drive 9 ( 932G) ONLINE SATA enclosure 1, slot 9 array 10 of 1 drives: drive 10 ( 932G) ONLINE SATA enclosure 1, slot 10 array 11 of 1 drives: drive 11 ( 932G) ONLINE SATA enclosure 1, slot 11 volume mfid0 (931G) RAID-0 64K OPTIMAL spans: array 0 volume mfid1 (931G) RAID-0 64K OPTIMAL spans: array 1 volume mfid2 (931G) RAID-0 64K OPTIMAL spans: array 2 volume mfid3 (931G) RAID-0 64K OPTIMAL spans: array 3 volume mfid4 (931G) RAID-0 64K OPTIMAL spans: array 4 volume mfid5 (931G) RAID-0 64K OPTIMAL spans: array 5 volume mfid6 (931G) RAID-0 64K OPTIMAL spans: array 6 volume mfid7 (931G) RAID-0 64K OPTIMAL spans: array 7 volume mfid8 (931G) RAID-0 64K OPTIMAL spans: array 8 volume mfid9 (931G) RAID-0 64K OPTIMAL spans: array 9 volume mfid10 (931G) RAID-0 64K OPTIMAL spans: array 10 volume mfid11 (931G) RAID-0 64K OPTIMAL spans: array 11 VS001# gstat -f mfid.p1 dT: 1.002s w: 1.000s filter: mfid.p1 L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 0 0 0 0.0 0 0 0.0 0.0| mfid0p1 0 0 0 0 0.0 0 0 0.0 0.0| mfid1p1 0 63 63 2946 26.7 0 0 0.0 90.6| mfid2p1 0 62 62 2824 22.8 0 0 0.0 78.0| mfid3p1 0 64 64 2949 22.3 0 0 0.0 84.9| mfid4p1 0 66 66 3012 19.4 0 0 0.0 77.4| mfid5p1 2 68 68 3266 16.3 0 0 0.0 68.9| mfid6p1 0 0 0 0 0.0 0 0 0.0 0.0| mfid7p1 0 0 0 0 0.0 0 0 0.0 0.0| mfid8p1 0 0 0 0 0.0 0 0 0.0 0.0| mfid9p1 more /boot/loader.conf VS001# more /boot/loader.conf zfs_load="YES" vfs.root.mountfrom="zfs:zroot" geom_mirror_load="YES" #vm.kmem_size="4096M" #vm.kmem_size_max="3072M" vfs.zfs.arc_min="1024M" vfs.zfs.arc_max="4096M" #vfs.zfs.vdev.cache.size="5M" vfs.zfs.vdev.min_pending="1" vfs.zfs.vdev.max_pending="1" vfs.zfs.prefetch_disable="1" vfs.zfs.txg.timeout="5" vfs.zfs.txg.synctime="1" vfs.zfs.txg.write_limit_override="524288000" when the system slow there much mermory in wired status about 5GB, and the system begin to use swap. So,my question is why the zfs slow . Please Help ,now the box is in production env. From owner-freebsd-fs@FreeBSD.ORG Thu Jan 20 17:09:20 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C2C4106566C for ; Thu, 20 Jan 2011 17:09:20 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop1b.sarenet.es (proxypop1b.sarenet.es [194.30.0.104]) by mx1.freebsd.org (Postfix) with ESMTP id 393C98FC16 for ; Thu, 20 Jan 2011 17:09:19 +0000 (UTC) Received: from [172.16.1.55] (ssglan.sare.net [192.148.167.100]) by proxypop1b.sarenet.es (Postfix) with ESMTP id 77E475C4E; Thu, 20 Jan 2011 18:09:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: Date: Thu, 20 Jan 2011 18:09:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <08E2A27C-4564-43F0-898B-00C5C6A7B446@sarenet.es> References: To: jackie wang X-Mailer: Apple Mail (2.1082) Cc: freebsd-fs@freebsd.org Subject: Re: Freebsd8.1 ZFS with mfi driver performance 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, 20 Jan 2011 17:09:20 -0000 On Jan 20, 2011, at 2:57 PM, jackie wang wrote: > hello ,I have a question.Sorry I have google a lot and have no answer. > I run freebsd 8.1 with zfs file system and mfi driver . > And my problem is when the system started , the speed is fast ,but > after one or two days the system began to slow . > My server main used as a web server ,the ram is 8G. > my uname -a output > FreeBSD xxx 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Dec 20 20:50:20 > CST 2010 root@VS001.vlongbiz.com:/usr/obj/usr/src/sys/xxxCore > amd64 >=20 >=20 > when the system slow there much mermory in wired status about 5GB, and > the system begin to use swap. >=20 > So,my question is why the zfs slow . Please Help ,now the box is in > production env. Maybe you will want to check on the sister freebsd-scsi list. Some = users (me included) have seen some ugly issues at least with what Dell = calls PERC H700 and H800 cards. Check your console for something like this: hi, we keep seeing these timeouts when there is heavy writes to the mfi: ... mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6564 SECONDS mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6594 SECONDS mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6624 SECONDS mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6654 SECONDS mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6684 SECONDS mfi1: COMMAND 0xffffff80009ce498 TIMEOUT AFTER 35 SECONDS mfi1: COMMAND 0xffffff80009ce9e8 TIMEOUT AFTER 37 SECONDS mfi1: COMMAND 0xffffff80009cec08 TIMEOUT AFTER 38 SECONDS mfi1: COMMAND 0xffffff80009cc3a8 TIMEOUT AFTER 47 SECONDS mfi1: COMMAND 0xffffff80009ceda0 TIMEOUT AFTER 31 SECONDS mfi1: COMMAND 0xffffff80009ce9e8 TIMEOUT AFTER 46 SECONDS mfi1: COMMAND 0xffffff80009cda80 TIMEOUT AFTER 55 SECONDS ... mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6624 SECONDS Borja From owner-freebsd-fs@FreeBSD.ORG Fri Jan 21 06:38:43 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 561ED106564A for ; Fri, 21 Jan 2011 06:38:43 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2002:d596:2a92:2:155::]) by mx1.freebsd.org (Postfix) with ESMTP id 114A68FC12 for ; Fri, 21 Jan 2011 06:38:43 +0000 (UTC) Received: from [10.32.67.98] (fw.int.webpartner.dk [213.150.34.98]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id DA9E6638DAB; Fri, 21 Jan 2011 07:38:26 +0100 (CET) X-DKIM: OpenDKIM Filter v2.2.2 mail.tyknet.dk DA9E6638DAB DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1295591922; bh=e8gCi0uKr+ODQnTPv2ZAWu1klP20ZjVWd1lrnZuXEv4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=CPNbKB4VS0JXJu6WwWYMQxU4VAyzFIF2AhJDp7Jl39uya3CPMZGwp/17bFI6kQk4S Ruk7yAMF83XadB7d297M9sNm3UH5cGzK0yWtTAhbnzOMAk+V18Ubt6SElGl5gIfhUS 0gsa+gsh4BvUg8OlTcTF1J4u9N3jsroTlZ5O/mVM= Message-ID: <4D3929E1.7070701@gibfest.dk> Date: Fri, 21 Jan 2011 07:38:25 +0100 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Freebsd8.1 ZFS with mfi driver performance 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, 21 Jan 2011 06:38:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20-01-2011 14:57, jackie wang wrote: > hello ,I have a question.Sorry I have google a lot and have no answer. > I run freebsd 8.1 with zfs file system and mfi driver . > And my problem is when the system started , the speed is fast ,but > after one or two days the system began to slow . > My server main used as a web server ,the ram is 8G. Hello, Try checking if your problems fall inbetween "patrol read enabled" and "patrol read disabled" (should be logged in messages). I've recently disabled "patrol reads" (mfiutil patrol disable) on an MFI controller, as it was causing instability on a VirtualBox host, when the patrol read happened at the same time as heavy IO. Good luck with it! Best regards, Thomas Steen Rasmussen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk05KeEACgkQGjEBQafC9MDl4QCeKWx5TDRdS4r5G1FYf1LWf5EH CNUAoIVxQGGQaMlO/Tb59nS5gcz4LurF =jCxS -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Fri Jan 21 08:08:29 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39465106564A for ; Fri, 21 Jan 2011 08:08:29 +0000 (UTC) (envelope-from jackieit@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id E346A8FC16 for ; Fri, 21 Jan 2011 08:08:28 +0000 (UTC) Received: by qyk8 with SMTP id 8so217782qyk.13 for ; Fri, 21 Jan 2011 00:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=zNvqZLovpCJ8cAdOTSshhzBMWj1qtKFdex/ntA/oFjo=; b=BJkQEzM1bitLUr45O2oA0apGnbaIiQRo9XxNwJXeR1ReJ1oPkbjPrjKLr2px20aRDN E9CMOMPkEVCimluH8prMWR7FPeWuiN3+Ket4ESaXTa8/uiP9l1XqLMj5I9zZV46Qrd2Z qI3cFX1exAWj0EC8pq9Xp6e+7SxEhYSpq4hcw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Ljr5jcTSVTShu8CrmWIuUrcflvzUMc6VBlyN1VSY9U2rMuyqt5fTKXJZZkS9JNpP4O Mr10TRMddCvB77Hk6iZG5s8Oe+7u7/1/e0t2chwXqbKSV72Pi/Kk62q4jVlm7UdPD09m gQpW54CdcJ9y93OWNcspHv4OOdk8eC29FosMQ= MIME-Version: 1.0 Received: by 10.229.188.144 with SMTP id da16mr323153qcb.158.1295597308140; Fri, 21 Jan 2011 00:08:28 -0800 (PST) Received: by 10.220.177.1 with HTTP; Fri, 21 Jan 2011 00:08:28 -0800 (PST) In-Reply-To: References: <08E2A27C-4564-43F0-898B-00C5C6A7B446@sarenet.es> Date: Fri, 21 Jan 2011 16:08:28 +0800 Message-ID: From: jackie wang To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Freebsd8.1 ZFS with mfi driver performance 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, 21 Jan 2011 08:08:29 -0000 2011/1/21 Borja Marcos : > > On Jan 20, 2011, at 2:57 PM, jackie wang wrote: > >> hello ,I have a question.Sorry I have google a lot and have no answer. >> I run freebsd 8.1 with zfs file system and mfi driver . >> And my problem is when the system started , the speed is fast ,but >> after one or two days the system began to slow . >> My server main used as a web server ,the ram is 8G. >> my uname -a output >> FreeBSD xxx 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Dec 20 20:50:20 >> CST 2010 =A0 =A0 root@VS001.vlongbiz.com:/usr/obj/usr/src/sys/xxxCore >> amd64 >> >> >> when the system slow there much mermory in wired status about 5GB, and >> the system begin to use swap. >> >> So,my question is why the zfs slow . Please Help ,now the box is in >> production env. > > Maybe you will want to check on the sister freebsd-scsi list. =A0Some use= rs (me included) have seen some ugly issues at least with what Dell calls P= ERC H700 and H800 cards. > > Check your console for something like this: > > hi, > we keep seeing these timeouts when there is heavy writes to the mfi: > ... > mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6564 SECONDS > mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6594 SECONDS > mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6624 SECONDS > mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6654 SECONDS > mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6684 SECONDS > mfi1: COMMAND 0xffffff80009ce498 TIMEOUT AFTER 35 SECONDS > mfi1: COMMAND 0xffffff80009ce9e8 TIMEOUT AFTER 37 SECONDS > mfi1: COMMAND 0xffffff80009cec08 TIMEOUT AFTER 38 SECONDS > mfi1: COMMAND 0xffffff80009cc3a8 TIMEOUT AFTER 47 SECONDS > mfi1: COMMAND 0xffffff80009ceda0 TIMEOUT AFTER 31 SECONDS > mfi1: COMMAND 0xffffff80009ce9e8 TIMEOUT AFTER 46 SECONDS > mfi1: COMMAND 0xffffff80009cda80 TIMEOUT AFTER 55 SECONDS > ... > mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6624 SECONDS > > > > > Borja > > Fortunately,I have no this problem . My Firmware version is 2.30.03-0872. and find no error log in message files . From owner-freebsd-fs@FreeBSD.ORG Fri Jan 21 15:04:36 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81D2E1065674 for ; Fri, 21 Jan 2011 15:04:36 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 266878FC14 for ; Fri, 21 Jan 2011 15:04:34 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 6C06245E5C; Fri, 21 Jan 2011 16:04:31 +0100 (CET) Received: from localhost (pdawidek.whl [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 1F4E345685; Fri, 21 Jan 2011 16:04:24 +0100 (CET) Date: Fri, 21 Jan 2011 16:04:13 +0100 From: Pawel Jakub Dawidek To: jackie wang Message-ID: <20110121150413.GE1698@garage.freebsd.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FoLtEtfbNGMjfgrs" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: Freebsd8.1 ZFS with mfi driver performance 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, 21 Jan 2011 15:04:36 -0000 --FoLtEtfbNGMjfgrs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 20, 2011 at 09:57:33PM +0800, jackie wang wrote: > more /boot/loader.conf >=20 > VS001# more /boot/loader.conf > zfs_load=3D"YES" > vfs.root.mountfrom=3D"zfs:zroot" > geom_mirror_load=3D"YES" > #vm.kmem_size=3D"4096M" > #vm.kmem_size_max=3D"3072M" Why you commented those out? Try adding: vm.kmem_size=3D"4096M" > vfs.zfs.arc_min=3D"1024M" > vfs.zfs.arc_max=3D"4096M" > #vfs.zfs.vdev.cache.size=3D"5M" > vfs.zfs.vdev.min_pending=3D"1" > vfs.zfs.vdev.max_pending=3D"1" > vfs.zfs.prefetch_disable=3D"1" > vfs.zfs.txg.timeout=3D"5" > vfs.zfs.txg.synctime=3D"1" > vfs.zfs.txg.write_limit_override=3D"524288000" >=20 > when the system slow there much mermory in wired status about 5GB, and > the system begin to use swap. >=20 > So,my question is why the zfs slow . Please Help ,now the box is in > production env. Could you explain all your settings there? I'd start from removing all of them and just leaving kmem_size. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --FoLtEtfbNGMjfgrs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk05oG0ACgkQForvXbEpPzTsGACgvc2tWQAGcxhRD1AOKukgmTlI Xv0AnRknd9E1Y66rRix5CE/DgKG7JI4G =UwBK -----END PGP SIGNATURE----- --FoLtEtfbNGMjfgrs-- From owner-freebsd-fs@FreeBSD.ORG Fri Jan 21 21:40:11 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0748F106566B for ; Fri, 21 Jan 2011 21:40:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EB0CE8FC16 for ; Fri, 21 Jan 2011 21:40:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0LLeA9w008496 for ; Fri, 21 Jan 2011 21:40:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0LLeAlJ008494; Fri, 21 Jan 2011 21:40:10 GMT (envelope-from gnats) Date: Fri, 21 Jan 2011 21:40:10 GMT Message-Id: <201101212140.p0LLeAlJ008494@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/153584: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 21:40:11 -0000 The following reply was made to PR kern/153584; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/153584: commit references a PR Date: Fri, 21 Jan 2011 21:33:52 +0000 (UTC) Author: jhb Date: Fri Jan 21 21:33:46 2011 New Revision: 217702 URL: http://svn.freebsd.org/changeset/base/217702 Log: Restore support for the 'async' and 'sync' mount options lost when switching to nmount(2). While here, sort the options. PR: kern/153584 Submitted by: Pedro F. Giffuni giffunip at yahoo MFC after: 1 week Modified: head/sys/fs/ext2fs/ext2_vfsops.c Modified: head/sys/fs/ext2fs/ext2_vfsops.c ============================================================================== --- head/sys/fs/ext2fs/ext2_vfsops.c Fri Jan 21 18:32:29 2011 (r217701) +++ head/sys/fs/ext2fs/ext2_vfsops.c Fri Jan 21 21:33:46 2011 (r217702) @@ -95,9 +95,9 @@ static int ext2_check_sb_compat(struct e static int compute_sb_data(struct vnode * devvp, struct ext2fs * es, struct m_ext2fs * fs); -static const char *ext2_opts[] = { "from", "export", "acls", "noexec", - "noatime", "union", "suiddir", "multilabel", "nosymfollow", - "noclusterr", "noclusterw", "force", NULL }; +static const char *ext2_opts[] = { "acls", "async", "noatime", "noclusterr", + "noclusterw", "noexec", "export", "force", "from", "multilabel", + "suiddir", "nosymfollow", "sync", "union", NULL }; /* * VFS Operations. _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Fri Jan 21 22:10:10 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC94F106564A for ; Fri, 21 Jan 2011 22:10:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DBEFB8FC16 for ; Fri, 21 Jan 2011 22:10:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0LMA98W040537 for ; Fri, 21 Jan 2011 22:10:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0LMA96d040536; Fri, 21 Jan 2011 22:10:09 GMT (envelope-from gnats) Date: Fri, 21 Jan 2011 22:10:09 GMT Message-Id: <201101212210.p0LMA96d040536@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/153584: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 22:10:10 -0000 The following reply was made to PR kern/153584; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/153584: commit references a PR Date: Fri, 21 Jan 2011 22:00:47 +0000 (UTC) Author: jhb Date: Fri Jan 21 22:00:40 2011 New Revision: 217703 URL: http://svn.freebsd.org/changeset/base/217703 Log: - Move special inode constants to ext2_dinode.h and rename them to match NetBSD. - Add a constant for the HASJOURNAL compat flag. PR: kern/153584 Submitted by: Pedro F. Giffuni giffunip at yahoo Modified: head/sys/fs/ext2fs/ext2_dinode.h head/sys/fs/ext2fs/ext2fs.h Modified: head/sys/fs/ext2fs/ext2_dinode.h ============================================================================== --- head/sys/fs/ext2fs/ext2_dinode.h Fri Jan 21 21:33:46 2011 (r217702) +++ head/sys/fs/ext2fs/ext2_dinode.h Fri Jan 21 22:00:40 2011 (r217703) @@ -32,6 +32,23 @@ #define e2di_size_high e2di_dacl /* + * Special inode numbers + * The root inode is the root of the file system. Inode 0 can't be used for + * normal purposes and bad blocks are normally linked to inode 1, thus + * the root inode is 2. + * Inode 3 to 10 are reserved in ext2fs. + */ +#define EXT2_BADBLKINO ((ino_t)1) +#define EXT2_ROOTINO ((ino_t)2) +#define EXT2_ACLIDXINO ((ino_t)3) +#define EXT2_ACLDATAINO ((ino_t)4) +#define EXT2_BOOTLOADERINO ((ino_t)5) +#define EXT2_UNDELDIRINO ((ino_t)6) +#define EXT2_RESIZEINO ((ino_t)7) +#define EXT2_JOURNALINO ((ino_t)8) +#define EXT2_FIRSTINO ((ino_t)11) + +/* * Inode flags * The current implementation uses only EXT2_IMMUTABLE and EXT2_APPEND flags */ Modified: head/sys/fs/ext2fs/ext2fs.h ============================================================================== --- head/sys/fs/ext2fs/ext2fs.h Fri Jan 21 21:33:46 2011 (r217702) +++ head/sys/fs/ext2fs/ext2fs.h Fri Jan 21 22:00:40 2011 (r217703) @@ -39,22 +39,6 @@ #include -/* - * Special inode numbers - */ -#define EXT2_BAD_INO 1 /* Bad blocks inode */ -#define EXT2_ROOT_INO 2 /* Root inode */ -#define EXT2_BOOT_LOADER_INO 5 /* Boot loader inode */ -#define EXT2_UNDEL_DIR_INO 6 /* Undelete directory inode */ - -/* First non-reserved inode for old ext2 filesystems */ -#define E2FS_REV0_FIRST_INO 11 - -/* - * The second extended file system magic number - */ -#define E2FS_MAGIC 0xEF53 - #if defined(_KERNEL) /* * FreeBSD passes the pointer to the in-core struct with relevant @@ -170,7 +154,7 @@ struct m_ext2fs { uint32_t e2fs_mount_opt; uint32_t e2fs_blocksize_bits; uint32_t e2fs_total_dir; /* Total number of directories */ - uint8_t *e2fs_contigdirs; + uint8_t *e2fs_contigdirs; /* (u) # of contig. allocated dirs */ char e2fs_wasvalid; /* valid at mount time */ off_t e2fs_maxfilesize; struct ext2_gd *e2fs_gd; /* Group Descriptors */ @@ -182,6 +166,14 @@ struct m_ext2fs { #define E2FS_DATE "95/08/09" #define E2FS_VERSION "0.5b" +/* First non-reserved inode for old ext2 filesystems */ +#define E2FS_REV0_FIRST_INO 11 + +/* + * The second extended file system magic number + */ +#define E2FS_MAGIC 0xEF53 + /* * Revision levels */ @@ -197,6 +189,7 @@ struct m_ext2fs { * compatible/incompatible features */ #define EXT2F_COMPAT_PREALLOC 0x0001 +#define EXT2F_COMPAT_HASJOURNAL 0x0004 #define EXT2F_COMPAT_RESIZE 0x0010 #define EXT2F_ROCOMPAT_SPARSESUPER 0x0001 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Sat Jan 22 09:39:44 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06372106564A for ; Sat, 22 Jan 2011 09:39:44 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id B50138FC16 for ; Sat, 22 Jan 2011 09:39:43 +0000 (UTC) Received: by gyf3 with SMTP id 3so808927gyf.13 for ; Sat, 22 Jan 2011 01:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=2pXR9JIzzKyPn3lzc24x4HN88QEZTWgihNNhNH3zEJw=; b=uLBQ55CTACpWTINhzUHfy5xrUApbasQwuqjMGi5+FrrW0ww2KR2h8XblURzmTHex0d crhYtOGWzkiSHlcrG9bVhkNad093K6PHhJSYKKiXoW2HV/f2fwowQJPJmc0Fon0QuROe bJRz3LfJWLVyqxmf/aF4Nn6YJ7rkwFaWjER4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ka7mfNAzyD/Rz6W3EOlJgHkPEG9zhEPjX5uSyGyBMzPwctEB+RdWc+PhImxF8pyFzc G8efwkfWeL/Xq8vutZ/CAwE87LCSsaUV5zxHV3TbxJmBayyeswp9+w3rYG727fnJtMeO QqquQaENCQruqFqsh3ub0R7/ciRrMr1TnmEBw= MIME-Version: 1.0 Received: by 10.90.54.3 with SMTP id c3mr2002005aga.186.1295687809352; Sat, 22 Jan 2011 01:16:49 -0800 (PST) Received: by 10.90.86.18 with HTTP; Sat, 22 Jan 2011 01:16:49 -0800 (PST) Date: Sat, 22 Jan 2011 01:16:49 -0800 Message-ID: From: Garrett Cooper To: freebsd-fs@freebsd.org Content-Type: multipart/mixed; boundary=0016e6587aa09dc58e049a6bd39b Subject: [PATCH] Fix includes for file-utilities to use time.h 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, 22 Jan 2011 09:39:44 -0000 --0016e6587aa09dc58e049a6bd39b Content-Type: text/plain; charset=ISO-8859-1 Hi, Many of the fs-related utilities appear to include sys/time.h instead of time.h . This is incorrect as per the manpages for the APIs and the POSIX definitions. The attached patch replaces sys/time.h where necessary with time.h and some minor style(9) header fixup is included in sbin/newfs/mkfs.c only. The work is part of a larger effort I started in //depot/user/gcooper/posix-conformance-work/ -- to make FreeBSD more POSIX compliant. If someone could please commit the following patch it would be much appreciated! Thanks! -Garrett --0016e6587aa09dc58e049a6bd39b Content-Type: text/x-patch; charset=US-ASCII; name="add-missing-file-utilities-time-h-includes.patch" Content-Disposition: attachment; filename="add-missing-file-utilities-time-h-includes.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gj8b101x0 ZGlmZiAtLWdpdCBhL3VzZXIvZ2Nvb3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3JrL3NiaW4vZHVt cC9pdGltZS5jIGIvdXNlci9nY29vcGVyL3Bvc2l4LWNvbmZvcm1hbmNlLXdvcmsvc2Jpbi9kdW1w L2l0aW1lLmMKaW5kZXggNjFlZDY3Yy4uMzM5YjZkOSAxMDA2NDQKLS0tIGEvdXNlci9nY29vcGVy L3Bvc2l4LWNvbmZvcm1hbmNlLXdvcmsvc2Jpbi9kdW1wL2l0aW1lLmMKKysrIGIvdXNlci9nY29v cGVyL3Bvc2l4LWNvbmZvcm1hbmNlLXdvcmsvc2Jpbi9kdW1wL2l0aW1lLmMKQEAgLTM3LDcgKzM3 LDYgQEAgc3RhdGljIGNvbnN0IGNoYXIgcmNzaWRbXSA9CiAKICNpbmNsdWRlIDxzeXMvcGFyYW0u aD4KICNpbmNsdWRlIDxzeXMvcXVldWUuaD4KLSNpbmNsdWRlIDxzeXMvdGltZS5oPgogCiAjaW5j bHVkZSA8dWZzL3Vmcy9kaW5vZGUuaD4KIApAQCAtNDksNiArNDgsNyBAQCBzdGF0aWMgY29uc3Qg Y2hhciByY3NpZFtdID0KICNpbmNsdWRlIDxzdGRpby5oPgogI2luY2x1ZGUgPHN0ZGxpYi5oPgog I2luY2x1ZGUgPHN0cmluZy5oPgorI2luY2x1ZGUgPHRpbWUuaD4KICNpbmNsdWRlIDx0aW1lY29u di5oPgogCiAjaW5jbHVkZSAiZHVtcC5oIgpkaWZmIC0tZ2l0IGEvdXNlci9nY29vcGVyL3Bvc2l4 LWNvbmZvcm1hbmNlLXdvcmsvc2Jpbi9kdW1wL21haW4uYyBiL3VzZXIvZ2Nvb3Blci9wb3NpeC1j b25mb3JtYW5jZS13b3JrL3NiaW4vZHVtcC9tYWluLmMKaW5kZXggMDJhZWU4YS4uZjdiODgyYyAx MDA2NDQKLS0tIGEvdXNlci9nY29vcGVyL3Bvc2l4LWNvbmZvcm1hbmNlLXdvcmsvc2Jpbi9kdW1w L21haW4uYworKysgYi91c2VyL2djb29wZXIvcG9zaXgtY29uZm9ybWFuY2Utd29yay9zYmluL2R1 bXAvbWFpbi5jCkBAIC00Myw3ICs0Myw2IEBAIHN0YXRpYyBjb25zdCBjaGFyIHJjc2lkW10gPQog CiAjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CiAjaW5jbHVkZSA8c3lzL3N0YXQuaD4KLSNpbmNsdWRl IDxzeXMvdGltZS5oPgogI2luY2x1ZGUgPHN5cy9tb3VudC5oPgogI2luY2x1ZGUgPHN5cy9kaXNr bGFiZWwuaD4KIApAQCAtNjQsNiArNjMsNyBAQCBzdGF0aWMgY29uc3QgY2hhciByY3NpZFtdID0K ICNpbmNsdWRlIDxzdGRpby5oPgogI2luY2x1ZGUgPHN0ZGxpYi5oPgogI2luY2x1ZGUgPHN0cmlu Zy5oPgorI2luY2x1ZGUgPHRpbWUuaD4KICNpbmNsdWRlIDx0aW1lY29udi5oPgogI2luY2x1ZGUg PHVuaXN0ZC5oPgogCmRpZmYgLS1naXQgYS91c2VyL2djb29wZXIvcG9zaXgtY29uZm9ybWFuY2Ut d29yay9zYmluL2R1bXAvb3B0ci5jIGIvdXNlci9nY29vcGVyL3Bvc2l4LWNvbmZvcm1hbmNlLXdv cmsvc2Jpbi9kdW1wL29wdHIuYwppbmRleCA5ZWU2MTFmLi43NjAwY2JmIDEwMDY0NAotLS0gYS91 c2VyL2djb29wZXIvcG9zaXgtY29uZm9ybWFuY2Utd29yay9zYmluL2R1bXAvb3B0ci5jCisrKyBi L3VzZXIvZ2Nvb3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3JrL3NiaW4vZHVtcC9vcHRyLmMKQEAg LTM4LDcgKzM4LDYgQEAgc3RhdGljIGNvbnN0IGNoYXIgcmNzaWRbXSA9CiAjaW5jbHVkZSA8c3lz L3BhcmFtLmg+CiAjaW5jbHVkZSA8c3lzL3F1ZXVlLmg+CiAjaW5jbHVkZSA8c3lzL3dhaXQuaD4K LSNpbmNsdWRlIDxzeXMvdGltZS5oPgogCiAjaW5jbHVkZSA8dWZzL3Vmcy9kaW5vZGUuaD4KIApA QCAtNTEsNiArNTAsNyBAQCBzdGF0aWMgY29uc3QgY2hhciByY3NpZFtdID0KICNpbmNsdWRlIDxz dHJpbmcuaD4KICNpbmNsdWRlIDxzdGRhcmcuaD4KICNpbmNsdWRlIDxzaWduYWwuaD4KKyNpbmNs dWRlIDx0aW1lLmg+CiAjaW5jbHVkZSA8dW5pc3RkLmg+CiAKICNpbmNsdWRlICJkdW1wLmgiCmRp ZmYgLS1naXQgYS91c2VyL2djb29wZXIvcG9zaXgtY29uZm9ybWFuY2Utd29yay9zYmluL2R1bXAv dGFwZS5jIGIvdXNlci9nY29vcGVyL3Bvc2l4LWNvbmZvcm1hbmNlLXdvcmsvc2Jpbi9kdW1wL3Rh cGUuYwppbmRleCBmMzAwNDVhLi5iNWUwNDUyIDEwMDY0NAotLS0gYS91c2VyL2djb29wZXIvcG9z aXgtY29uZm9ybWFuY2Utd29yay9zYmluL2R1bXAvdGFwZS5jCisrKyBiL3VzZXIvZ2Nvb3Blci9w b3NpeC1jb25mb3JtYW5jZS13b3JrL3NiaW4vZHVtcC90YXBlLmMKQEAgLTM3LDcgKzM3LDYgQEAg c3RhdGljIGNvbnN0IGNoYXIgcmNzaWRbXSA9CiAKICNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KICNp bmNsdWRlIDxzeXMvc29ja2V0Lmg+Ci0jaW5jbHVkZSA8c3lzL3RpbWUuaD4KICNpbmNsdWRlIDxz eXMvd2FpdC5oPgogI2luY2x1ZGUgPHN5cy9zdGF0Lmg+CiAKQEAgLTU0LDYgKzUzLDcgQEAgc3Rh dGljIGNvbnN0IGNoYXIgcmNzaWRbXSA9CiAjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNsdWRlIDxz dGRsaWIuaD4KICNpbmNsdWRlIDxzdHJpbmcuaD4KKyNpbmNsdWRlIDx0aW1lLmg+CiAjaW5jbHVk ZSA8dW5pc3RkLmg+CiAKICNpbmNsdWRlICJkdW1wLmgiCmRpZmYgLS1naXQgYS91c2VyL2djb29w ZXIvcG9zaXgtY29uZm9ybWFuY2Utd29yay9zYmluL2ZzY2tfZmZzL2lub2RlLmMgYi91c2VyL2dj b29wZXIvcG9zaXgtY29uZm9ybWFuY2Utd29yay9zYmluL2ZzY2tfZmZzL2lub2RlLmMKaW5kZXgg ZGRhYzg2ZC4uZmM3OTgwZCAxMDA2NDQKLS0tIGEvdXNlci9nY29vcGVyL3Bvc2l4LWNvbmZvcm1h bmNlLXdvcmsvc2Jpbi9mc2NrX2Zmcy9pbm9kZS5jCisrKyBiL3VzZXIvZ2Nvb3Blci9wb3NpeC1j b25mb3JtYW5jZS13b3JrL3NiaW4vZnNja19mZnMvaW5vZGUuYwpAQCAtMzcsNyArMzcsNiBAQCBf X0ZCU0RJRCgiJEZyZWVCU0Q6IHNyYy9zYmluL2ZzY2tfZmZzL2lub2RlLmMsdiAxLjQwIDIwMDkv MDIvMDQgMDE6MDI6NTYgbWNrdXNpYwogCiAjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CiAjaW5jbHVk ZSA8c3lzL3N0ZGludC5oPgotI2luY2x1ZGUgPHN5cy90aW1lLmg+CiAjaW5jbHVkZSA8c3lzL3N5 c2N0bC5oPgogCiAjaW5jbHVkZSA8dWZzL3Vmcy9kaW5vZGUuaD4KQEAgLTQ3LDYgKzQ2LDcgQEAg X19GQlNESUQoIiRGcmVlQlNEOiBzcmMvc2Jpbi9mc2NrX2Zmcy9pbm9kZS5jLHYgMS40MCAyMDA5 LzAyLzA0IDAxOjAyOjU2IG1ja3VzaWMKICNpbmNsdWRlIDxlcnIuaD4KICNpbmNsdWRlIDxwd2Qu aD4KICNpbmNsdWRlIDxzdHJpbmcuaD4KKyNpbmNsdWRlIDx0aW1lLmg+CiAKICNpbmNsdWRlICJm c2NrLmgiCiAKZGlmZiAtLWdpdCBhL3VzZXIvZ2Nvb3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3Jr L3NiaW4vZnNja19mZnMvbWFpbi5jIGIvdXNlci9nY29vcGVyL3Bvc2l4LWNvbmZvcm1hbmNlLXdv cmsvc2Jpbi9mc2NrX2Zmcy9tYWluLmMKaW5kZXggMzk4MGJiZi4uMTQyMzI4YyAxMDA2NDQKLS0t IGEvdXNlci9nY29vcGVyL3Bvc2l4LWNvbmZvcm1hbmNlLXdvcmsvc2Jpbi9mc2NrX2Zmcy9tYWlu LmMKKysrIGIvdXNlci9nY29vcGVyL3Bvc2l4LWNvbmZvcm1hbmNlLXdvcmsvc2Jpbi9mc2NrX2Zm cy9tYWluLmMKQEAgLTQyLDExICs0MiwxMCBAQCBzdGF0aWMgY2hhciBzY2NzaWRbXSA9ICJAKCMp bWFpbi5jCTguNiAoQmVya2VsZXkpIDUvMTQvOTUiOwogX19GQlNESUQoIiRGcmVlQlNEOiBzcmMv c2Jpbi9mc2NrX2Zmcy9tYWluLmMsdiAxLjYxIDIwMTAvMDgvMDMgMDk6MjE6MTMgYnogRXhwICQi KTsKIAogI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgotI2luY2x1ZGUgPHN5cy9zdGF0Lmg+CiAjaW5j bHVkZSA8c3lzL2ZpbGUuaD4KLSNpbmNsdWRlIDxzeXMvdGltZS5oPgogI2luY2x1ZGUgPHN5cy9t b3VudC5oPgogI2luY2x1ZGUgPHN5cy9yZXNvdXJjZS5oPgorI2luY2x1ZGUgPHN5cy9zdGF0Lmg+ CiAjaW5jbHVkZSA8c3lzL3N5c2N0bC5oPgogI2luY2x1ZGUgPHN5cy91aW8uaD4KICNpbmNsdWRl IDxzeXMvZGlza2xhYmVsLmg+CkBAIC02Miw2ICs2MSw3IEBAIF9fRkJTRElEKCIkRnJlZUJTRDog c3JjL3NiaW4vZnNja19mZnMvbWFpbi5jLHYgMS42MSAyMDEwLzA4LzAzIDA5OjIxOjEzIGJ6IEV4 cCAkCiAjaW5jbHVkZSA8cGF0aHMuaD4KICNpbmNsdWRlIDxzdGRpbnQuaD4KICNpbmNsdWRlIDxz dHJpbmcuaD4KKyNpbmNsdWRlIDx0aW1lLmg+CiAKICNpbmNsdWRlICJmc2NrLmgiCiAKZGlmZiAt LWdpdCBhL3VzZXIvZ2Nvb3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3JrL3NiaW4vZnNja19mZnMv c3VqLmMgYi91c2VyL2djb29wZXIvcG9zaXgtY29uZm9ybWFuY2Utd29yay9zYmluL2ZzY2tfZmZz L3N1ai5jCmluZGV4IGIxNmVkMmYuLmEzOGM1NjcgMTAwNjQ0Ci0tLSBhL3VzZXIvZ2Nvb3Blci9w b3NpeC1jb25mb3JtYW5jZS13b3JrL3NiaW4vZnNja19mZnMvc3VqLmMKKysrIGIvdXNlci9nY29v cGVyL3Bvc2l4LWNvbmZvcm1hbmNlLXdvcmsvc2Jpbi9mc2NrX2Zmcy9zdWouYwpAQCAtMzcsNiAr MzcsOCBAQCBfX0ZCU0RJRCgiJEZyZWVCU0Q6IHNyYy9zYmluL2ZzY2tfZmZzL3N1ai5jLHYgMS40 IDIwMTAvMDcvMDYgMDc6MDc6MjkgamVmZiBFeHAgJAogI2luY2x1ZGUgPHVmcy91ZnMvZGlyLmg+ CiAjaW5jbHVkZSA8dWZzL2Zmcy9mcy5oPgogCisjaW5jbHVkZSA8YXNzZXJ0Lmg+CisjaW5jbHVk ZSA8ZXJyLmg+CiAjaW5jbHVkZSA8c2V0am1wLmg+CiAjaW5jbHVkZSA8c3RkYXJnLmg+CiAjaW5j bHVkZSA8c3RkaW8uaD4KQEAgLTQ2LDggKzQ4LDcgQEAgX19GQlNESUQoIiRGcmVlQlNEOiBzcmMv c2Jpbi9mc2NrX2Zmcy9zdWouYyx2IDEuNCAyMDEwLzA3LzA2IDA3OjA3OjI5IGplZmYgRXhwICQK ICNpbmNsdWRlIDxzdHJpbmcuaD4KICNpbmNsdWRlIDxzdHJpbmdzLmg+CiAjaW5jbHVkZSA8c3lz ZXhpdHMuaD4KLSNpbmNsdWRlIDxlcnIuaD4KLSNpbmNsdWRlIDxhc3NlcnQuaD4KKyNpbmNsdWRl IDx0aW1lLmg+CiAKICNpbmNsdWRlICJmc2NrLmgiCiAKZGlmZiAtLWdpdCBhL3VzZXIvZ2Nvb3Bl ci9wb3NpeC1jb25mb3JtYW5jZS13b3JrL3NiaW4vZnNkYi9mc2RiLmMgYi91c2VyL2djb29wZXIv cG9zaXgtY29uZm9ybWFuY2Utd29yay9zYmluL2ZzZGIvZnNkYi5jCmluZGV4IDMzZTdkMzkuLmJm ZDYxZDcgMTAwNjQ0Ci0tLSBhL3VzZXIvZ2Nvb3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3JrL3Ni aW4vZnNkYi9mc2RiLmMKKysrIGIvdXNlci9nY29vcGVyL3Bvc2l4LWNvbmZvcm1hbmNlLXdvcmsv c2Jpbi9mc2RiL2ZzZGIuYwpAQCAtMzQsMTMgKzM0LDEzIEBAIHN0YXRpYyBjb25zdCBjaGFyIHJj c2lkW10gPQogI2VuZGlmIC8qIG5vdCBsaW50ICovCiAKICNpbmNsdWRlIDxzeXMvcGFyYW0uaD4K LSNpbmNsdWRlIDxzeXMvdGltZS5oPgogI2luY2x1ZGUgPGN0eXBlLmg+CiAjaW5jbHVkZSA8ZXJy Lmg+CiAjaW5jbHVkZSA8Z3JwLmg+CiAjaW5jbHVkZSA8aGlzdGVkaXQuaD4KICNpbmNsdWRlIDxw d2QuaD4KICNpbmNsdWRlIDxzdHJpbmcuaD4KKyNpbmNsdWRlIDx0aW1lLmg+CiAjaW5jbHVkZSA8 dGltZWNvbnYuaD4KIAogI2luY2x1ZGUgPHVmcy91ZnMvZGlub2RlLmg+CmRpZmYgLS1naXQgYS91 c2VyL2djb29wZXIvcG9zaXgtY29uZm9ybWFuY2Utd29yay9zYmluL2ZzaXJhbmQvZnNpcmFuZC5j IGIvdXNlci9nY29vcGVyL3Bvc2l4LWNvbmZvcm1hbmNlLXdvcmsvc2Jpbi9mc2lyYW5kL2ZzaXJh bmQuYwppbmRleCBiMzA1NmJhLi5kMGE1MjBjIDEwMDY0NAotLS0gYS91c2VyL2djb29wZXIvcG9z aXgtY29uZm9ybWFuY2Utd29yay9zYmluL2ZzaXJhbmQvZnNpcmFuZC5jCisrKyBiL3VzZXIvZ2Nv b3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3JrL3NiaW4vZnNpcmFuZC9mc2lyYW5kLmMKQEAgLTM1 LDkgKzM1LDggQEAgc3RhdGljIGNvbnN0IGNoYXIgcmNzaWRbXSA9CiAgICIkRnJlZUJTRDogc3Jj L3NiaW4vZnNpcmFuZC9mc2lyYW5kLmMsdiAxLjE0IDIwMTAvMDUvMTQgMTQ6MjY6NDkgdXFzIEV4 cCAkIjsKICNlbmRpZiAvKiBub3QgbGludCAqLwogCi0jaW5jbHVkZSA8c3lzL2Rpc2tsYWJlbC5o PgogI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgotI2luY2x1ZGUgPHN5cy90aW1lLmg+CisjaW5jbHVk ZSA8c3lzL2Rpc2tsYWJlbC5oPgogI2luY2x1ZGUgPHN5cy9yZXNvdXJjZS5oPgogCiAjaW5jbHVk ZSA8dWZzL3Vmcy9kaW5vZGUuaD4KQEAgLTUwLDYgKzQ5LDcgQEAgc3RhdGljIGNvbnN0IGNoYXIg cmNzaWRbXSA9CiAjaW5jbHVkZSA8c3RkaW50Lmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+CiAjaW5j bHVkZSA8c3RyaW5nLmg+CisjaW5jbHVkZSA8dGltZS5oPgogI2luY2x1ZGUgPHVuaXN0ZC5oPgog CiBzdGF0aWMgdm9pZCB1c2FnZSh2b2lkKSBfX2RlYWQyOwpkaWZmIC0tZ2l0IGEvdXNlci9nY29v cGVyL3Bvc2l4LWNvbmZvcm1hbmNlLXdvcmsvc2Jpbi9uZXdmcy9ta2ZzLmMgYi91c2VyL2djb29w ZXIvcG9zaXgtY29uZm9ybWFuY2Utd29yay9zYmluL25ld2ZzL21rZnMuYwppbmRleCAxNTE4YmFi Li4yM2ZhZjYyIDEwMDY0NAotLS0gYS91c2VyL2djb29wZXIvcG9zaXgtY29uZm9ybWFuY2Utd29y ay9zYmluL25ld2ZzL21rZnMuYworKysgYi91c2VyL2djb29wZXIvcG9zaXgtY29uZm9ybWFuY2Ut d29yay9zYmluL25ld2ZzL21rZnMuYwpAQCAtNDQsNiArNDQsMTQgQEAgc3RhdGljIGNoYXIgc2Nj c2lkW10gPSAiQCgjKW1rZnMuYwk4LjExIChCZXJrZWxleSkgNS8zLzk1IjsKICNpbmNsdWRlIDxz eXMvY2RlZnMuaD4KIF9fRkJTRElEKCIkRnJlZUJTRDogc3JjL3NiaW4vbmV3ZnMvbWtmcy5jLHYg MS4xMDQgMjAxMC8xMi8yOSAxMjozMToxOCBraWIgRXhwICQiKTsKIAorI2luY2x1ZGUgPHN5cy9w YXJhbS5oPgorI2luY2x1ZGUgPHN5cy9kaXNrbGFiZWwuaD4KKyNpbmNsdWRlIDxzeXMvZmlsZS5o PgorI2luY2x1ZGUgPHN5cy9pb2N0bC5oPgorI2luY2x1ZGUgPHN5cy9tbWFuLmg+CisjaW5jbHVk ZSA8c3lzL3Jlc291cmNlLmg+CisjaW5jbHVkZSA8c3lzL3N0YXQuaD4KKyNpbmNsdWRlIDxzeXMv d2FpdC5oPgogI2luY2x1ZGUgPGVyci5oPgogI2luY2x1ZGUgPGdycC5oPgogI2luY2x1ZGUgPGxp bWl0cy5oPgpAQCAtNTIsMjAgKzYwLDExIEBAIF9fRkJTRElEKCIkRnJlZUJTRDogc3JjL3NiaW4v bmV3ZnMvbWtmcy5jLHYgMS4xMDQgMjAxMC8xMi8yOSAxMjozMToxOCBraWIgRXhwICQiCiAjaW5j bHVkZSA8c3RyaW5nLmg+CiAjaW5jbHVkZSA8c3RkaW50Lmg+CiAjaW5jbHVkZSA8c3RkaW8uaD4K KyNpbmNsdWRlIDx0aW1lLmg+CiAjaW5jbHVkZSA8dW5pc3RkLmg+Ci0jaW5jbHVkZSA8c3lzL3Bh cmFtLmg+Ci0jaW5jbHVkZSA8c3lzL3RpbWUuaD4KLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KLSNp bmNsdWRlIDxzeXMvd2FpdC5oPgotI2luY2x1ZGUgPHN5cy9yZXNvdXJjZS5oPgotI2luY2x1ZGUg PHN5cy9zdGF0Lmg+CiAjaW5jbHVkZSA8dWZzL3Vmcy9kaW5vZGUuaD4KICNpbmNsdWRlIDx1ZnMv dWZzL2Rpci5oPgogI2luY2x1ZGUgPHVmcy9mZnMvZnMuaD4KLSNpbmNsdWRlIDxzeXMvZGlza2xh YmVsLmg+Ci0jaW5jbHVkZSA8c3lzL2ZpbGUuaD4KLSNpbmNsdWRlIDxzeXMvbW1hbi5oPgotI2lu Y2x1ZGUgPHN5cy9pb2N0bC5oPgogI2luY2x1ZGUgIm5ld2ZzLmgiCiAKIC8qCmRpZmYgLS1naXQg YS91c2VyL2djb29wZXIvcG9zaXgtY29uZm9ybWFuY2Utd29yay91c3Iuc2Jpbi9tYWtlZnMvZmZz LmMgYi91c2VyL2djb29wZXIvcG9zaXgtY29uZm9ybWFuY2Utd29yay91c3Iuc2Jpbi9tYWtlZnMv ZmZzLmMKaW5kZXggMWVjN2VjMi4uNTM2MThlNyAxMDA2NDQKLS0tIGEvdXNlci9nY29vcGVyL3Bv c2l4LWNvbmZvcm1hbmNlLXdvcmsvdXNyLnNiaW4vbWFrZWZzL2Zmcy5jCisrKyBiL3VzZXIvZ2Nv b3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3JrL3Vzci5zYmluL21ha2Vmcy9mZnMuYwpAQCAtODAs NiArODAsNyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0Q6IHNyYy91c3Iuc2Jpbi9tYWtlZnMvZmZzLmMs diAxLjMgMjAxMC8xMS8wNyAxNjowNTowNCBjb2duZXQgRQogI2luY2x1ZGUgPHN0ZGlvLmg+CiAj aW5jbHVkZSA8c3RkbGliLmg+CiAjaW5jbHVkZSA8c3RyaW5nLmg+CisjaW5jbHVkZSA8dGltZS5o PgogI2luY2x1ZGUgPHVuaXN0ZC5oPgogCiAjaW5jbHVkZSAibWFrZWZzLmgiCmRpZmYgLS1naXQg YS91c2VyL2djb29wZXIvcG9zaXgtY29uZm9ybWFuY2Utd29yay91c3Iuc2Jpbi9tYWtlZnMvbWFr ZWZzLmMgYi91c2VyL2djb29wZXIvcG9zaXgtY29uZm9ybWFuY2Utd29yay91c3Iuc2Jpbi9tYWtl ZnMvbWFrZWZzLmMKaW5kZXggNGM3ZjdkMC4uZDM5MzBkYiAxMDA2NDQKLS0tIGEvdXNlci9nY29v cGVyL3Bvc2l4LWNvbmZvcm1hbmNlLXdvcmsvdXNyLnNiaW4vbWFrZWZzL21ha2Vmcy5jCisrKyBi L3VzZXIvZ2Nvb3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3JrL3Vzci5zYmluL21ha2Vmcy9tYWtl ZnMuYwpAQCAtNDUsNiArNDUsNyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0Q6IHNyYy91c3Iuc2Jpbi9t YWtlZnMvbWFrZWZzLmMsdiAxLjIgMjAxMC8xMS8wNyAxNjowNTowNCBjb2duZQogI2luY2x1ZGUg PHN0ZGlvLmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+CiAjaW5jbHVkZSA8c3RyaW5nLmg+CisjaW5j bHVkZSA8dGltZS5oPgogI2luY2x1ZGUgPHVuaXN0ZC5oPgogCiAjaW5jbHVkZSAibWFrZWZzLmgi CmRpZmYgLS1naXQgYS91c2VyL2djb29wZXIvcG9zaXgtY29uZm9ybWFuY2Utd29yay91c3Iuc2Jp bi9xdW90L3F1b3QuYyBiL3VzZXIvZ2Nvb3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3JrL3Vzci5z YmluL3F1b3QvcXVvdC5jCmluZGV4IDI4Njc4ZjkuLjE5ZWI2MTIgMTAwNjQ0Ci0tLSBhL3VzZXIv Z2Nvb3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3JrL3Vzci5zYmluL3F1b3QvcXVvdC5jCisrKyBi L3VzZXIvZ2Nvb3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3JrL3Vzci5zYmluL3F1b3QvcXVvdC5j CkBAIC0zNiw3ICszNiw2IEBAIF9fRkJTRElEKCIkRnJlZUJTRDogc3JjL3Vzci5zYmluL3F1b3Qv cXVvdC5jLHYgMS4yNyAyMDA4LzA5LzE0IDExOjUwOjE5IGVkIEV4cCAkCiAjaW5jbHVkZSA8c3lz L3N0ZGludC5oPgogI2luY2x1ZGUgPHN5cy9tb3VudC5oPgogI2luY2x1ZGUgPHN5cy9kaXNrbGFi ZWwuaD4KLSNpbmNsdWRlIDxzeXMvdGltZS5oPgogI2luY2x1ZGUgPHVmcy91ZnMvZGlub2RlLmg+ CiAjaW5jbHVkZSA8dWZzL2Zmcy9mcy5oPgogCkBAIC00OSw2ICs0OCw3IEBAIF9fRkJTRElEKCIk RnJlZUJTRDogc3JjL3Vzci5zYmluL3F1b3QvcXVvdC5jLHYgMS4yNyAyMDA4LzA5LzE0IDExOjUw OjE5IGVkIEV4cCAkCiAjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNsdWRlIDxzdGRsaWIuaD4KICNp bmNsdWRlIDxzdHJpbmcuaD4KKyNpbmNsdWRlIDx0aW1lLmg+CiAjaW5jbHVkZSA8dW5pc3RkLmg+ CiAKIC8qIHNvbWUgZmxhZ3Mgb2Ygd2hhdCB0byBkbzogKi8K --0016e6587aa09dc58e049a6bd39b-- From owner-freebsd-fs@FreeBSD.ORG Sat Jan 22 10:51:33 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6138106564A for ; Sat, 22 Jan 2011 10:51:33 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA8D8FC08 for ; Sat, 22 Jan 2011 10:51:33 +0000 (UTC) Received: from Octa64 (octa64.tdx.co.uk [62.13.130.232]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/Kp) with ESMTP id p0MAcZn4031570 for ; Sat, 22 Jan 2011 10:38:35 GMT Date: Sat, 22 Jan 2011 10:39:13 +0000 From: Karl Pielorz To: freebsd-fs@freebsd.org Message-ID: <1ABA88EDF84B6472579216FE@Octa64> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Write cache, is write cache, is write cache? 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, 22 Jan 2011 10:51:33 -0000 Hi, I've a small HP server I've been using recently (an NL36). I've got ZFS setup on it, and it runs quite nicely. I was using the server for zeroing some drives the other day - and noticed that a: dd if=/dev/zero of=/dev/ada0 bs=2m Gives around 12Mbyte/sec throughput when that's all that's running on the machine. Looking in the BIOS is a "Enabled drive write cache" option - which was set to 'No'. Changing it to 'Yes' - I now get around 90-120Mbyte/sec doing the same thing. Knowing all the issues with IDE drives and write caches - is there any way of telling if this would be safe to enable with ZFS? (i.e. if the option is likely to be making the drive completely ignore flush requests?) - or if it's still honouring the various 'write through' options if set on data to be written? I'm presuming DD won't by default be writing the data with the 'flush' bit set - as it probably doesn't know about it. Is there anyway of testing this? (say using some tool to write the data using either lots of 'cache flush' or 'write through' stuff) - and seeing if the performance drops back to nearer the 12Mbyte/sec? I've not enabled the option with the ZFS drives in the machine - I suppose I could test it. Write performance on the unit isn't that bad [it's not stunning] - though with 4 drives in a mirrored set - it probably helps hide some of the impact this option might have. -Kp From owner-freebsd-fs@FreeBSD.ORG Sat Jan 22 11:10:48 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 047BF106564A for ; Sat, 22 Jan 2011 11:10:48 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id A63A38FC1C for ; Sat, 22 Jan 2011 11:10:47 +0000 (UTC) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta12.westchester.pa.mail.comcast.net with comcast id yb8d1f0020EZKEL5CbAnRd; Sat, 22 Jan 2011 11:10:47 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta01.westchester.pa.mail.comcast.net with comcast id ybAm1f00F2tehsa3MbAnTX; Sat, 22 Jan 2011 11:10:47 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 390029B427; Sat, 22 Jan 2011 03:10:45 -0800 (PST) Date: Sat, 22 Jan 2011 03:10:45 -0800 From: Jeremy Chadwick To: Karl Pielorz Message-ID: <20110122111045.GA59117@icarus.home.lan> References: <1ABA88EDF84B6472579216FE@Octa64> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ABA88EDF84B6472579216FE@Octa64> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Write cache, is write cache, is write cache? 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, 22 Jan 2011 11:10:48 -0000 On Sat, Jan 22, 2011 at 10:39:13AM +0000, Karl Pielorz wrote: > I've a small HP server I've been using recently (an NL36). I've got > ZFS setup on it, and it runs quite nicely. > > I was using the server for zeroing some drives the other day - and > noticed that a: > > dd if=/dev/zero of=/dev/ada0 bs=2m > > Gives around 12Mbyte/sec throughput when that's all that's running > on the machine. > > Looking in the BIOS is a "Enabled drive write cache" option - which > was set to 'No'. Changing it to 'Yes' - I now get around > 90-120Mbyte/sec doing the same thing. > > Knowing all the issues with IDE drives and write caches - is there > any way of telling if this would be safe to enable with ZFS? (i.e. > if the option is likely to be making the drive completely ignore > flush requests?) - or if it's still honouring the various 'write > through' options if set on data to be written? > > I'm presuming DD won't by default be writing the data with the > 'flush' bit set - as it probably doesn't know about it. > > Is there anyway of testing this? (say using some tool to write the > data using either lots of 'cache flush' or 'write through' stuff) - > and seeing if the performance drops back to nearer the 12Mbyte/sec? > > I've not enabled the option with the ZFS drives in the machine - I > suppose I could test it. > > Write performance on the unit isn't that bad [it's not stunning] - > though with 4 drives in a mirrored set - it probably helps hide some > of the impact this option might have. I'm stating the below with the assumption that you have SATA disks with some form of AHCI-based controller (possibly Intel ICHxx or ESBx on-board), and *not* a hardware RAID controller with cache/RAM of its own: Keep write caching *enabled* in the system BIOS. ZFS will take care of any underlying "issues" in the case the system abruptly loses power (hard disk cache contents lost), since you're using ZFS mirroring. The same would apply if you were using raidz{1,2}, but not if you were using ZFS on a single device (no mirroring/raidz). In that scenario, expect data loss; but the same could be said of any non-journalling filesystem. I have no idea why your BIOS setting for this option was disabled. I do not know if it's the factory default either; you would have to talk to HP about that, or spend the time figuring out who was in the system BIOS last and how/if/why they messed around (the number of possibilities for why the option is disabled are endless). You can use bonnie++ (ports/benchmarks/bonnie++) if you wish to do throughput and/or benchmark testing of sorts. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sat Jan 22 15:50:45 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BE061065673 for ; Sat, 22 Jan 2011 15:50:45 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 87EEB8FC14 for ; Sat, 22 Jan 2011 15:50:44 +0000 (UTC) Received: from Octa64 (octa64.tdx.co.uk [62.13.130.232]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/Kp) with ESMTP id p0MFogv3057225; Sat, 22 Jan 2011 15:50:42 GMT Date: Sat, 22 Jan 2011 15:51:21 +0000 From: Karl Pielorz To: Jeremy Chadwick Message-ID: In-Reply-To: <20110122111045.GA59117@icarus.home.lan> References: <1ABA88EDF84B6472579216FE@Octa64> <20110122111045.GA59117@icarus.home.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-fs@freebsd.org Subject: Re: Write cache, is write cache, is write cache? 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, 22 Jan 2011 15:50:45 -0000 --On 22 January 2011 03:10 -0800 Jeremy Chadwick wrote: >> Write performance on the unit isn't that bad [it's not stunning] - >> though with 4 drives in a mirrored set - it probably helps hide some >> of the impact this option might have. > > I'm stating the below with the assumption that you have SATA disks with > some form of AHCI-based controller (possibly Intel ICHxx or ESBx > on-board), and *not* a hardware RAID controller with cache/RAM of its > own: It is an onboard AHCI based controller, it can do RAID 0/1 - but I'm using it as just JBOD / 1:1 (i.e. individual channels). > Keep write caching *enabled* in the system BIOS. ZFS will take care of > any underlying "issues" in the case the system abruptly loses power > (hard disk cache contents lost), since you're using ZFS mirroring. Ok, I'll give it a whirl and see what it does to the performance. I was more concerned if ZFS would be writing data it doesn't want cached - and that BIOS setting effectively makes it cached. > I have no idea why your BIOS setting for this option was disabled. I do > not know if it's the factory default either; you would have to talk to > HP about that, or spend the time figuring out who was in the system BIOS > last and how/if/why they messed around (the number of possibilities for > why the option is disabled are endless). It is the factory default. I have three of these machines (HP MicroServers), shipped from different suppliers - two had slightly older BIOS versions on, but *all* had Write Cache disabled in BIOS, both before & after the BIOS updates. > You can use bonnie++ (ports/benchmarks/bonnie++) if you wish to do > throughput and/or benchmark testing of sorts. I'll have a look at those - I'm more interested in finding a tool that will write data both with, and without the "don't cache this" flag(s) set - to see if the performance is the same (you would hope that regardless of the BIOS setting that writing entirely data that's marked not to be cached, the performance would 'sink' back down to a sedate 12Mbytes/sec) - if it doesn't, something is lying somewhere :) -Karl From owner-freebsd-fs@FreeBSD.ORG Sat Jan 22 17:27:19 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4D44106566B for ; Sat, 22 Jan 2011 17:27:19 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 04A4E8FC08 for ; Sat, 22 Jan 2011 17:27:19 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 02B26E8322; Sat, 22 Jan 2011 17:27:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=qe9xcSJD85Nr rg4iPX3aKqibRTs=; b=m4mStQu01kRFnlLPdzF2Ex+AecIxYGqJ1nQd3LL4mDis Bt6SmotvRQt0JHGr1K6QRGoq6iQt+hASRJHo0WgbYvx/UyQEnqkRDVaZMQZhjxtc PNgs6TAIErhBMfiBc+63OuVyem6/ZuoYducAE7CFYlssCSnoLK32n3Ujp713fUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=b60HTX 4zJ9hmWWQDKp1KQ3sVyzkoF2qkrLFv84tJuWCn3Kl350rDHgYee+aGArHJxcjuqR bdP9Gyb4tgyjNb2qKuWzQJ5TzXIuMOpx8oqQ2wZe8EvWYhr+yjz+gVbZD4CT+iS1 Q6PSMeCfAMyeTX9OG0/uENVkTpHgRPGLV5Jo4= Received: from unknown (client-86-23-95-6.brhm.adsl.virginmedia.com [86.23.95.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id AE683E8321; Sat, 22 Jan 2011 17:27:16 +0000 (GMT) Date: Sat, 22 Jan 2011 17:27:14 +0000 From: Bruce Cran To: Karl Pielorz Message-ID: <20110122172714.00002274@unknown> In-Reply-To: References: <1ABA88EDF84B6472579216FE@Octa64> <20110122111045.GA59117@icarus.home.lan> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Write cache, is write cache, is write cache? 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, 22 Jan 2011 17:27:19 -0000 On Sat, 22 Jan 2011 15:51:21 +0000 Karl Pielorz wrote: > I'll have a look at those - I'm more interested in finding a tool > that will write data both with, and without the "don't cache this" > flag(s) set - to see if the performance is the same (you would hope > that regardless of the BIOS setting that writing entirely data that's > marked not to be cached, the performance would 'sink' back down to a > sedate 12Mbytes/sec) - if it doesn't, something is lying somewhere :) sysutils/fio supports that: just add "fsync=x" to the configuration file and it'll send a request to the OS to flush the data to disk every x blocks. -- Bruce Cran From owner-freebsd-fs@FreeBSD.ORG Sat Jan 22 19:09:00 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ADC5106566B; Sat, 22 Jan 2011 19:09:00 +0000 (UTC) (envelope-from cforgeron@acsi.ca) Received: from mta01.eastlink.ca (mta01.eastlink.ca [24.224.136.30]) by mx1.freebsd.org (Postfix) with ESMTP id D3BE18FC23; Sat, 22 Jan 2011 19:08:59 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ip04.eastlink.ca ([unknown] [24.222.39.52]) by mta01.eastlink.ca (Sun Java(tm) System Messaging Server 7u3-12.01 64bit (built Oct 15 2009)) with ESMTP id <0LFF002F7UIYL7M2@mta01.eastlink.ca>; Sat, 22 Jan 2011 15:08:58 -0400 (AST) X-CMAE-Score: 0 X-CMAE-Analysis: v=1.1 cv=b0sI0M7bjhCmEOs51LbeKzGQ5ECIs9m+H5QCeOcUmtc= c=1 sm=1 a=kj9zAlcOel0A:10 a=MIl_wUwkK7mT0Sd1HeQA:9 a=D5HGGtvjFIuUQ0MB7dC-Og9XXisA:4 a=CjuIK1q_8ugA:10 a=ZjIqTmGINkQKjhCx/60B3Q==:117 Received: from blk-222-10-85.eastlink.ca (HELO server7.acsi.ca) ([24.222.10.85]) by ip04.eastlink.ca with ESMTP; Sat, 22 Jan 2011 15:08:58 -0400 Received: from server7.acsi.ca ([192.168.9.7]) by server7.acsi.ca ([192.168.9.7]) with mapi; Sat, 22 Jan 2011 15:08:52 -0400 From: Chris Forgeron To: Pawel Jakub Dawidek Date: Sat, 22 Jan 2011 15:08:51 -0400 Thread-topic: My ZFS v28 Testing Experience Thread-index: AcuzcbzI9prO2K7/S8SCrzq+LoNNtAG9aPPA Message-id: References: <20101213214556.GC2038@garage.freebsd.pl> <20110113223125.GA2330@garage.freebsd.pl> In-reply-to: <20110113223125.GA2330@garage.freebsd.pl> Accept-Language: en-US Content-language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Cc: "freebsd-fs@freebsd.org" , "freebsd-current@freebsd.org" Subject: RE: My ZFS v28 Testing Experience 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, 22 Jan 2011 19:09:00 -0000 >Before we go any further could you please confirm that you commented out this line in sys/modules/zfs/Makefile: > > CFLAGS+=-DDEBUG=1 > >This turns all kind of ZFS debugging and slows it down a lot, but for the correctness testing is invaluable. This will >be turned off once we import ZFS into FreeBSD-CURRENT. Ah! I did not do this. My bad, I've made the edit, and will be recompiling today to see the differences this makes. I will also clone my disk, turn witness and full debug back on, and then try and find out where my problems importing a pool with multiple cache/log devices comes from. It's quite possible it's not hanging, just taking forever, and I'm impatient and not letting it sit for a n hour to see if it completes. Will report back once I have numbers. From owner-freebsd-fs@FreeBSD.ORG Sat Jan 22 23:16:34 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86197106566B; Sat, 22 Jan 2011 23:16:34 +0000 (UTC) (envelope-from am@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id 0AF798FC19; Sat, 22 Jan 2011 23:16:33 +0000 (UTC) Received: from bolt.zol (nereis.pl [62.121.98.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id 5856428; Sun, 23 Jan 2011 00:12:21 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Pawel Jakub Dawidek" References: <20110117012739.GF82886@garage.freebsd.pl> Date: Sun, 23 Jan 2011 00:16:30 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Emil Smolenski" Message-ID: In-Reply-To: <20110117012739.GF82886@garage.freebsd.pl> User-Agent: Opera Mail/11.00 (FreeBSD) Cc: freebsd-fs@freebsd.org Subject: Re: [ZFS] Booting from zpool created on 4k-sector drive 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, 22 Jan 2011 23:16:34 -0000 On Mon, 17 Jan 2011 02:27:39 +0100, Pawel Jakub Dawidek wrote: > On Tue, Dec 21, 2010 at 03:29:01PM +0100, Emil Smolenski wrote: >> Hello, >> >> There is a hack to force zpool creation with minimum sector size equal >> to 4k: (cut -- description of gnop hack) >> But there is one problem: I cannot boot from such pool. Error message: >> >> ZFS: i/o error - all block copies unavailable >> ZFS: can't read MOS >> ZFS: unexpected object set type 0 > > Tracking it down and fixing took all my free time during this weekend, > eh. Thank you for all your hard work on solving this issue. > I fixed this in ZFSv28 and I'm afraid I'm not going to backport the fix > to ZFSv15, as I also did many other changes while working on this > (booting off of RAIDZ3 is now supported, for example). > > Here is the patch if someone would like to try it: > > http://people.freebsd.org/~pjd/patches/zfs_boot_fixes.patch This patch works as expected, thanks! -- am From owner-freebsd-fs@FreeBSD.ORG Sat Jan 22 23:50:10 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FB3B106566B for ; Sat, 22 Jan 2011 23:50:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 538448FC1B for ; Sat, 22 Jan 2011 23:50:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0MNoAUO015022 for ; Sat, 22 Jan 2011 23:50:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0MNoALR015021; Sat, 22 Jan 2011 23:50:10 GMT (envelope-from gnats) Date: Sat, 22 Jan 2011 23:50:10 GMT Message-Id: <201101222350.p0MNoALR015021@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Emil Smolenski" Cc: Subject: Re: kern/153695: [patch] [zfs] Booting from zpool created on 4k-sector drive doesn't work X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Emil Smolenski List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 23:50:10 -0000 The following reply was made to PR kern/153695; it has been noted by GNATS. From: "Emil Smolenski" To: bug-followup@freebsd.org Cc: "Pawel Jakub Dawidek" Subject: Re: kern/153695: [patch] [zfs] Booting from zpool created on 4k-sector drive doesn't work Date: Sun, 23 Jan 2011 00:21:39 +0100 Just for reference: pjd@ solved this issue: http://people.freebsd.org/~pjd/patches/zfs_boot_fixes.patch -- am