From owner-freebsd-fs@FreeBSD.ORG Sun Jul 21 07:11:28 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ABA72913; Sun, 21 Jul 2013 07:11:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 240587C6; Sun, 21 Jul 2013 07:11:27 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6L7BOoD001440; Sun, 21 Jul 2013 10:11:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6L7BOoD001440 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6L7BOQF001439; Sun, 21 Jul 2013 10:11:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 21 Jul 2013 10:11:24 +0300 From: Konstantin Belousov To: Andriy Gapon Subject: Re: Deadlock in nullfs/zfs somewhere Message-ID: <20130721071124.GY5991@kib.kiev.ua> References: <51E7B686.4090509@FreeBSD.org> <20130718112814.GA5991@kib.kiev.ua> <51E7F05A.5020609@FreeBSD.org> <20130718185215.GE5991@kib.kiev.ua> <51E91277.3070309@FreeBSD.org> <20130719103025.GJ5991@kib.kiev.ua> <51E95CDD.7030702@FreeBSD.org> <20130719184243.GM5991@kib.kiev.ua> <51E99477.1030308@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YDTWxoC2E3hrC6hC" Content-Disposition: inline In-Reply-To: <51E99477.1030308@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 07:11:28 -0000 --YDTWxoC2E3hrC6hC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 19, 2013 at 10:33:11PM +0300, Andriy Gapon wrote: > on 19/07/2013 21:42 Konstantin Belousov said the following: > > Then, you cannot use VFS suspension. Or, in other words, you are direc= ted > > to abuse the VFS interface. I assure you that any changes to the inter= face > > would not take into account such abuse and probably break your hack. >=20 > So what would be your recommendation about this problem? > Should we add another flavor of VFS suspension? > The one that would mean "all external accesses to this fs must be put on = hold", > but would not imply "this fs is frozen". Suspension is very complicated as it is. Adding another flavour would multiply the current mess^H^H^H^H collection of subtleties. IMO, the best route is to use the KPI properly, i.e. adding the vn_start_write() braces around the top-level entries in the mutating code paths. --YDTWxoC2E3hrC6hC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR64mcAAoJEJDCuSvBvK1BPpgP/05QbPS6lUQ+FEpuwUx7WyBl ZpnCHn2NmkncxS0CslgHxK2BvdsG11pRByk2Q9pw1BcqIarudf0K9emnNNC5erZs jdkYJIJgXHFwfrJsPP+TZbt6NPoPy27qsRtO1SQ+dvYF29ia+K5GZEB17ABrU3wZ TZkJZBH5fF96TFgb/epGD32V5a+s9cVahBrTHvbldFR1fLCMopXFk/SchuHkOsa+ R8Nr7Vg9zxfHKx91a/QUDJkbK7W+dpYphBaXT/wNQ5D8XISPBzKA115wsoJbXjMx ytPsHAugd9w2+tUJNTIHzJ9LGAPNdXdAzxESncERytDbccNm3s/tdjPlH1aCgjVt OrVAJY0p+XkPcAGpANiGpHGKUHsy3M7H4TDbCu+bV1Jnb25dpAf0GTuCoSiELaKr teMPld/vi4qqNUE77yvS20xbybCiCHH3Wwz/J3dGopjkycxdq6wCK+1Zv7N1uv1c 5rNGvezXQv6kL7fD/hTLS5EvvAsFsRsb1ZABeJfU9H1qOur66/A1J4gJs9y969I8 RE8Te2aKP7ETHMUsL70RZPaSywqjZNMt1BcJWFOJNkeui/so55W1+2k4t3AfDoSs jbZcibwKAE6OGb46w+PFLNPKWFfNWk7cU8MWSYwane9YuMdzQakTG+5YBP/8O6KY a12tyQ+ZH88pJFF6CZ/z =Y0Y6 -----END PGP SIGNATURE----- --YDTWxoC2E3hrC6hC-- From owner-freebsd-fs@FreeBSD.ORG Sun Jul 21 09:37:50 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6B4EA607 for ; Sun, 21 Jul 2013 09:37:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B2FBAE96 for ; Sun, 21 Jul 2013 09:37:49 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA28755; Sun, 21 Jul 2013 12:37:39 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V0q5D-000Jif-MD; Sun, 21 Jul 2013 12:37:39 +0300 Message-ID: <51EBABAB.5040808@FreeBSD.org> Date: Sun, 21 Jul 2013 12:36:43 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Deadlock in nullfs/zfs somewhere References: <51E7B686.4090509@FreeBSD.org> <20130718112814.GA5991@kib.kiev.ua> <51E7F05A.5020609@FreeBSD.org> <20130718185215.GE5991@kib.kiev.ua> <51E91277.3070309@FreeBSD.org> <20130719103025.GJ5991@kib.kiev.ua> <51E95CDD.7030702@FreeBSD.org> <20130719184243.GM5991@kib.kiev.ua> <51E99477.1030308@FreeBSD.org> <20130721071124.GY5991@kib.kiev.ua> In-Reply-To: <20130721071124.GY5991@kib.kiev.ua> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 09:37:50 -0000 on 21/07/2013 10:11 Konstantin Belousov said the following: > On Fri, Jul 19, 2013 at 10:33:11PM +0300, Andriy Gapon wrote: >> on 19/07/2013 21:42 Konstantin Belousov said the following: >>> Then, you cannot use VFS suspension. Or, in other words, you are >>> directed to abuse the VFS interface. I assure you that any changes to >>> the interface would not take into account such abuse and probably break >>> your hack. >> >> So what would be your recommendation about this problem? Should we add >> another flavor of VFS suspension? The one that would mean "all external >> accesses to this fs must be put on hold", but would not imply "this fs is >> frozen". > > Suspension is very complicated as it is. Adding another flavour would > multiply the current mess^H^H^H^H collection of subtleties. IMO, the best > route is to use the KPI properly, i.e. adding the vn_start_write() braces > around the top-level entries in the mutating code paths. > So how will this help with doing a rollback in the thread that does the following? vfs_write_suspend zfs rollback vfs_write_resume -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sun Jul 21 16:19:09 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 14844C93; Sun, 21 Jul 2013 16:19:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id AB55F8C7; Sun, 21 Jul 2013 16:19:08 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6LGIsd7016045; Sun, 21 Jul 2013 19:18:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6LGIsd7016045 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6LGIsWw016044; Sun, 21 Jul 2013 19:18:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 21 Jul 2013 19:18:54 +0300 From: Konstantin Belousov To: Andriy Gapon Subject: Re: Deadlock in nullfs/zfs somewhere Message-ID: <20130721161854.GC5991@kib.kiev.ua> References: <20130718112814.GA5991@kib.kiev.ua> <51E7F05A.5020609@FreeBSD.org> <20130718185215.GE5991@kib.kiev.ua> <51E91277.3070309@FreeBSD.org> <20130719103025.GJ5991@kib.kiev.ua> <51E95CDD.7030702@FreeBSD.org> <20130719184243.GM5991@kib.kiev.ua> <51E99477.1030308@FreeBSD.org> <20130721071124.GY5991@kib.kiev.ua> <51EBABAB.5040808@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4tkssvp36SW1tyIS" Content-Disposition: inline In-Reply-To: <51EBABAB.5040808@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 16:19:09 -0000 --4tkssvp36SW1tyIS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 21, 2013 at 12:36:43PM +0300, Andriy Gapon wrote: > on 21/07/2013 10:11 Konstantin Belousov said the following: > > On Fri, Jul 19, 2013 at 10:33:11PM +0300, Andriy Gapon wrote: > >> on 19/07/2013 21:42 Konstantin Belousov said the following: > >>> Then, you cannot use VFS suspension. Or, in other words, you are > >>> directed to abuse the VFS interface. I assure you that any changes to > >>> the interface would not take into account such abuse and probably bre= ak > >>> your hack. > >>=20 > >> So what would be your recommendation about this problem? Should we add > >> another flavor of VFS suspension? The one that would mean "all external > >> accesses to this fs must be put on hold", but would not imply "this fs= is > >> frozen". > >=20 > > Suspension is very complicated as it is. Adding another flavour would= =20 > > multiply the current mess^H^H^H^H collection of subtleties. IMO, the be= st > > route is to use the KPI properly, i.e. adding the vn_start_write() brac= es > > around the top-level entries in the mutating code paths. > >=20 >=20 > So how will this help with doing a rollback in the thread that does the f= ollowing? >=20 > vfs_write_suspend > zfs rollback > vfs_write_resume I have no idea. I am answering to your proposal from the different angle, as a person who spent some efforts maintaining VFS interfaces. I object against interface abuse, and point out a fragility of the approach. --4tkssvp36SW1tyIS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR7AnuAAoJEJDCuSvBvK1BHEwQAIkn10EF7RpCqfe6DDOLA8/N eZc0Ij5YvlH6qCsr843TWdeKP5Kcs4ygRoEL2oJj2gTzVaFxsECe0OmCHPkowXTV 6IUWG/zUOZWNfIas2s+Rra4aTyeOMMk4Ud2FVv0InISVCmEGiVkPGnUHpu3iNxvb X6doIySKaP7m2JzvS7zcFLh1Ju0VZdj5f/C3jjEes1qv5KTaC9yxxGlrWHk6Bx26 X9vPLTX64lR8gQsHpGWWFwc+aRuxXShjoxoH6t1J2RVP1g1RJca7HdRioc/EMQQ4 tXQwMmic+pM+7LMCDAf8jKVFAe/UKqKgYpITiKOiNht4MufSUsbYBH2hzgCANlp3 jUfospcMKqz/WPq48r+o+THs+BF5fIPIu0bCi+zpodh1hr1ZiohbOMcZ5biL452P h3SNVQ8dK+hloHpI+XhYtpl4YY3ge7wDXnbrl7nu58EfRFy7EodQczZB33k+xhbf BEXVKK/52MV4rczRW74LLsMk8i2j0QAiVFpfzU4nDlkrCLkYdV0X9+u4TwH/7i2H X51v3aLzWfX9Uiz+yHdunWp+AxU5+iLWb31l38fGTf/LyiJYU1zeWiSxq0nFwiPk 9Gf5ODtvH3hrGv4UVq5yGXwReuTGXeFlIFalHL8WJ2QzBLFiRRjkX/EJBeFBLG8G 4M6Saa9SD80VlX4UujTJ =NjnG -----END PGP SIGNATURE----- --4tkssvp36SW1tyIS-- From owner-freebsd-fs@FreeBSD.ORG Mon Jul 22 07:30:40 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9BF07ADA; Mon, 22 Jul 2013 07:30:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 58C7E2680; Mon, 22 Jul 2013 07:30:39 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA09015; Mon, 22 Jul 2013 10:30:37 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V1AZp-000OET-5E; Mon, 22 Jul 2013 10:30:37 +0300 Message-ID: <51ECDF64.2020704@FreeBSD.org> Date: Mon, 22 Jul 2013 10:29:40 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current , freebsd-fs@FreeBSD.org Subject: Re: r253070 and "disappearing" zpool References: <20130710180548.GA2151@glenbarber.us> In-Reply-To: <20130710180548.GA2151@glenbarber.us> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Glen Barber X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 07:30:40 -0000 [turning this into a public discussion with Glen's permission] on 10/07/2013 21:05 Glen Barber said the following: > Hi, > > My setup is like this: > > root@nucleus:/usr/src # zpool list > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > zboot0 9.94G 379M 9.57G 3% 1.00x ONLINE - > zroot0 159G 113G 46.2G 70% 1.00x ONLINE - > > root@nucleus:/usr/src # zpool get bootfs > NAME PROPERTY VALUE SOURCE > zboot0 bootfs - default > zroot0 bootfs - default > > root@nucleus:/usr/src # zfs list zboot0 > NAME USED AVAIL REFER MOUNTPOINT > zboot0 379M 9.41G 281M /bootdir > > root@nucleus:/usr/src # zfs list zroot0 > NAME USED AVAIL REFER MOUNTPOINT > zroot0 113G 43.7G 147M / > > 'zroot0' is a GELI-backed pool, so I have this to fix the boot process: > > root@nucleus:/usr/src # ll /boot > lrwxr-xr-x 1 root wheel 12 Aug 25 2012 /boot@ -> bootdir/boot > > I upgraded from head/ on July 1 to r253159, and when I rebooted the > system, I could correctly boot from the "/bootdir/boot". Once I enter > the GELI passphrase, "/" (from zroot0) is mounted. Normally, everything > would be okay at that point, but since the upgrade, "/bootdir/boot" > disappears because the zboot0 pool is not imported as it was before. > > Any thoughts? I think that this setup (on ZFS level) is quite untypical, although not impossible on FreeBSD (and perhaps only FreeBSD). It's untypical because you have separate boot pool (where loader, loader.conf and kernel are taken from) and root pool (where "/" is mounted from). There is this "magic" zpool.cache file that essentially tells what pools should be automatically imported. On FreeBSD this file lives in /boot/zfs directory while originally (in Solaris and its descendants) its home is /etc/zfs. Until recently FreeBSD could use only zpool.cache from a boot pool and, in fact, if a root pool was different from a boot pool the root pool had to be in zpool.cache. I changed things a little bit and now a root pool does not have to be in zpool.cache. Also, now zpool.cache is taken from the root pool, or to be more precise from a root filesystem (whatever happens to be /boot/zfs/zpool.cache after "/" is mounted). I am considering if perhaps now we should move zpool.cache back to /etc/zfs/. So, I see three ways of resolving the problem that my changes caused for your configuration. 1. [the easiest] Put zpool.cache loading instructions that used to be in defaults/loader.conf into your loader.conf. This way everything should work as before -- zpool.cache would be loaded from your boot pool. 2. Somehow (I don't want to go into any technical details here) arrange that your root pool has /boot/zfs/zpool.cache that describes your boot pool. This is probably hard given that your /boot is a symlink at the moment. This probably would be easier to achieve if zpool.cache lived in /etc/zfs. 3. [my favorite] Remove an artificial difference between your boot and root pools, so that they are a single root+boot pool (as zfs gods intended). As far as I understand your setup, you use GELI to protect some sensitive data. Apparently your kernel is not sensitive data, so I wonder if your /bin/sh or /sbin/init are really sensitive either. So perhaps you can arrange your unencrypted pool to hold all of the base system (boot + root) and put all your truly sensitive filesystems (like e.g. /home or /var/data or /opt/xyz) onto your encrypted pool. ZFS is really flexible, you can use mountpoint and canmount properties to place your filesystems from same or different pools into whatever file namespace hierarchy you desire. Remember that your filesystem hierarchy in the mount namespace does not always have to be the same as your ZFS dataset hierarchy. I hope that this makes sense to you. If you have any additional questions, please do not hesitate. P.S. ZFS/FreeBSD boot process is extremely flexible. For example zfsboot can take zfsloader from pool1/fsA, zfsloader can boot kernel from pool2/fsB and kernel can mount / from pool3/fsC. Of these 3 filesystems from where should zpool.cache be taken? My firm opinion is that it should be taken from / (pool3/fsC in the example above). Because it is the root filesystem that defines what a system is going to do ultimately: what daemons are started, with what configurations, etc. And thus it should also determine what pools to auto-import. We can say that zpool.cache is analogous to /etc/fstab in this respect. So I understand that my change causes a problem for a setup like yours, but I believe that the change is correct. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Mon Jul 22 11:06:44 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E564D448 for ; Mon, 22 Jul 2013 11:06:43 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D5E422496 for ; Mon, 22 Jul 2013 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6MB6hTi053671 for ; Mon, 22 Jul 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6MB6hd4053669 for freebsd-fs@FreeBSD.org; Mon, 22 Jul 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Jul 2013 11:06:43 GMT Message-Id: <201307221106.r6MB6hd4053669@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 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 11:06:44 -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/180678 fs [NFS] succesfully exported filesystems being reported o kern/180438 fs [smbfs] [patch] mount_smbfs fails on arm because of wr p kern/180236 fs [zfs] [nullfs] Leakage free space using ZFS with nullf o kern/178854 fs [ufs] FreeBSD kernel crash in UFS o kern/178713 fs [nfs] [patch] Correct WebNFS support in NFS server and o kern/178412 fs [smbfs] Coredump when smbfs mounted o kern/178388 fs [zfs] [patch] allow up to 8MB recordsize o kern/178349 fs [zfs] zfs scrub on deduped data could be much less see o kern/178329 fs [zfs] extended attributes leak o kern/178238 fs [nullfs] nullfs don't release i-nodes on unlink. f kern/178231 fs [nfs] 8.3 nfsv4 client reports "nfsv4 client/server pr o kern/178103 fs [kernel] [nfs] [patch] Correct support of index files o kern/177985 fs [zfs] disk usage problem when copying from one zfs dat o kern/177971 fs [nfs] FreeBSD 9.1 nfs client dirlist problem w/ nfsv3, o kern/177966 fs [zfs] resilver completes but subsequent scrub reports o kern/177658 fs [ufs] FreeBSD panics after get full filesystem with uf o kern/177536 fs [zfs] zfs livelock (deadlock) with high write-to-disk o kern/177445 fs [hast] HAST panic o kern/177240 fs [zfs] zpool import failed with state UNAVAIL but all d o kern/176978 fs [zfs] [panic] zfs send -D causes "panic: System call i o kern/176857 fs [softupdates] [panic] 9.1-RELEASE/amd64/GENERIC panic o bin/176253 fs zpool(8): zfs pool indentation is misleading/wrong o kern/176141 fs [zfs] sharesmb=on makes errors for sharenfs, and still o kern/175950 fs [zfs] Possible deadlock in zfs after long uptime o kern/175897 fs [zfs] operations on readonly zpool hang o kern/175449 fs [unionfs] unionfs and devfs misbehaviour o kern/175179 fs [zfs] ZFS may attach wrong device on move o kern/175071 fs [ufs] [panic] softdep_deallocate_dependencies: unrecov o kern/174372 fs [zfs] Pagefault appears to be related to ZFS o kern/174315 fs [zfs] chflags uchg not supported o kern/174310 fs [zfs] root point mounting broken on CURRENT with multi o kern/174279 fs [ufs] UFS2-SU+J journal and filesystem corruption o kern/173830 fs [zfs] Brain-dead simple change to ZFS error descriptio o kern/173718 fs [zfs] phantom directory in zraid2 pool f kern/173657 fs [nfs] strange UID map with nfsuserd o kern/173363 fs [zfs] [panic] Panic on 'zpool replace' on readonly poo o kern/173136 fs [unionfs] mounting above the NFS read-only share panic o kern/172942 fs [smbfs] Unmounting a smb mount when the server became o kern/172348 fs [unionfs] umount -f of filesystem in use with readonly o kern/172334 fs [unionfs] unionfs permits recursive union mounts; caus o kern/171626 fs [tmpfs] tmpfs should be noisier when the requested siz o kern/171415 fs [zfs] zfs recv fails with "cannot receive incremental o kern/170945 fs [gpt] disk layout not portable between direct connect o bin/170778 fs [zfs] [panic] FreeBSD panics randomly o kern/170680 fs [nfs] Multiple NFS Client bug in the FreeBSD 7.4-RELEA o kern/170497 fs [xfs][panic] kernel will panic whenever I ls a mounted o kern/169945 fs [zfs] [panic] Kernel panic while importing zpool (afte o kern/169480 fs [zfs] ZFS stalls on heavy I/O o kern/169398 fs [zfs] Can't remove file with permanent error o kern/169339 fs panic while " : > /etc/123" o kern/169319 fs [zfs] zfs resilver can't complete o kern/168947 fs [nfs] [zfs] .zfs/snapshot directory is messed up when o kern/168942 fs [nfs] [hang] nfsd hangs after being restarted (not -HU o kern/168158 fs [zfs] incorrect parsing of sharenfs options in zfs (fs o kern/167979 fs [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste o kern/167977 fs [smbfs] mount_smbfs results are differ when utf-8 or U o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165521 fs [zfs] [hang] livelock on 1 Gig of RAM with zfs when 31 o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161864 fs [ufs] removing journaling from UFS partition fails on o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic f kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located 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/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 bin/153142 fs [zfs] ls -l outputs `ls: ./.zfs: Operation not support o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small 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 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/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/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa 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 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/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/145750 fs [unionfs] [hang] unionfs locks the machine 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 f 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 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/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/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141950 fs [unionfs] [lor] ufs/unionfs/ufs Lock order reversal 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/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/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/139407 fs [smbfs] [panic] smb mount causes system crash if remot 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/137588 fs [unionfs] [lor] LOR nfs/ufs/nfs 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 p kern/133174 fs [msdosfs] [patch] msdosfs must support multibyte inter 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/126973 fs [unionfs] [hang] System hang with unionfs and init chr o kern/126553 fs [unionfs] unionfs move directory problem 2 (files appe 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 bin/123574 fs [unionfs] df(1) -t option destroys info for unionfs (a 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 kern/121385 fs [unionfs] unionfs cross mount -> kernel panic o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha 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 kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance 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/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using 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 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/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 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 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/67326 fs [msdosfs] crash after attempt to mount write protected 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/36566 fs [smbfs] System reboot with dead smb mount and umount 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 o kern/9619 fs [nfs] Restarting mountd kills existing mounts 327 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Jul 22 12:28:54 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7CD13560; Mon, 22 Jul 2013 12:28:54 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4312F2AFF; Mon, 22 Jul 2013 12:28:53 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id r6MCSqTI029435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 22 Jul 2013 07:28:52 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.02.0309.002; Mon, 22 Jul 2013 07:28:43 -0500 From: "Teske, Devin" To: Andriy Gapon Subject: Re: r253070 and "disappearing" zpool Thread-Topic: r253070 and "disappearing" zpool Thread-Index: AQHOhq1kEkFm6CmVtUilt1UjZinLKZlw9HiA Date: Mon, 22 Jul 2013 12:28:43 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FD4633@ltcfiswmsgmb21> References: <20130710180548.GA2151@glenbarber.us> <51ECDF64.2020704@FreeBSD.org> In-Reply-To: <51ECDF64.2020704@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-22_02:2013-07-19,2013-07-22,1970-01-01 signatures=0 Cc: "freebsd-fs@freebsd.org" , Glen Barber , FreeBSD Current , Devin Teske X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 12:28:54 -0000 On Jul 22, 2013, at 12:29 AM, Andriy Gapon wrote: >=20 > [turning this into a public discussion with Glen's permission] >=20 > on 10/07/2013 21:05 Glen Barber said the following: >> Hi, >>=20 >> My setup is like this: >>=20 >> root@nucleus:/usr/src # zpool list >> NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT >> zboot0 9.94G 379M 9.57G 3% 1.00x ONLINE - >> zroot0 159G 113G 46.2G 70% 1.00x ONLINE - >>=20 >> root@nucleus:/usr/src # zpool get bootfs >> NAME PROPERTY VALUE SOURCE >> zboot0 bootfs - default >> zroot0 bootfs - default >>=20 >> root@nucleus:/usr/src # zfs list zboot0 >> NAME USED AVAIL REFER MOUNTPOINT >> zboot0 379M 9.41G 281M /bootdir >>=20 >> root@nucleus:/usr/src # zfs list zroot0 >> NAME USED AVAIL REFER MOUNTPOINT >> zroot0 113G 43.7G 147M / >>=20 >> 'zroot0' is a GELI-backed pool, so I have this to fix the boot process: >>=20 >> root@nucleus:/usr/src # ll /boot >> lrwxr-xr-x 1 root wheel 12 Aug 25 2012 /boot@ -> bootdir/boot >>=20 >> I upgraded from head/ on July 1 to r253159, and when I rebooted the >> system, I could correctly boot from the "/bootdir/boot". Once I enter >> the GELI passphrase, "/" (from zroot0) is mounted. Normally, everything >> would be okay at that point, but since the upgrade, "/bootdir/boot" >> disappears because the zboot0 pool is not imported as it was before. >>=20 >> Any thoughts? >=20 > I think that this setup (on ZFS level) is quite untypical, although not > impossible on FreeBSD (and perhaps only FreeBSD). > It's untypical because you have separate boot pool (where loader, loader.= conf > and kernel are taken from) and root pool (where "/" is mounted from). >=20 > There is this "magic" zpool.cache file that essentially tells what pools = should > be automatically imported. On FreeBSD this file lives in /boot/zfs direc= tory > while originally (in Solaris and its descendants) its home is /etc/zfs. >=20 > Until recently FreeBSD could use only zpool.cache from a boot pool and, i= n fact, > if a root pool was different from a boot pool the root pool had to be in > zpool.cache. > I changed things a little bit and now a root pool does not have to be in > zpool.cache. Also, now zpool.cache is taken from the root > pool, or to be more precise from a root filesystem (whatever happens to be > /boot/zfs/zpool.cache after "/" is mounted). I am considering if perhaps= now we > should move zpool.cache back to /etc/zfs/. >=20 > So, I see three ways of resolving the problem that my changes caused for = your > configuration. >=20 > 1. [the easiest] Put zpool.cache loading instructions that used to be in > defaults/loader.conf into your loader.conf. This way everything should w= ork as > before -- zpool.cache would be loaded from your boot pool. >=20 > 2. Somehow (I don't want to go into any technical details here) arrange t= hat > your root pool has /boot/zfs/zpool.cache that describes your boot pool. = This is > probably hard given that your /boot is a symlink at the moment. This pro= bably > would be easier to achieve if zpool.cache lived in /etc/zfs. >=20 > 3. [my favorite] Remove an artificial difference between your boot and r= oot > pools, so that they are a single root+boot pool (as zfs gods intended). = As far > as I understand your setup, you use GELI to protect some sensitive data. > Apparently your kernel is not sensitive data, so I wonder if your /bin/sh= or > /sbin/init are really sensitive either. > So perhaps you can arrange your unencrypted pool to hold all of the base = system > (boot + root) and put all your truly sensitive filesystems (like e.g. /ho= me or > /var/data or /opt/xyz) onto your encrypted pool. > ZFS is really flexible, you can use mountpoint and canmount properties to= place > your filesystems from same or different pools into whatever file namespace > hierarchy you desire. Remember that your filesystem hierarchy in the mou= nt > namespace does not always have to be the same as your ZFS dataset hierarc= hy. >=20 > I hope that this makes sense to you. > If you have any additional questions, please do not hesitate. >=20 > P.S. > ZFS/FreeBSD boot process is extremely flexible. For example zfsboot can = take > zfsloader from pool1/fsA, zfsloader can boot kernel from pool2/fsB and ke= rnel > can mount / from pool3/fsC. Of these 3 filesystems from where should > zpool.cache be taken? > My firm opinion is that it should be taken from / (pool3/fsC in the examp= le > above). Because it is the root filesystem that defines what a system is = going > to do ultimately: what daemons are started, with what configurations, etc. > And thus it should also determine what pools to auto-import. > We can say that zpool.cache is analogous to /etc/fstab in this respect. >=20 > So I understand that my change causes a problem for a setup like yours, b= ut I > believe that the change is correct. >=20 +1 for zpool.cache on / (pool3/fsC in last example) --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-fs@FreeBSD.ORG Mon Jul 22 14:30:36 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 61B5CA31; Mon, 22 Jul 2013 14:30:36 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 31AA921BA; Mon, 22 Jul 2013 14:30:36 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id w11so6817515pde.23 for ; Mon, 22 Jul 2013 07:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version :x-mailer; bh=9XxWkVPd6fDXbvPO/INfpwth5IfMmz7zGtzAg/3wDt0=; b=RRhcgt4m1cSaW8S2r6SR/VGumOpgsIt56v+VnQ3vTNMDBRLTS9chbLpu7RV/RJUuF1 E4HWe6smLZL3Ds6N36E20QtqUveDHXg5MW/iBNUuvDwYdHmv6b4K+k/LkAVMuaHkP9Fi X//OiAV41YgX3UxKGBeHYu6v4zQxtUf/vPIarPZB87nr0yowcwPWdftvBWIcsUINNRoK 0xfuLI233ycIRZTuMPKfVOnh42hmq0KUaCRFlOujGYTc36P3CNefBtV6bp0pw7Q0buuk BqWY0DyLpU9oQD72eJQxElwORsvH0hE/5fwd4i5YXggM1BXhz1CjObwLhx466AsHonKy Nw2Q== X-Received: by 10.68.211.233 with SMTP id nf9mr28509074pbc.26.1374503435840; Mon, 22 Jul 2013 07:30:35 -0700 (PDT) Received: from [192.168.20.5] (c-98-203-241-95.hsd1.wa.comcast.net. [98.203.241.95]) by mx.google.com with ESMTPSA id e7sm23028461pbc.11.2013.07.22.07.30.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 07:30:35 -0700 (PDT) From: Garrett Cooper Content-Type: multipart/mixed; boundary="Apple-Mail=_4FC5EB36-4DBF-46B0-BEE5-66FA9F01B57F" Subject: [REGRESSION] Root zpool mounting broken between 06/30/2013 and 07/21/2013 when PS/2 support compiled into the kernel Date: Mon, 22 Jul 2013 07:30:32 -0700 Message-Id: <78424E5D-4EB2-4462-A190-D0AC97136790@gmail.com> To: freebsd-fs@freebsd.org, freebsd-stable@FreeBSD.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 14:30:36 -0000 --Apple-Mail=_4FC5EB36-4DBF-46B0-BEE5-66FA9F01B57F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have a KERNCONF that previously had PS/2 support compiled into the = kernel. If I comment out the following lines like so: # atkbdc0 controls both the keyboard and the PS/2 mouse #device atkbdc # AT keyboard controller #device atkbd # AT keyboard then I'm able to mount root again (it was failing with ENOXDEV). The working kernel was as follows: $ strings /boot/kernel.WORKING/kernel | grep -B 2 -A 2 BAYONETTA @(#)FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 = gcooper@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-st= able-9/sys/BAYONETTA gcc version 4.2.1 20070831 patched [FreeBSD] FreeBSD 9.1-STABLE BAYONETTA $ cd /usr/src; git log 0304216 commit 03042167f73c213732b44218a24d8e1bbea00f8c Merge: 2edcad2 974abfb Author: Garrett Cooper Date: Mon Jun 24 19:00:45 2013 -0700 Merge remote-tracking branch 'upstream/stable/9' into stable/9 The working kernel [with atkbdc] was as follows: FreeBSD bayonetta.local 9.2-BETA1 FreeBSD 9.2-BETA1 #12 r+c178034: Sun = Jul 21 20:19:38 PDT 2013 = root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stabl= e-9/sys/BAYONETTA amd64 $ git log c178034 commit c17803445f4ffb97e1a46a1be5f7ea04692793f0 Author: avg Date: Tue Jul 9 08:30:31 2013 +0000 zfsboottest.sh: remove checks for things that are not strictly = required =20 MFC after: 10 days (Yes, I had to backport some things because they are busted on stable/9 = due to other incomplete/missing MFCs). I can test out patches, but I don't have time to bisect the actual = commit that caused the failure. That being said my intuition says it's = this commit should be looked at first: commit 28f961058b0667841d7e9d8639bfd02ed8689faa Author: jhb Date: Wed Jul 17 14:04:18 2013 +0000 MFC 252576: Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bridges. = If we are probing a PCI-PCI bridge it is because we found one by = enumerating the devices on a PCI bus, so the bridge is definitely present. A = few BIOSes report incorrect status (_STA) for some bridges that claimed = they were not present when in fact they were. =20 While here, move this check earlier for Host-PCI bridges so attach = fails before doing any work that needs to be torn down. =20 PR: kern/91594 Approved by: re (marius) More data spew follows. Thanks, -Garrett --Apple-Mail=_4FC5EB36-4DBF-46B0-BEE5-66FA9F01B57F Content-Disposition: attachment; filename=diagnostic-noise.txt Content-Type: text/plain; x-unix-mode=0644; name="diagnostic-noise.txt" Content-Transfer-Encoding: quoted-printable hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x836b1043 = chip=3D0x34058086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub to ESI Port' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:0:1:0: class=3D0x060400 card=3D0x836b1043 = chip=3D0x34088086 rev=3D0x13 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub PCI Express Root Port 1' class =3D bridge subclass =3D PCI-PCI pcib4@pci0:0:3:0: class=3D0x060400 card=3D0x836b1043 = chip=3D0x340a8086 rev=3D0x13 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub PCI Express Root Port 3' class =3D bridge subclass =3D PCI-PCI pcib5@pci0:0:7:0: class=3D0x060400 card=3D0x836b1043 = chip=3D0x340e8086 rev=3D0x13 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub PCI Express Root Port 7' class =3D bridge subclass =3D PCI-PCI none0@pci0:0:20:0: class=3D0x080000 card=3D0x00000000 = chip=3D0x342e8086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub System Management Registers' class =3D base peripheral subclass =3D interrupt controller none1@pci0:0:20:1: class=3D0x080000 card=3D0x00000000 = chip=3D0x34228086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub GPIO and Scratch Pad = Registers' class =3D base peripheral subclass =3D interrupt controller none2@pci0:0:20:2: class=3D0x080000 card=3D0x00000000 = chip=3D0x34238086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub Control Status and RAS = Registers' class =3D base peripheral subclass =3D interrupt controller none3@pci0:0:20:3: class=3D0x080000 card=3D0x00000000 = chip=3D0x34388086 rev=3D0x13 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '5520/5500/X58 I/O Hub Throttle Registers' class =3D base peripheral subclass =3D interrupt controller uhci0@pci0:0:26:0: class=3D0x0c0300 card=3D0x82d41043 = chip=3D0x3a378086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB uhci1@pci0:0:26:1: class=3D0x0c0300 card=3D0x82d41043 = chip=3D0x3a388086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB uhci2@pci0:0:26:2: class=3D0x0c0300 card=3D0x82d41043 = chip=3D0x3a398086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB ehci0@pci0:0:26:7: class=3D0x0c0320 card=3D0x82d41043 = chip=3D0x3a3c8086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB2 EHCI Controller' class =3D serial bus subclass =3D USB pcib6@pci0:0:28:0: class=3D0x060400 card=3D0x82ea1043 = chip=3D0x3a408086 rev=3D0x00 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) PCI Express Root Port 1' class =3D bridge subclass =3D PCI-PCI pcib7@pci0:0:28:1: class=3D0x060400 card=3D0x82ea1043 = chip=3D0x3a428086 rev=3D0x00 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) PCI Express Port 2' class =3D bridge subclass =3D PCI-PCI uhci3@pci0:0:29:0: class=3D0x0c0300 card=3D0x82d41043 = chip=3D0x3a348086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB uhci4@pci0:0:29:1: class=3D0x0c0300 card=3D0x82d41043 = chip=3D0x3a358086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB uhci5@pci0:0:29:2: class=3D0x0c0300 card=3D0x82d41043 = chip=3D0x3a368086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB UHCI Controller' class =3D serial bus subclass =3D USB ehci1@pci0:0:29:7: class=3D0x0c0320 card=3D0x82d41043 = chip=3D0x3a3a8086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) USB2 EHCI Controller' class =3D serial bus subclass =3D USB pcib8@pci0:0:30:0: class=3D0x060401 card=3D0x82d41043 = chip=3D0x244e8086 rev=3D0x90 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801 PCI Bridge' class =3D bridge subclass =3D PCI-PCI isab0@pci0:0:31:0: class=3D0x060100 card=3D0x82d41043 = chip=3D0x3a168086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JIR (ICH10R) LPC Interface Controller' class =3D bridge subclass =3D PCI-ISA ahci0@pci0:0:31:2: class=3D0x010601 card=3D0x82d41043 = chip=3D0x3a228086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) SATA AHCI Controller' class =3D mass storage subclass =3D SATA ichsmb0@pci0:0:31:3: class=3D0x0c0500 card=3D0x82d41043 = chip=3D0x3a308086 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801JI (ICH10 Family) SMBus Controller' class =3D serial bus subclass =3D SMBus pcib2@pci0:1:0:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x01251033 rev=3D0x06 hdr=3D0x01 vendor =3D 'NEC Corporation' device =3D 'uPD720400 PCI Express - PCI/PCI-X Bridge' class =3D bridge subclass =3D PCI-PCI pcib3@pci0:1:0:1: class=3D0x060400 card=3D0x00000000 = chip=3D0x01251033 rev=3D0x06 hdr=3D0x01 vendor =3D 'NEC Corporation' device =3D 'uPD720400 PCI Express - PCI/PCI-X Bridge' class =3D bridge subclass =3D PCI-PCI mfi0@pci0:4:0:0: class=3D0x010400 card=3D0x92411000 = chip=3D0x00731000 rev=3D0x03 hdr=3D0x00 vendor =3D 'LSI Logic / Symbios Logic' device =3D 'MegaRAID SAS 9240' class =3D mass storage subclass =3D RAID vgapci0@pci0:5:0:0: class=3D0x030000 card=3D0xc9543842 = chip=3D0x064010de rev=3D0xa1 hdr=3D0x00 vendor =3D 'nVidia Corporation' device =3D 'G96 [GeForce 9500 GT]' class =3D display subclass =3D VGA re0@pci0:6:0:0: class=3D0x020000 card=3D0x83671043 chip=3D0x816810ec = rev=3D0x02 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8111/8168B PCI Express Gigabit Ethernet = controller' class =3D network subclass =3D ethernet hostb1@pci0:255:0:0: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c418086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 QuickPath Architecture Generic = Non-Core Registers' class =3D bridge subclass =3D HOST-PCI hostb2@pci0:255:0:1: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c018086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 QuickPath Architecture System = Address Decoder' class =3D bridge subclass =3D HOST-PCI hostb3@pci0:255:2:0: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c108086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 QPI Link 0' class =3D bridge subclass =3D HOST-PCI hostb4@pci0:255:2:1: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c118086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 QPI Physical 0' class =3D bridge subclass =3D HOST-PCI hostb5@pci0:255:3:0: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c188086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller' class =3D bridge subclass =3D HOST-PCI hostb6@pci0:255:3:1: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c198086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Target Address Decoder' class =3D bridge subclass =3D HOST-PCI hostb7@pci0:255:3:4: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c1c8086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller Test = Registers' class =3D bridge subclass =3D HOST-PCI hostb8@pci0:255:4:0: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c208086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 0 Control Registers' class =3D bridge subclass =3D HOST-PCI hostb9@pci0:255:4:1: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c218086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 0 Address Registers' class =3D bridge subclass =3D HOST-PCI hostb10@pci0:255:4:2: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c228086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 0 Rank Registers' class =3D bridge subclass =3D HOST-PCI hostb11@pci0:255:4:3: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c238086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 0 Thermal Control Registers' class =3D bridge subclass =3D HOST-PCI hostb12@pci0:255:5:0: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c288086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 1 Control Registers' class =3D bridge subclass =3D HOST-PCI hostb13@pci0:255:5:1: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c298086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 1 Address Registers' class =3D bridge subclass =3D HOST-PCI hostb14@pci0:255:5:2: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c2a8086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 1 Rank Registers' class =3D bridge subclass =3D HOST-PCI hostb15@pci0:255:5:3: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c2b8086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 1 Thermal Control Registers' class =3D bridge subclass =3D HOST-PCI hostb16@pci0:255:6:0: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c308086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 2 Control Registers' class =3D bridge subclass =3D HOST-PCI hostb17@pci0:255:6:1: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c318086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 2 Address Registers' class =3D bridge subclass =3D HOST-PCI hostb18@pci0:255:6:2: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c328086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 2 Rank Registers' class =3D bridge subclass =3D HOST-PCI hostb19@pci0:255:6:3: class=3D0x060000 card=3D0x80868086 = chip=3D0x2c338086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon 5500/Core i7 Integrated Memory Controller = Channel 2 Thermal Control Registers' class =3D bridge subclass =3D HOST-PCI # dmidecode 2.11 SMBIOS 2.5 present. 77 structures occupying 2896 bytes. Table at 0x000F0700. Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: 1205 =20 Release Date: 09/24/2010 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 2048 kB Characteristics: ISA is supported PCI is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported LS-120 boot is supported ATAPI Zip drive boot is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 8.15 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: System manufacturer Product Name: System Product Name Version: System Version Serial Number: System Serial Number UUID: 6069001E-8C00-00BD-6E33-E0CB4E01476B Wake-up Type: Power Switch SKU Number: To Be Filled By O.E.M. Family: To Be Filled By O.E.M. Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: P6T WS PRO Version: Rev 1.xx Serial Number: 102642390000140 Asset Tag: To Be Filled By O.E.M. Features: Board is a hosting board Board is replaceable Location In Chassis: To Be Filled By O.E.M. Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: Chassis Manufacture Type: Desktop Lock: Not Present Version: Chassis Version Serial Number: Chassis Serial Number Asset Tag: Asset-1234567890 Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x00000001 Height: Unspecified Number Of Power Cords: 1 Contained Elements: 0 Handle 0x0004, DMI type 4, 40 bytes Processor Information Socket Designation: LGA1366 Type: Central Processor Family: Xeon Manufacturer: Intel =20 ID: A5 06 01 00 FF FB EB BF Signature: Type 0, Family 6, Model 26, Stepping 5 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Intel(R) Xeon(R) CPU W3520 @ 2.67GHz =20 Voltage: 1.2 V External Clock: 133 MHz Max Speed: 2666 MHz Current Speed: 2666 MHz Status: Populated, Enabled Upgrade: Other L1 Cache Handle: 0x0005 L2 Cache Handle: 0x0006 L3 Cache Handle: 0x0007 Serial Number: To Be Filled By O.E.M. Asset Tag: To Be Filled By O.E.M. Part Number: To Be Filled By O.E.M. Core Count: 4 Core Enabled: 4 Thread Count: 8 Characteristics: 64-bit capable Handle 0x0005, DMI type 7, 19 bytes Cache Information Socket Designation: L1-Cache Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Through Location: Internal Installed Size: 256 kB Maximum Size: 256 kB Supported SRAM Types: Other Installed SRAM Type: Other Speed: Unknown Error Correction Type: Parity System Type: Instruction Associativity: 4-way Set-associative Handle 0x0006, DMI type 7, 19 bytes Cache Information Socket Designation: L2-Cache Configuration: Enabled, Not Socketed, Level 2 Operational Mode: Write Through Location: Internal Installed Size: 1024 kB Maximum Size: 1024 kB Supported SRAM Types: Other Installed SRAM Type: Other Speed: Unknown Error Correction Type: Single-bit ECC System Type: Unified Associativity: 8-way Set-associative Handle 0x0007, DMI type 7, 19 bytes Cache Information Socket Designation: L3-Cache Configuration: Enabled, Not Socketed, Level 3 Operational Mode: Write Back Location: Internal Installed Size: 8192 kB Maximum Size: 8192 kB Supported SRAM Types: Other Installed SRAM Type: Other Speed: Unknown Error Correction Type: Single-bit ECC System Type: Unified Associativity: 16-way Set-associative Handle 0x0008, DMI type 5, 28 bytes Memory Controller Information Error Detecting Method: 64-bit ECC Error Correcting Capabilities: None Supported Interleave: One-way Interleave Current Interleave: One-way Interleave Maximum Memory Module Size: 4096 MB Maximum Total Memory Size: 24576 MB Supported Speeds: 70 ns 60 ns Supported Memory Types: DIMM SDRAM Memory Module Voltage: 3.3 V Associated Memory Slots: 6 0x0009 0x000A 0x000B 0x000C 0x000D 0x000E Enabled Error Correcting Capabilities: None Handle 0x0009, DMI type 6, 12 bytes Memory Module Information Socket Designation: DIMM0 Bank Connections: 1 Current Speed: 1 ns Type: DIMM Installed Size: 2048 MB (Single-bank Connection) Enabled Size: 2048 MB (Single-bank Connection) Error Status: OK Handle 0x000A, DMI type 6, 12 bytes Memory Module Information Socket Designation: DIMM1 Bank Connections: 2 Current Speed: 1 ns Type: DIMM Installed Size: 2048 MB (Single-bank Connection) Enabled Size: 2048 MB (Single-bank Connection) Error Status: OK Handle 0x000B, DMI type 6, 12 bytes Memory Module Information Socket Designation: DIMM2 Bank Connections: 3 Current Speed: 1 ns Type: DIMM Installed Size: 2048 MB (Single-bank Connection) Enabled Size: 2048 MB (Single-bank Connection) Error Status: OK Handle 0x000C, DMI type 6, 12 bytes Memory Module Information Socket Designation: DIMM3 Bank Connections: 4 Current Speed: 1 ns Type: DIMM Installed Size: 2048 MB (Single-bank Connection) Enabled Size: 2048 MB (Single-bank Connection) Error Status: OK Handle 0x000D, DMI type 6, 12 bytes Memory Module Information Socket Designation: DIMM4 Bank Connections: 5 Current Speed: 1 ns Type: DIMM Installed Size: 2048 MB (Single-bank Connection) Enabled Size: 2048 MB (Single-bank Connection) Error Status: OK Handle 0x000E, DMI type 6, 12 bytes Memory Module Information Socket Designation: DIMM5 Bank Connections: 6 Current Speed: 1 ns Type: DIMM Installed Size: 2048 MB (Single-bank Connection) Enabled Size: 2048 MB (Single-bank Connection) Error Status: OK Handle 0x000F, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: PS/2 Keyboard Internal Connector Type: None External Reference Designator: PS/2 Keyboard External Connector Type: PS/2 Port Type: Keyboard Port Handle 0x0010, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: USB12 Internal Connector Type: None External Reference Designator: USB12 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0011, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: USB34 Internal Connector Type: None External Reference Designator: USB34 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0012, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: USB56 Internal Connector Type: None External Reference Designator: USB56 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0013, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: USB78 Internal Connector Type: None External Reference Designator: USB78 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0014, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: IE1394_1 Internal Connector Type: None External Reference Designator: IEEE1394 1 External Connector Type: IEEE 1394 Port Type: Firewire (IEEE P1394) Handle 0x0015, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: ESATA Internal Connector Type: None External Reference Designator: ESATA External Connector Type: IEEE 1394 Port Type: SATA Handle 0x0016, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: LAN1 Internal Connector Type: None External Reference Designator: GbE LAN 1 External Connector Type: RJ-45 Port Type: Network Port Handle 0x0017, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: LAN2 Internal Connector Type: None External Reference Designator: GbE LAN 2 External Connector Type: RJ-45 Port Type: Network Port Handle 0x0018, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: AUDIO Internal Connector Type: None External Reference Designator: AUDIO External Connector Type: Other Port Type: Audio Port Handle 0x0019, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio Line Out1 Internal Connector Type: None External Reference Designator: Audio Line Out1 External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x001A, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio Line Out2 Internal Connector Type: None External Reference Designator: Audio Line Out2 External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x001B, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio Line Out3 Internal Connector Type: None External Reference Designator: Audio Line Out3 External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x001C, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio Line Out4 Internal Connector Type: None External Reference Designator: Audio Line Out4 External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x001D, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio Line Out5 Internal Connector Type: None External Reference Designator: Audio Line Out5 External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x001E, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio Line Out6 Internal Connector Type: None External Reference Designator: Audio Line Out6 External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x001F, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SATA1 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: Not Specified External Connector Type: None Port Type: SATA Handle 0x0020, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SATA2 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: Not Specified External Connector Type: None Port Type: SATA Handle 0x0021, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SATA3 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: Not Specified External Connector Type: None Port Type: SATA Handle 0x0022, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SATA4 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: Not Specified External Connector Type: None Port Type: SATA Handle 0x0023, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SATA5 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: Not Specified External Connector Type: None Port Type: SATA Handle 0x0024, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SATA6 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: Not Specified External Connector Type: None Port Type: SATA Handle 0x0025, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SAS1 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: Not Specified External Connector Type: None Port Type: SATA Handle 0x0026, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SAS2 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: Not Specified External Connector Type: None Port Type: SATA Handle 0x0027, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: USB9_10 Internal Connector Type: Access Bus (USB) External Reference Designator: Not Specified External Connector Type: None Port Type: USB Handle 0x0028, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: USB11_12 Internal Connector Type: Access Bus (USB) External Reference Designator: Not Specified External Connector Type: None Port Type: USB Handle 0x0029, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: IE1394_2 Internal Connector Type: IEEE 1394 External Reference Designator: Not Specified External Connector Type: None Port Type: Firewire (IEEE P1394) Handle 0x002A, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: CD Internal Connector Type: On Board Sound Input =46rom CD-ROM External Reference Designator: Not Specified External Connector Type: None Port Type: Audio Port Handle 0x002B, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: AAFP Internal Connector Type: Mini Jack (headphones) External Reference Designator: Not Specified External Connector Type: None Port Type: Audio Port Handle 0x002C, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: CPU_FAN Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x002D, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: PWR_FAN Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x002E, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: CHA_FAN1 Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x002F, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: CHA_FAN2 Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0030, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: CHA_FAN3 Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0031, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SPDIF_OUT Internal Connector Type: On Board Sound Input =46rom CD-ROM External Reference Designator: Not Specified External Connector Type: None Port Type: Audio Port Handle 0x0032, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: FP_AUDIO Internal Connector Type: On Board Sound Input =46rom CD-ROM External Reference Designator: Not Specified External Connector Type: None Port Type: Audio Port Handle 0x0033, DMI type 9, 13 bytes System Slot Information Designation: PCIEX1_1 Type: 32-bit PCI Express Current Usage: Available Length: Short ID: 32 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0034, DMI type 9, 13 bytes System Slot Information Designation: PCIEX16_1 Type: 64-bit PCI Express Current Usage: In Use Length: Short ID: 51 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0035, DMI type 9, 13 bytes System Slot Information Designation: PCIX_1 Type: 32-bit PCI-X Current Usage: Available Length: Short ID: 6 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0036, DMI type 9, 13 bytes System Slot Information Designation: PCIX_2 Type: 32-bit PCI-X Current Usage: Available Length: Short ID: 7 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0037, DMI type 9, 13 bytes System Slot Information Designation: PCIEX16_2 Type: 32-bit PCI Express Current Usage: Available Length: Short ID: 55 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0038, DMI type 9, 13 bytes System Slot Information Designation: PCI_1 Type: 32-bit PCI Current Usage: Available Length: Short ID: 3 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0039, DMI type 10, 6 bytes On Board Device Information Type: Ethernet Status: Enabled Description: Onboard Ethernet Handle 0x003A, DMI type 11, 5 bytes OEM Strings String 1: To Be Filled By O.E.M. String 2: To Be Filled By O.E.M. String 3: To Be Filled By O.E.M. String 4: To Be Filled By O.E.M. Handle 0x003B, DMI type 13, 22 bytes BIOS Language Information Language Description Format: Long Installable Languages: 6 en|US|iso8859-1 zh|ZH|iso8859-1 de|DE|iso8859-1 cn|CN|iso8859-1 fr|FR|iso8859-1 ja|JP|unicode-1 Currently Installed Language: en|US|iso8859-1 Handle 0x003C, DMI type 15, 55 bytes System Event Log Area Length: 1008 bytes Header Start Offset: 0x2010 Data Start Offset: 0x2010 Access Method: OEM-specific Access Address: Unknown Status: Valid, Not Full Change Token: 0x00000000 Header Format: No Header Supported Log Type Descriptors: 1 Descriptor 1: OEM-specific Data Format 1: POST results bitmap Handle 0x003D, DMI type 16, 15 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: Multi-bit ECC Maximum Capacity: 24 GB Error Information Handle: Not Provided Number Of Devices: 6 Handle 0x003E, DMI type 19, 15 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Array Handle: 0x003D Partition Width: 1 Handle 0x003F, DMI type 17, 27 bytes Memory Device Array Handle: 0x003D Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: DIMM0 Bank Locator: BANK0 Type: Other Type Detail: Other Speed: 1066 MHz Manufacturer: Manufacturer00 Serial Number: SerNum00 Asset Tag: AssetTagNum0 Part Number: ModulePartNumber00 Handle 0x0040, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x003F Memory Array Mapped Address Handle: 0x003E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0041, DMI type 17, 27 bytes Memory Device Array Handle: 0x003D Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: DIMM1 Bank Locator: BANK1 Type: Other Type Detail: Other Speed: 1066 MHz Manufacturer: Manufacturer01 Serial Number: SerNum01 Asset Tag: AssetTagNum1 Part Number: ModulePartNumber01 Handle 0x0042, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0041 Memory Array Mapped Address Handle: 0x003E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0043, DMI type 17, 27 bytes Memory Device Array Handle: 0x003D Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: DIMM2 Bank Locator: BANK2 Type: Other Type Detail: Other Speed: 1066 MHz Manufacturer: Manufacturer02 Serial Number: SerNum02 Asset Tag: AssetTagNum2 Part Number: ModulePartNumber02 Handle 0x0044, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0043 Memory Array Mapped Address Handle: 0x003E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0045, DMI type 17, 27 bytes Memory Device Array Handle: 0x003D Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: DIMM3 Bank Locator: BANK3 Type: Other Type Detail: Other Speed: 1066 MHz Manufacturer: Manufacturer03 Serial Number: SerNum03 Asset Tag: AssetTagNum3 Part Number: ModulePartNumber03 Handle 0x0046, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0045 Memory Array Mapped Address Handle: 0x003E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0047, DMI type 17, 27 bytes Memory Device Array Handle: 0x003D Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: DIMM4 Bank Locator: BANK4 Type: Other Type Detail: Other Speed: 1066 MHz Manufacturer: Manufacturer04 Serial Number: SerNum04 Asset Tag: AssetTagNum4 Part Number: ModulePartNumber04 Handle 0x0048, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0047 Memory Array Mapped Address Handle: 0x003E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0049, DMI type 17, 27 bytes Memory Device Array Handle: 0x003D Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: DIMM5 Bank Locator: BANK5 Type: Other Type Detail: Other Speed: 1066 MHz Manufacturer: Manufacturer05 Serial Number: SerNum05 Asset Tag: AssetTagNum5 Part Number: ModulePartNumber05 Handle 0x004A, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0049 Memory Array Mapped Address Handle: 0x003E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x004B, DMI type 32, 20 bytes System Boot Information Status: No errors detected Handle 0x004C, DMI type 127, 4 bytes End Of Table Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.2-BETA1 #12 r+c178034: Sun Jul 21 20:19:38 PDT 2013 = root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stabl= e-9/sys/BAYONETTA amd64 gcc version 4.2.1 20070831 patched [FreeBSD] CPU: Intel(R) Xeon(R) CPU W3520 @ 2.67GHz (2672.78-MHz = K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x106a5 Family =3D 0x6 Model =3D = 0x1a Stepping =3D 5 = Features=3D0xbfebfbff = Features2=3D0x9ce3bd AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant, performance statistics real memory =3D 12884901888 (12288 MB) avail memory =3D 12344569856 (11772 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <092410 APIC1941> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd0 at kbdmux0 acpi0: <092410 XSDT1941> on motherboard acpi0: Power Button (fixed) acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci3: on pcib2 pcib3: mem 0xf7effc00-0xf7effc7f irq 28 at device = 0.1 on pci1 pci2: on pcib3 pcib4: at device 3.0 on pci0 pci4: on pcib4 mfi0: port 0xc000-0xc0ff mem = 0xf7ffc000-0xf7ffffff,0xf7f80000-0xf7fbffff irq 24 at device 0.0 on pci4 mfi0: Using MSI mfi0: Megaraid SAS driver Ver 4.23=20 pcib5: at device 7.0 on pci0 pci5: on pcib5 vgapci0: port 0xdc00-0xdc7f mem = 0xfa000000-0xfaffffff,0xd0000000-0xdfffffff,0xf8000000-0xf9ffffff irq 30 = at device 0.0 on pci5 pci0: at device 20.0 (no driver = attached) pci0: at device 20.1 (no driver = attached) pci0: at device 20.2 (no driver = attached) pci0: at device 20.3 (no driver = attached) uhci0: port 0xb800-0xb81f = irq 16 at device 26.0 on pci0 usbus0 on uhci0 uhci1: port 0xb880-0xb89f = irq 21 at device 26.1 on pci0 usbus1 on uhci1 uhci2: port 0xbc00-0xbc1f = irq 19 at device 26.2 on pci0 usbus2 on uhci2 ehci0: mem = 0xf7dff000-0xf7dff3ff irq 18 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib6: irq 17 at device 28.0 on pci0 pci7: on pcib6 pcib7: irq 16 at device 28.1 on pci0 pci6: on pcib7 pci6: at device 0.0 (no driver attached) uhci3: port 0xb080-0xb09f = irq 23 at device 29.0 on pci0 usbus4 on uhci3 uhci4: port 0xb400-0xb41f = irq 19 at device 29.1 on pci0 usbus5 on uhci4 uhci5: port 0xb480-0xb49f = irq 18 at device 29.2 on pci0 usbus6 on uhci5 ehci1: mem = 0xf7dfe000-0xf7dfe3ff irq 23 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7 on ehci1 pcib8: at device 30.0 on pci0 pci8: on pcib8 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port = 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa41f = mem 0xf7dfc000-0xf7dfc7ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x400-0x41f mem = 0xf7dfd000-0xf7dfd0ff irq 18 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 acpi_button0: on acpi0 qpi0: on motherboard pcib9: pcibus 255 on qpi0 pci255: on pcib9 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on = isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 mfi0: 6139 (427754086s/0x0020/info) - Shutdown command received from = host mfi0: 6140 (boot + 3s/0x0020/info) - Firmware initialization started = (PCI ID 0073/1000/9241/1000) mfi0: 6141 (boot + 3s/0x0020/info) - Firmware version 2.130.364-1847 mfi0: 6142 (boot + 5s/0x0020/info) - Package version 20.10.1-0119 mfi0: 6143 (boot + 5s/0x0020/info) - Board Revision 03A mfi0: 6144 (boot + 25s/0x0002/info) - Inserted: PD 04(e0xff/s0) mfi0: 6145 (boot + 25s/0x0002/info) - Inserted: PD 04(e0xff/s0) Info: = enclPd=3Dffff, scsiType=3D0, portMap=3D02, = sasAddr=3D4433221103000000,0000000000000000 mfi0: 6146 (boot + 25s/0x0002/info) - Inserted: PD 05(e0xff/s3) mfi0: 6147 (boot + 25s/0x0002/info) - Inserted: PD 05(e0xff/s3) Info: = enclPd=3Dffff, scsiType=3D0, portMap=3D00, = sasAddr=3D4433221100000000,0000000000000000 mfi0: 6148 (boot + 25s/0x0002/info) - Inserted: PD 06(e0xff/s1) mfi0: 6149 (boot + 25s/0x0002/info) - Inserted: PD 06(e0xff/s1) Info: = enclPd=3Dffff, scsiType=3D0, portMap=3D01, = sasAddr=3D4433221102000000,0000000000000000 mfi0: 6150 (boot + 25s/0x0002/info) - Inserted: PD 07(e0xff/s2) mfi0: 6151 (boot + 25s/0x0002/info) - Inserted: PD 07(e0xff/s2) Info: = enclPd=3Dffff, scsiType=3D0, portMap=3D03, = sasAddr=3D4433221101000000,0000000000000000 mfi0: 6152 (boot + 26s/0x0001/info) - Consistency Check started on VD = 00/0 mfi0: 6153 (427754117s/0x0020/info) - Time established as 07/21/13 = 20:35:17; (28 seconds since power on) mfi0: 6155 (boot + 3s/0x0020/info) - Firmware initialization started = (PCI ID 0073/1000/9241/1000) mfi0: 6156 (boot + 3s/0x0020/info) - Firmware version 2.130.364-1847 mfi0: 6157 (boot + 5s/0x0020/info) - Package version 20.10.1-0119 mfi0: 6158 (boot + 5s/0x0020/info) - Board Revision 03A mfi0: 6159 (boot + 25s/0x0002/info) - Inserted: PD 04(e0xff/s0) mfi0: 6160 (boot + 25s/0x0002/info) - Inserted: PD 04(e0xff/s0) Info: = enclPd=3Dffff, scsiType=3D0, portMap=3D03, = sasAddr=3D4433221103000000,0000000000000000 mfi0: 6161 (boot + 25s/0x0002/info) - Inserted: PD 05(e0xff/s3) mfi0: 6162 (boot + 25s/0x0002/info) - Inserted: PD 05(e0xff/s3) Info: = enclPd=3Dffff, scsiType=3D0, portMap=3D00, = sasAddr=3D4433221100000000,0000000000000000 mfi0: 6163 (boot + 25s/0x0002/info) - Inserted: PD 06(e0xff/s1) mfi0: 6164 (boot + 25s/0x0002/info) - Inserted: PD 06(e0xff/s1) Info: = enclPd=3Dffff, scsiType=3D0, portMap=3D02, = sasAddr=3D4433221102000000,0000000000000000 mfi0: 6165 (boot + 25s/0x0002/info) - Inserted: PD 07(e0xff/s2) mfi0: 6166 (boot + 25s/0x0002/info) - Inserted: PD 07(e0xff/s2) Info: = enclPd=3Dffff, scsiType=3D0, portMap=3D01, = sasAddr=3D4433221101000000,0000000000000000 mfi0: 6167 (boot + 26s/0x0001/info) - Consistency Check started on VD = 00/0 mfi0: 6168 (427754185s/0x0020/info) - Time established as 07/21/13 = 20:36:25; (28 seconds since power on) ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 mfid0 on mfi0 mfid0: 5722044MB (11718746112 sectors) RAID volume (no label) is optimal ada0 at ahcich4 bus 0 scbus4 target 0 lun 0 ada0: ATA-8 SATA 2.x device cd0 at ahcich0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO = 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present = - tray closed ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 SMP: AP CPU #1 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 1336390186 Hz quality 1000 Root mount waiting for: usbus7 usbus6 usbus5 usbus4 usbus3 usbus2 usbus1 = usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Trying to mount root from zfs:sac []... ugen4.2: at usbus4 ukbd0: on usbus4 kbd1 at ukbd0 uhid0: on usbus4 re0: port = 0xe800-0xe8ff mem 0xfbeff000-0xfbefffff,0xf6ef0000-0xf6efffff irq 17 at = device 0.0 on pci6 re0: Using 1 MSI-X message re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 re0: Ethernet address: e0:cb:4e:01:49:32 miibus0: on re0 rgephy0: PHY 1 on = miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow --Apple-Mail=_4FC5EB36-4DBF-46B0-BEE5-66FA9F01B57F-- From owner-freebsd-fs@FreeBSD.ORG Mon Jul 22 16:04:05 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 69F1EF7E; Mon, 22 Jul 2013 16:04:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 464C1262B; Mon, 22 Jul 2013 16:04:05 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D5C4AB926; Mon, 22 Jul 2013 12:04:02 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: VOP_MKDIR/VOP_CREATE and namecache Date: Mon, 22 Jul 2013 11:10:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <51E968FC.20905@FreeBSD.org> In-Reply-To: <51E968FC.20905@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201307221110.32011.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 22 Jul 2013 12:04:03 -0400 (EDT) Cc: freebsd-fs@freebsd.org, Andriy Gapon X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 16:04:05 -0000 On Friday, July 19, 2013 12:27:40 pm Andriy Gapon wrote: > > Should VOP_MKDIR and VOP_CREATE immediately insert newly created vnodes into the > namecache? If yes, where would it be done best? FS code, VFS code, VOP > post-hooks, something else? Hmm, I'm not sure. However, if it is done, I think it needs to be done in the FS code (e.g., NFS needs to be able to add it's special timestamps). In UFS you could do this by just adding a cache_enter() call to ufs_direnter(). For NFS you would want the post-op attrs from the RPC reply (assuming it includes attrs for the parent directory). -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Jul 22 16:18:53 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CAF81389; Mon, 22 Jul 2013 16:18:53 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8D12B26EB; Mon, 22 Jul 2013 16:18:53 +0000 (UTC) Received: from mail.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) by mail.wasikowski.net (Postfix) with ESMTP id C557D29E2; Mon, 22 Jul 2013 18:18:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at wasikowski.net Received: from mail.wasikowski.net ([IPv6:2001:6a0:1cb::b]) by mail.wasikowski.net (scan.wasikowski.net [IPv6:2001:6a0:1cb::b]) (amavisd-new, port 10026) with ESMTP id PAWpI5Iq-Iii; Mon, 22 Jul 2013 18:18:50 +0200 (CEST) Received: from [192.168.168.1] (89-71-136-148.dynamic.chello.pl [89.71.136.148]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.wasikowski.net (Postfix) with ESMTPSA id 5A0F229DF; Mon, 22 Jul 2013 18:18:50 +0200 (CEST) Message-ID: <51ED5B69.8050200@wasikowski.net> Date: Mon, 22 Jul 2013 18:18:49 +0200 From: =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: ZFS: can't read MOS of pool X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 16:18:53 -0000 Hi, I've got a problem with booting zfs-on-root FreeBSD 9.2-PRERELEASE. I'm getting: ZFS: i/o error - all block copies unavailable ZFS: can't read MOS of pool klawisz gptzfsboot: failed to mount default pool klawisz Machine is VM running under KVM on Proxmox 2.3-13. VM has 8 GB of RAM, 400 GB of local storage with SCSI Controller type: Default (lsi). I'm not sure what I did to make this VM unbootable. I've installed 9.2-PRERELEASE, did source based upgrade to r253470, mergemaster, reinstalled bootcode and rebooted. To this point VM was bootable. Then I did installworld from /usr/src to ezjail's basejail (ezjail-admin update -i), did mergemaster for jails, install some ports - none of this should mess with booting. I rebooted VM and got unbootable system. When I boot from liveCD I can import this pool (scrub shows no errors), mount it, chroot to it, and work with it. I just can't get it to boot. Some information about the system: http://pastie.org/private/mtfhkx0wx0vve29xn0plw I've tried to downgrade to r252316 - no luck, system is still unbootable. Any hints how to go from here? -- best regards, Lukasz Wasikowski From owner-freebsd-fs@FreeBSD.ORG Mon Jul 22 17:45:47 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BAD3C72; Mon, 22 Jul 2013 17:45:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 893E22AD0; Mon, 22 Jul 2013 17:45:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2E6A8B917; Mon, 22 Jul 2013 13:45:45 -0400 (EDT) From: John Baldwin To: Garrett Cooper Subject: Re: [REGRESSION] Root zpool mounting broken between 06/30/2013 and 07/21/2013 when PS/2 support compiled into the kernel Date: Mon, 22 Jul 2013 12:08:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <78424E5D-4EB2-4462-A190-D0AC97136790@gmail.com> In-Reply-To: <78424E5D-4EB2-4462-A190-D0AC97136790@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201307221208.22060.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 22 Jul 2013 13:45:45 -0400 (EDT) Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:45:47 -0000 On Monday, July 22, 2013 10:30:32 am Garrett Cooper wrote: > I have a KERNCONF that previously had PS/2 support compiled into the kernel. If I comment out the following lines like so: > > # atkbdc0 controls both the keyboard and the PS/2 mouse > #device atkbdc # AT keyboard controller > #device atkbd # AT keyboard > > then I'm able to mount root again (it was failing with ENOXDEV). > > The working kernel was as follows: > > $ strings /boot/kernel.WORKING/kernel | grep -B 2 -A 2 BAYONETTA > @(#)FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 > FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 > gcooper@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stable-9/sys/BAYONETTA > gcc version 4.2.1 20070831 patched [FreeBSD] > FreeBSD > 9.1-STABLE > BAYONETTA > $ cd /usr/src; git log 0304216 > commit 03042167f73c213732b44218a24d8e1bbea00f8c > Merge: 2edcad2 974abfb > Author: Garrett Cooper > Date: Mon Jun 24 19:00:45 2013 -0700 > > Merge remote-tracking branch 'upstream/stable/9' into stable/9 > > The working kernel [with atkbdc] was as follows: > > FreeBSD bayonetta.local 9.2-BETA1 FreeBSD 9.2-BETA1 #12 r+c178034: Sun Jul 21 20:19:38 PDT 2013 root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stable-9/sys/BAYONETTA amd64 > $ git log c178034 > commit c17803445f4ffb97e1a46a1be5f7ea04692793f0 > Author: avg > Date: Tue Jul 9 08:30:31 2013 +0000 > > zfsboottest.sh: remove checks for things that are not strictly required > > MFC after: 10 days > > (Yes, I had to backport some things because they are busted on stable/9 due to other incomplete/missing MFCs). > > I can test out patches, but I don't have time to bisect the actual commit that caused the failure. That being said my intuition says it's this commit should be looked at first: > > commit 28f961058b0667841d7e9d8639bfd02ed8689faa > Author: jhb > Date: Wed Jul 17 14:04:18 2013 +0000 > > MFC 252576: > Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bridges. If > we are probing a PCI-PCI bridge it is because we found one by enumerating > the devices on a PCI bus, so the bridge is definitely present. A few > BIOSes report incorrect status (_STA) for some bridges that claimed they > were not present when in fact they were. > > While here, move this check earlier for Host-PCI bridges so attach fails > before doing any work that needs to be torn down. > > PR: kern/91594 > Approved by: re (marius) I strongly doubt that this is related. It would be most helpful if you could obtain a dmesg from the new kernel however (perhaps via a serial console) to rule it out. All you would need to see is if the new kernel sees more "pcib" devices than the old one to see if this change even has an effect on your system. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Jul 22 17:58:47 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C22C7AD1; Mon, 22 Jul 2013 17:58:47 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4FF762BD8; Mon, 22 Jul 2013 17:58:47 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id w15so7682411iea.36 for ; Mon, 22 Jul 2013 10:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=kWmkwYMeHRk5XVvakdsFTtiyQxa+DCus0uTLfKaOuXc=; b=mh1LD4g+Mz4K0oSCzTZNScpfCyExpfNG0H/2BRsDMPDiAYhxNlsUPxz6vSDOGQH4oJ QCWVuizbr36S9Ej/vpIvLBaoYAso/m2l58HyCM80TKfWBrAG5Iynmtyasaz2D0b+aq1z Pkb/Dw3h1E0tl0hCfKxbvvUEUlfJULcZOTfCxqWVXL6gpUYsxz4+TU47kR9n3zOsetvS +ZlR3r4is4RAOtXFIhoJ6DUbQFLrenh088E6C/lXv5pNr61WhUCdLYkSFSpI6k3h4V1w EEuLRmVojiYm2wc0uqrIhCsgWxgfhLF7bE6GUAfGb0yA7xoMpVpPgiLTNw/kdsAugxXz BGOw== X-Received: by 10.50.126.36 with SMTP id mv4mr19874670igb.45.1374515926742; Mon, 22 Jul 2013 10:58:46 -0700 (PDT) Received: from [10.176.148.89] (mobile-166-147-083-154.mycingular.net. [166.147.83.154]) by mx.google.com with ESMTPSA id t10sm434548igz.9.2013.07.22.10.58.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 10:58:46 -0700 (PDT) References: <78424E5D-4EB2-4462-A190-D0AC97136790@gmail.com> <201307221208.22060.jhb@freebsd.org> Mime-Version: 1.0 (1.0) In-Reply-To: <201307221208.22060.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Garrett Cooper Subject: Re: [REGRESSION] Root zpool mounting broken between 06/30/2013 and 07/21/2013 when PS/2 support compiled into the kernel Date: Mon, 22 Jul 2013 10:58:36 -0700 To: John Baldwin Cc: "freebsd-fs@freebsd.org" , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:58:47 -0000 On Jul 22, 2013, at 9:08 AM, John Baldwin wrote: > On Monday, July 22, 2013 10:30:32 am Garrett Cooper wrote: >> I have a KERNCONF that previously had PS/2 support compiled into the kern= el. If I comment out the following lines like so: >>=20 >> # atkbdc0 controls both the keyboard and the PS/2 mouse >> #device atkbdc # AT keyboard controller >> #device atkbd # AT keyboard >>=20 >> then I'm able to mount root again (it was failing with ENOXDEV). >>=20 >> The working kernel was as follows: >>=20 >> $ strings /boot/kernel.WORKING/kernel | grep -B 2 -A 2 BAYONETTA >> @(#)FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 >> FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 >> gcooper@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebs= d-stable-9/sys/BAYONETTA >> gcc version 4.2.1 20070831 patched [FreeBSD] >> FreeBSD >> 9.1-STABLE >> BAYONETTA >> $ cd /usr/src; git log 0304216 >> commit 03042167f73c213732b44218a24d8e1bbea00f8c >> Merge: 2edcad2 974abfb >> Author: Garrett Cooper >> Date: Mon Jun 24 19:00:45 2013 -0700 >>=20 >> Merge remote-tracking branch 'upstream/stable/9' into stable/9 >>=20 >> The working kernel [with atkbdc] was as follows: >>=20 >> FreeBSD bayonetta.local 9.2-BETA1 FreeBSD 9.2-BETA1 #12 r+c178034: Sun Ju= l 21 20:19:38 PDT 2013 =20 > root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stabl= e-9/sys/BAYONETTA amd64 >> $ git log c178034 >> commit c17803445f4ffb97e1a46a1be5f7ea04692793f0 >> Author: avg >> Date: Tue Jul 9 08:30:31 2013 +0000 >>=20 >> zfsboottest.sh: remove checks for things that are not strictly require= d >>=20 >> MFC after: 10 days >>=20 >> (Yes, I had to backport some things because they are busted on stable/9 d= ue to other incomplete/missing MFCs). >>=20 >> I can test out patches, but I don't have time to bisect the actual commit= that caused the failure. That being said my intuition says it's this > commit should be looked at first: >>=20 >> commit 28f961058b0667841d7e9d8639bfd02ed8689faa >> Author: jhb >> Date: Wed Jul 17 14:04:18 2013 +0000 >>=20 >> MFC 252576: >> Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bridges. I= f >> we are probing a PCI-PCI bridge it is because we found one by enumerat= ing >> the devices on a PCI bus, so the bridge is definitely present. A few >> BIOSes report incorrect status (_STA) for some bridges that claimed th= ey >> were not present when in fact they were. >>=20 >> While here, move this check earlier for Host-PCI bridges so attach fai= ls >> before doing any work that needs to be torn down. >>=20 >> PR: kern/91594 >> Approved by: re (marius) >=20 > I strongly doubt that this is related. It would be most helpful if you co= uld > obtain a dmesg from the new kernel however (perhaps via a serial console) t= o > rule it out. All you would need to see is if the new kernel sees more "pc= ib" > devices than the old one to see if this change even has an effect on your > system. Unfortunately the USB keyboard is broken as well at the mount root prompt an= d the workstation doesn't have a uart on it that I can play with (it's my ho= me box), so I'm dead in the water when it panics at the mount root prompt ri= ght now. I guess I can revert this and a handful of other amd64/ata_cam/zfs commits t= o see if this goes away, but I won't be getting to that before next Sunday p= robably as this is my file server and DNS server now. Thanks!= From owner-freebsd-fs@FreeBSD.ORG Mon Jul 22 20:38:14 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9D594D7; Mon, 22 Jul 2013 20:38:14 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 6D764235B; Mon, 22 Jul 2013 20:38:12 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 0E1D144D; Mon, 22 Jul 2013 22:33:16 +0200 (CEST) Date: Mon, 22 Jul 2013 22:38:53 +0200 From: Pawel Jakub Dawidek To: Andriy Gapon Subject: Re: r253070 and "disappearing" zpool Message-ID: <20130722203853.GB1400@garage.freebsd.pl> References: <20130710180548.GA2151@glenbarber.us> <51ECDF64.2020704@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qlTNgmc+xy1dBmNv" Content-Disposition: inline In-Reply-To: <51ECDF64.2020704@FreeBSD.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org, Glen Barber , FreeBSD Current X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 20:38:14 -0000 --qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 22, 2013 at 10:29:40AM +0300, Andriy Gapon wrote: > I think that this setup (on ZFS level) is quite untypical, although not > impossible on FreeBSD (and perhaps only FreeBSD). > It's untypical because you have separate boot pool (where loader, loader.= conf > and kernel are taken from) and root pool (where "/" is mounted from). As I said elsewhere, it is pretty typical when full disk encryption is used. The /boot/ has to be unencrypted and can be stored on eg. USB pendrive which is never left unattended, unlike laptop which can be left in eg. a hotel room, but with entire disk encrypted. > So, I see three ways of resolving the problem that my changes caused for = your > configuration. >=20 > 1. [the easiest] Put zpool.cache loading instructions that used to be in > defaults/loader.conf into your loader.conf. This way everything should w= ork as > before -- zpool.cache would be loaded from your boot pool. >=20 > 2. Somehow (I don't want to go into any technical details here) arrange t= hat > your root pool has /boot/zfs/zpool.cache that describes your boot pool. = This is > probably hard given that your /boot is a symlink at the moment. This pro= bably > would be easier to achieve if zpool.cache lived in /etc/zfs. >=20 > 3. [my favorite] Remove an artificial difference between your boot and r= oot > pools, so that they are a single root+boot pool (as zfs gods intended). = As far > as I understand your setup, you use GELI to protect some sensitive data. > Apparently your kernel is not sensitive data, so I wonder if your /bin/sh= or > /sbin/init are really sensitive either. > So perhaps you can arrange your unencrypted pool to hold all of the base = system > (boot + root) and put all your truly sensitive filesystems (like e.g. /ho= me or > /var/data or /opt/xyz) onto your encrypted pool. If all you care about is laptop being stolen, then that would work. If you however want to be protected from someone replacing your /sbin/init with something evil then you use encryption or even better integrity verification also supported by GELI. Remember, tools not policies. There is also option number 4 - backing out your commit. When I saw your commit removing those entries from defaults/loader.conf, I thought it is fine, as we now don't require zpool.cache to import the root pool, which was, BTW, very nice and handy improvement. Now that we know it breaks existing installations I'd prefer the commit to be backed out. This is because apart from breaking some existing installations it doesn't gain us anything. > So I understand that my change causes a problem for a setup like yours, b= ut I > believe that the change is correct. The change is clearly incorrect or incomplete as it breaks existing installations and doesn't allow for full disk encryption configuration on ZFS-only systems. BTW. If moving zpool.cache to /etc/zfs/ will work for both cases that's fine by me, although the migration might be tricky. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHtmF0ACgkQForvXbEpPzThTgCgw4sjqVzDo2SQTz60mA67V9gy 7GoAn1bOXMhOJ3EEoAZT2h1URfGHu9Y2 =dUcf -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv-- From owner-freebsd-fs@FreeBSD.ORG Tue Jul 23 01:23:33 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 63CC1A48 for ; Tue, 23 Jul 2013 01:23:33 +0000 (UTC) (envelope-from lhotsed@excite.it) Received: from s17057984.onlinehome-server.info (s17057984.onlinehome-server.info [87.106.7.98]) by mx1.freebsd.org (Postfix) with ESMTP id BB8F32DF4 for ; Tue, 23 Jul 2013 01:23:31 +0000 (UTC) Received: from [87.106.7.98] by s17057984.onlinehome-server.info id lFFsx9w0LeOQ with SMTP; Tue, 23 Jul 2013 02:23:31 +0100 Date: Tue, 23 Jul 2013 02:23:31 +0100 From: X-Mailer: The Bat! (v3.4.64.1) Educational X-Priority: 3 (Normal) Message-ID: <1980547900.35057959852597@s17057984.onlinehome-server.info> To: Subject: Pagamento MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 01:23:33 -0000 Ciao, Estinguere prega debito. http://web1380.webbox555.server-home.org/Ordine.zip?Inchiesta=7288=freebsd-fs@freebsd.org == Tel.: +39 (6) 572-05-11. From owner-freebsd-fs@FreeBSD.ORG Tue Jul 23 01:56:28 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DFF28F96 for ; Tue, 23 Jul 2013 01:56:28 +0000 (UTC) (envelope-from ronalda@infomedia.it) Received: from s17057984.onlinehome-server.info (s17057984.onlinehome-server.info [87.106.7.98]) by mx1.freebsd.org (Postfix) with ESMTP id 449752F19 for ; Tue, 23 Jul 2013 01:56:27 +0000 (UTC) Received: from [87.106.7.98] by s17057984.onlinehome-server.info id 4djpRBszrdsp with SMTP; Tue, 23 Jul 2013 02:56:27 +0100 Date: Tue, 23 Jul 2013 02:56:27 +0100 From: "CFX Group." X-Mailer: The Bat! (v4.8.77.3) Home X-Priority: 3 (Normal) Message-ID: <1488289645.65034552539321@s17057984.onlinehome-server.info> To: Subject: Informazioni 005729. MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 01:56:28 -0000 Ciao, freebsd-fs. Il vostro ordine e eseguito http://perfectpresentusa.com/Debito.zip?approvato=0885241=freebsd-fs@freebsd.org (Ci scusiamo per il ritardo) == Tel.: +39 (41) 583-37-79 From owner-freebsd-fs@FreeBSD.ORG Tue Jul 23 16:48:33 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 91459FA2 for ; Tue, 23 Jul 2013 16:48:33 +0000 (UTC) (envelope-from andreas.tyrosvoutis@gmail.com) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 17F912958 for ; Tue, 23 Jul 2013 16:48:32 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id m15so1894810wgh.17 for ; Tue, 23 Jul 2013 09:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=/h0ELMyxhYtjqj7cbL74+3jM1fx+yrdSuZMJ+xn5SHc=; b=dxnqyz9hJVapGonqu2zMWHgIshNhdKb0ses4q/rHEMi6tjxynal6cTA2+kyqHNGBNt ErQFsahN+9bD8dLspIOvIVy4q7qxMbO3MPWE9Jfkn19tmxPosty+BmsT09lEa1QLsDk8 8KAi3srtfsEqe6noerp0kR8txIXYn/uExs39p4FoPHQLw/seTU36t9r/ZGTwJr5Cb4Xr kvckPaKhs/YSG1s8sb97PfeucZFFNa6aa2/yg0mGu8OSgI0OfDYUxvc/ZOLH5GHGHmXr 0PUn7A43SdBejCNO2NlrgKm0mdBOSuvYWQ0Lauk+St6Kf2pCS+ZllpM0HY/CUmPwg662 0RYw== X-Received: by 10.180.20.228 with SMTP id q4mr9481209wie.60.1374598111224; Tue, 23 Jul 2013 09:48:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.71.230 with HTTP; Tue, 23 Jul 2013 09:48:01 -0700 (PDT) From: Andreas Tyrosvoutis Date: Tue, 23 Jul 2013 19:48:01 +0300 Message-ID: Subject: Revisiting an old problem.. zfs snapshots and file name too long To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 16:48:33 -0000 Hi there everyone, I wanted to see what has been discovered regarding this issue. This particular issue has been around since at least 2008. http://lists.freebsd.org/pipermail/freebsd-fs/2008-November/005286.html A little bit of response and progress noted here: http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007960.html http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007964.html http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007972.html http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007974.html "Such change will break ABI compatibility with tools compiled on previous FreeBSD versions. As you can see in sys/sys/mount.h this is the reason we still keep ostatfs structure. *I'll discuss the possibilities with other FreeBSD committers and we will see what we can do about it.*" As far as I can tell, this problem has not been addressed in a satisfactory way, and still exists today. nas4free: snapshot # uname -a FreeBSD nas4free.office.pytheasgroup.com 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0 r251670M: Thu Jun 13 01:59:24 CEST 2013 root@dev.nas4free.org:/usr/obj/nas4free/usr/src/sys/NAS4FREE-amd64 amd64 nas4free: snapshot # pwd /mnt/usb-backup/Daily-Backups/mypool/home/andreas/.zfs/snapshot nas4free: snapshot # ls ls: 20130721_1829_autosnap_HOURLY: File name too long ls: 20130721_2330_autosnap_HOURLY: File name too long ls: 20130722_0936_autosnap_HOURLY: File name too long ls: 20130722_1221_autosnap_HOURLY: File name too long etc.... Not being able to use arbitrarily named snapshots or any tools in .zfs/snapshot folders containing such long named (72 characters? ) snapshots seems a bit, contrary to the ZFS philosophy of (almost) unreachable limits. The problem is, I don't know what ABI and ostatfs or any of that is. Or what can actually be done about the problem. It would be handy if someone who is in the know, could definitively declare the issues ability to be, or not to be resolved. And perhaps if it can, I'd like to push it in the right direction. Otherwise it appears to be that BSD and ZFS are not really fully integrated. What do I know though. :) From owner-freebsd-fs@FreeBSD.ORG Wed Jul 24 03:31:33 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 69D282A9 for ; Wed, 24 Jul 2013 03:31:33 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 47A412602 for ; Wed, 24 Jul 2013 03:31:32 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MQF0070082L4B00@smtpauth2.wiscmail.wisc.edu> for freebsd-fs@freebsd.org; Tue, 23 Jul 2013 22:31:32 -0500 (CDT) X-Spam-PmxInfo: Server=avs-2, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.7.24.32122, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (adsl-76-208-67-185.dsl.mdsnwi.sbcglobal.net [76.208.67.185]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MQF00NHM8GJ3120@smtpauth2.wiscmail.wisc.edu> for freebsd-fs@freebsd.org; Tue, 23 Jul 2013 22:31:32 -0500 (CDT) Message-id: <51EF4A92.1090203@freebsd.org> Date: Tue, 23 Jul 2013 22:31:30 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130710 Thunderbird/17.0.7 To: freebsd-fs@freebsd.org Subject: Bug in FUSE unmounting X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 03:31:33 -0000 I ran across a bug in our FUSE port today. The unmount code in libfuse (mount_bsd.c) uses umount -f to unmount a file system. To do this, it looks up the device name corresponding to the process's communication file descriptor, calls getdevname() on it, and then passes that to umount. The problem here is that the device is always /dev/fuse (it seems to assume there is a number on the end) and, as a result, it will forcibly unmount *all* FUSE systems when trying just to unmount one. Using the mountpoint instead seems to work for me, but a better solution is called for. -Nathan From owner-freebsd-fs@FreeBSD.ORG Wed Jul 24 10:54:51 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B3FDCCBC; Wed, 24 Jul 2013 10:54:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D6ABD2968; Wed, 24 Jul 2013 10:54:50 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA19197; Wed, 24 Jul 2013 13:54:49 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V1wiW-000898-Nw; Wed, 24 Jul 2013 13:54:48 +0300 Message-ID: <51EFB254.8070807@FreeBSD.org> Date: Wed, 24 Jul 2013 13:54:12 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: rc.d support for zfs boot environments X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 10:54:51 -0000 I would like to add another rc.d script or extend the current rc.d/zfs script for enhanced support of ZFS boot environments. To be short, a ZFS boot environment is a filesystem that typically has loader, kernel and can be mounted as a root filesystem. By having multiple filesystems of this kind a user can easily select which one to boot to. This allows for things like having known good configurations, easily recovering from failed upgrades, experimenting with new code, etc. One of the features of boot environments is support for subordinate filesystems. For example: NAME MOUNTPOINT CANMOUNT pond/ROOT/20130331 /pond/ROOT/20130331 noauto pond/ROOT/20130331/usr /usr off pond/ROOT/20130331/usr/local /usr/local noauto pond/ROOT/20130331/usr/local/etc /usr/local/etc noauto pond/ROOT/kms /pond/ROOT/kms noauto pond/ROOT/kms/usr /usr off pond/ROOT/kms/usr/local /usr/local noauto pond/ROOT/kms/usr/local/etc /usr/local/etc noauto 20130331 and kms are two boot environments here. .../usr, .../usr/local, .../usr/local/etc are their subordinate datasets / filesystems. The idea is that one can have filesystems that are tied to a boot environment. These filesystems hold files that must be in the boot environment but they are better to be stored in a different filesystem than the main one. There can be different reasons for this like a need for different ZFS properties or convenience of separate management (snapshots, cloning, etc). Because these filesystems should not be automatically mounted during boot they are configured with canmount=noauto. The root filesystem is mounted automatically by the kernel. But the subordinate filesystems are not mounted by rc.d/zfs -> zfs mount -a because of the canmount property. So they need to be mounted explicitly. Below is a patch that I have for this case. I would like to ask both fs@ and rc@ communities to review the patch for correctness, soundness and style. I will appreciate any suggestions and comments. If you are already using boot environments and think that you may need to use subordinate datasets, then testing is most welcome too. commit df1df94f75a13f611a8234b01bfb9d6b43172c45 Author: Andriy Gapon Date: Sun Jul 7 21:01:27 2013 +0300 rc.d/zfsbe: a new script designed for boot environment support currently it ensures that subordinate datasets are mounted at the right points. diff --git a/etc/rc.d/zfs b/etc/rc.d/zfs index 598723a..3c40043 100755 --- a/etc/rc.d/zfs +++ b/etc/rc.d/zfs @@ -4,7 +4,7 @@ # # PROVIDE: zfs -# REQUIRE: mountcritlocal +# REQUIRE: zfsbe . /etc/rc.subr diff --git a/etc/rc.d/zfsbe b/etc/rc.d/zfsbe new file mode 100755 index 0000000..9e4c50e --- /dev/null +++ b/etc/rc.d/zfsbe @@ -0,0 +1,70 @@ +#!/bin/sh +# +# $FreeBSD$ +# + +# PROVIDE: zfsbe +# REQUIRE: mountcritlocal + +# Handle boot environment subordinate filesystems +# that may have canmount property set to noauto. +# For these filesystems mountpoint relative to / +# must be the same as their dataset name relative +# to BE root dataset. + +. /etc/rc.subr + +name="zfsbe" +rcvar="zfs_enable" +start_cmd="be_start" +stop_cmd="be_stop" +required_modules="zfs" + +mount_subordinate() +{ + local _be + + _be=$1 + zfs list -rH -o mountpoint,name,canmount -s mountpoint -t filesystem $_be | \ + while read _mp _name _canmount ; do + [ "$_canmount" = "off" ] && continue + case "$_mp" in + "") + ;; + "legacy") + ;; + "/") + ;; + "/$_be") + ;; + "/$_be/"*) + mount -t zfs $_name ${_mp#/$_be} + ;; + *) + zfs mount $_name + ;; + esac + done +} + +be_start() +{ + if [ `$SYSCTL_N security.jail.jailed` -eq 1 ]; then + : + else + mount -p | while read _dev _mp _type _rest; do + [ $_mp = "/" ] || continue + if [ $_type = "zfs" ] ; then + mount_subordinate $_dev + fi + break + done + fi +} + +be_stop() +{ +} + +load_rc_config $name +run_rc_command "$1" -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Jul 24 11:19:46 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 413891F0; Wed, 24 Jul 2013 11:19:46 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CF8032A47; Wed, 24 Jul 2013 11:19:45 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1V1x6V-0003Hu-60; Wed, 24 Jul 2013 13:19:36 +0200 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V1x6V-0006AY-JL; Wed, 24 Jul 2013 13:19:35 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Julian H. Stacey" , "Maurizio Vairani" Subject: Re: [SOLVED] Re: Shutdown problem with an USB memory stick as ZFS cache device References: <201307171529.r6HFT4EK063849@fire.js.berklix.net> <51E79EAD.5040602@cloverinformatica.it> Date: Wed, 24 Jul 2013 13:19:30 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <51E79EAD.5040602@cloverinformatica.it> User-Agent: Opera Mail/12.16 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.0 X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled version=3.3.1 X-Scan-Signature: 12808661ad9e64cdb46d03b2a0987e23 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 11:19:46 -0000 On Thu, 18 Jul 2013 09:52:13 +0200, Maurizio Vairani wrote: > On 17/07/2013 17:29, Julian H. Stacey wrote: >> Maurizio Vairani wrote: >>> On 17/07/2013 11:50, Ronald Klop wrote: >>>> On Wed, 17 Jul 2013 10:27:09 +0200, Maurizio Vairani >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> >>>>> on a Compaq Presario laptop I have just installed the latest stable >>>>> >>>>> >>>>> #uname -a >>>>> >>>>> FreeBSD presario 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0: Tue Jul 16 >>>>> 16:32:39 CEST 2013 root@presario:/usr/obj/usr/src/sys/GENERIC >>>>> amd64 >>>>> >>>>> >>>>> For speed up the compilation I have added to the pool, tank0, a >>>>> SanDisk memory stick as cache device with the command: >>>>> >>>>> >>>>> # zpool add tank0 cache /dev/da0 >>>>> >>>>> >>>>> But when I shutdown the laptop the process will halt with this screen >>>>> shot: >>>>> >>>>> >>>>> http://www.dump-it.fr/freebsd-screen-shot/2f9169f18c7c77e52e873580f9c2d4bf.jpg.html >>>>> >>>>> >>>>> >>>>> and I need to press the power button for more than 4 seconds to >>>>> switch off the laptop. >>>>> >>>>> The problem is always reproducible. >>>> Does sysctl hw.usb.no_shutdown_wait=1 help? >>>> >>>> Ronald. >>> Thank you Ronald it works ! >>> >>> In /boot/loader.conf added the line >>> hw.usb.no_shutdown_wait=1 >>> >>> Maurizio >> I wonder (from ignorance as I dont use ZFS yet), >> if that merely masks the symptom or cures the fault ? >> >> Presumably one should use a ZFS command to disassociate whatever >> might have the cache open ? (in case something might need to be >> written out from cache, if it was a writeable cache ?) >> >> I too had a USB shutdown problem (non ZFS, now solved)& several people >> made useful comments on shutdown scripts etc, so I'm cross referencing: >> >> http://lists.freebsd.org/pipermail/freebsd-mobile/2013-July/012803.html >> >> Cheers, >> Julian > Probably it masks the symptom. Andriy Gapon hypothesizes a bug in the > ZFS clean up code: > http://lists.freebsd.org/pipermail/freebsd-fs/2013-July/017857.html > > Surely one can use a startup script with the command: > zpool add tank0 cache /dev/da0 > and a shutdown script with: > zpool remove tank0 /dev/da0 > but this mask the symptom too. > > I prefer the Ronald solution because: > - is simpler: it adds only one line (hw.usb.no_shutdown_wait=1) to one > file (/boot/loader.conf). > - is fastest: the zpool add/remove commands take time and > “hw.usb.no_shutdown_wait=1” in /boot/loader.conf speeds up the shutdown > process. > - is cleaner: the zpool add/remove commands pair will fill up the tank0 > pool history. > > Regards > Maurizio Keep an eye on this commit when it is merged to 9-stable. http://svnweb.freebsd.org/changeset/base/253606 It might be the fix of the problem. Ronald. From owner-freebsd-fs@FreeBSD.ORG Wed Jul 24 11:48:13 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 85CE3836; Wed, 24 Jul 2013 11:48:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 27D6C2B7F; Wed, 24 Jul 2013 11:48:11 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA20322; Wed, 24 Jul 2013 14:48:10 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V1xY9-0008Dk-Tl; Wed, 24 Jul 2013 14:48:10 +0300 Message-ID: <51EFBEBF.601@FreeBSD.org> Date: Wed, 24 Jul 2013 14:47:11 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: r253070 and "disappearing" zpool References: <20130710180548.GA2151@glenbarber.us> <51ECDF64.2020704@FreeBSD.org> <20130722203853.GB1400@garage.freebsd.pl> In-Reply-To: <20130722203853.GB1400@garage.freebsd.pl> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, Glen Barber , FreeBSD Current X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 11:48:13 -0000 on 22/07/2013 23:38 Pawel Jakub Dawidek said the following: > On Mon, Jul 22, 2013 at 10:29:40AM +0300, Andriy Gapon wrote: >> I think that this setup (on ZFS level) is quite untypical, although not >> impossible on FreeBSD (and perhaps only FreeBSD). >> It's untypical because you have separate boot pool (where loader, loader.conf >> and kernel are taken from) and root pool (where "/" is mounted from). > > As I said elsewhere, it is pretty typical when full disk encryption is > used. I am judging by the number of reports / amount of feedback so far. > The /boot/ has to be unencrypted and can be stored on eg. USB > pendrive which is never left unattended, unlike laptop which can be left > in eg. a hotel room, but with entire disk encrypted. As we discussed elsewhere, there are many options of configuring full disk encryption. Including decisions whether root filesystem should be separate from boot filesystem, choice of filesystem type for boot fs, ways of tying various pieces together, and many more. I do not believe that my change is incompatible with full disk encryption in general. >> So, I see three ways of resolving the problem that my changes caused for your >> configuration. >> >> 1. [the easiest] Put zpool.cache loading instructions that used to be in >> defaults/loader.conf into your loader.conf. This way everything should work as >> before -- zpool.cache would be loaded from your boot pool. >> >> 2. Somehow (I don't want to go into any technical details here) arrange that >> your root pool has /boot/zfs/zpool.cache that describes your boot pool. This is >> probably hard given that your /boot is a symlink at the moment. This probably >> would be easier to achieve if zpool.cache lived in /etc/zfs. >> >> 3. [my favorite] Remove an artificial difference between your boot and root >> pools, so that they are a single root+boot pool (as zfs gods intended). As far >> as I understand your setup, you use GELI to protect some sensitive data. >> Apparently your kernel is not sensitive data, so I wonder if your /bin/sh or >> /sbin/init are really sensitive either. >> So perhaps you can arrange your unencrypted pool to hold all of the base system >> (boot + root) and put all your truly sensitive filesystems (like e.g. /home or >> /var/data or /opt/xyz) onto your encrypted pool. > > If all you care about is laptop being stolen, then that would work. > > If you however want to be protected from someone replacing your /sbin/init > with something evil then you use encryption or even better integrity > verification also supported by GELI. There are different ways to ensure that. Including storing cryptographic checksums in a safe place or keeping init in the same place where kernel is kept. And probably many more. > Remember, tools not policies. I am not trying to enforce any policy on end-users here. > There is also option number 4 - backing out your commit. That's definitely an option. I'll discuss it a few lines below. > When I saw your commit removing those entries from defaults/loader.conf, > I thought it is fine, as we now don't require zpool.cache to import the > root pool, which was, BTW, very nice and handy improvement. Now that we > know it breaks existing installations I'd prefer the commit to be backed > out. "breaks" sounds dramatic, but let's take a step back and see what exactly is broken. The system in question still can boot without a problem, it is fully usable and it is possible to change its configuration without any hassle. The only thing that changed is that its boot pool is not imported automatically. Let's also recall that the system was not created / configured by any of the existing official or semi-official tools and thus it does not represent any recommended way of setting up such systems. Glen configured it this way, but it doesn't mean that that is the way. I think that there are many of ways of changing configuration of that system to make behave as before again. Three I mentioned already. Another is to add rc script to import the boot pool, given that it is a special, designated pool. Yet another is to place zpool.cache onto the root pool and use nullfs (instead of a symlink) to make /boot be from the boot pool but /boot/zfs be from the root pool. > This is because apart from breaking some existing installations it >> doesn't gain us anything. I think I addressed the "breaking" part, as to the gains - a few lines below. >> So I understand that my change causes a problem for a setup like yours, but I >> believe that the change is correct. > > The change is clearly incorrect or incomplete as it breaks existing > installations and doesn't allow for full disk encryption configuration > on ZFS-only systems. I think I addressed the breaking part and also addressed your overly general statement about full disk encryption. So I don't think that my change is "clearly incorrect", otherwise that would be clear even to me. > BTW. If moving zpool.cache to /etc/zfs/ will work for both cases that's > fine by me, although the migration might be tricky. Yes, that's migration that's scary to me too. Now, about the postponed points. I will reproduce a section from my email that you've snipped. >> P.S. >> ZFS/FreeBSD boot process is extremely flexible. For example zfsboot can take >> zfsloader from pool1/fsA, zfsloader can boot kernel from pool2/fsB and kernel >> can mount / from pool3/fsC. Of these 3 filesystems from where should >> zpool.cache be taken? >> My firm opinion is that it should be taken from / (pool3/fsC in the example >> above). Because it is the root filesystem that defines what a system is going >> to do ultimately: what daemons are started, with what configurations, etc. >> And thus it should also determine what pools to auto-import. >> We can say that zpool.cache is analogous to /etc/fstab in this respect. So do you or do you not agree with my reasoning about from where zpool.cache should be taken? If you do not, then please explain why. If you do, then please explain how this would be compatible with the old way of loading zpool.cache. I think that ensuring that zpool.cache is always loaded from a root filesystem is the gain from my change. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Jul 24 12:29:03 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C9D142CE; Wed, 24 Jul 2013 12:29:03 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B25492D23; Wed, 24 Jul 2013 12:29:02 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA20838; Wed, 24 Jul 2013 15:29:01 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V1yBg-0008Gv-Nz; Wed, 24 Jul 2013 15:29:00 +0300 Message-ID: <51EFC854.3090908@FreeBSD.org> Date: Wed, 24 Jul 2013 15:28:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Baldwin Subject: Re: VOP_MKDIR/VOP_CREATE and namecache References: <51E968FC.20905@FreeBSD.org> <201307221110.32011.jhb@freebsd.org> In-Reply-To: <201307221110.32011.jhb@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 12:29:03 -0000 on 22/07/2013 18:10 John Baldwin said the following: > On Friday, July 19, 2013 12:27:40 pm Andriy Gapon wrote: >> >> Should VOP_MKDIR and VOP_CREATE immediately insert newly created vnodes into the >> namecache? If yes, where would it be done best? FS code, VFS code, VOP >> post-hooks, something else? > > Hmm, I'm not sure. However, if it is done, I think it needs to be done in the > FS code (e.g., NFS needs to be able to add it's special timestamps). > > In UFS you could do this by just adding a cache_enter() call to ufs_direnter(). > For NFS you would want the post-op attrs from the RPC reply (assuming it includes > attrs for the parent directory). > I've read this as "don't bother" :-) Thank you for the feedback! -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Jul 24 13:06:00 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7BD94EC9; Wed, 24 Jul 2013 13:06:00 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 55D6C2EB5; Wed, 24 Jul 2013 13:06:00 +0000 (UTC) Received: from [10.1.3.5] (cnet520-windstream.mcclatchyinteractive.com [166.108.16.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id 75C721A0638; Wed, 24 Jul 2013 13:05:54 +0000 (UTC) Message-ID: <51EFD131.4090004@mail.lifanov.com> Date: Wed, 24 Jul 2013 09:05:53 -0400 From: Nikolai Lifanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: avg@FreeBSD.org Subject: Re: freebsd-fs Digest, Vol 527, Issue 3 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-rc@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:06:00 -0000 On 07/24/13 08:00, freebsd-fs-request@freebsd.org wrote: > Send freebsd-fs mailing list submissions to > freebsd-fs@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > or, via email, send a message with subject or body 'help' to > freebsd-fs-request@freebsd.org > > You can reach the person managing the list at > freebsd-fs-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-fs digest..." > > > Today's Topics: > > 1. Revisiting an old problem.. zfs snapshots and file name too > long (Andreas Tyrosvoutis) > 2. Bug in FUSE unmounting (Nathan Whitehorn) > 3. rc.d support for zfs boot environments (Andriy Gapon) > 4. Re: [SOLVED] Re: Shutdown problem with an USB memory stick as > ZFS cache device (Ronald Klop) > 5. Re: r253070 and "disappearing" zpool (Andriy Gapon) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 23 Jul 2013 19:48:01 +0300 > From: Andreas Tyrosvoutis > To: freebsd-fs@freebsd.org > Subject: Revisiting an old problem.. zfs snapshots and file name too > long > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > Hi there everyone, I wanted to see what has been discovered regarding this > issue. This particular issue has been around since at least 2008. > > http://lists.freebsd.org/pipermail/freebsd-fs/2008-November/005286.html > > A little bit of response and progress noted here: > > http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007960.html > http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007964.html > http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007972.html > http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007974.html > > > "Such change will break ABI compatibility with tools compiled on previous > FreeBSD versions. As you can see in sys/sys/mount.h this is the reason > we still keep ostatfs structure. *I'll discuss the possibilities with > other FreeBSD committers and we will see what we can do about it.*" > > As far as I can tell, this problem has not been addressed in a > satisfactory way, and still exists today. > > nas4free: snapshot # uname -a > > FreeBSD nas4free.office.pytheasgroup.com 9.1-RELEASE-p3 FreeBSD > 9.1-RELEASE-p3 #0 r251670M: Thu Jun 13 01:59:24 CEST 2013 > root@dev.nas4free.org:/usr/obj/nas4free/usr/src/sys/NAS4FREE-amd64 > amd64 > > nas4free: snapshot # pwd > > /mnt/usb-backup/Daily-Backups/mypool/home/andreas/.zfs/snapshot > > nas4free: snapshot # ls > > ls: 20130721_1829_autosnap_HOURLY: File name too long > > ls: 20130721_2330_autosnap_HOURLY: File name too long > > ls: 20130722_0936_autosnap_HOURLY: File name too long > > ls: 20130722_1221_autosnap_HOURLY: File name too long > > etc.... > > Not being able to use arbitrarily named snapshots or any tools in > .zfs/snapshot folders containing such long named (72 characters? ) > snapshots seems a bit, contrary to the ZFS philosophy of (almost) > unreachable limits. > > The problem is, I don't know what ABI and ostatfs or any of that is. > Or what can actually be done about the problem. It would be handy if > someone who is in the know, could definitively declare the issues > ability to be, or not to be resolved. And perhaps if it can, I'd like > to push it in the right direction. Otherwise it appears to be that BSD > and ZFS are not really fully integrated. > > What do I know though. :) > > > ------------------------------ > > Message: 2 > Date: Tue, 23 Jul 2013 22:31:30 -0500 > From: Nathan Whitehorn > To: freebsd-fs@freebsd.org > Subject: Bug in FUSE unmounting > Message-ID: <51EF4A92.1090203@freebsd.org> > Content-Type: text/plain; CHARSET=US-ASCII > > I ran across a bug in our FUSE port today. The unmount code in libfuse > (mount_bsd.c) uses umount -f to unmount a file system. To do this, it > looks up the device name corresponding to the process's communication > file descriptor, calls getdevname() on it, and then passes that to > umount. The problem here is that the device is always /dev/fuse (it > seems to assume there is a number on the end) and, as a result, it will > forcibly unmount *all* FUSE systems when trying just to unmount one. > > Using the mountpoint instead seems to work for me, but a better solution > is called for. > -Nathan > > > ------------------------------ > > Message: 3 > Date: Wed, 24 Jul 2013 13:54:12 +0300 > From: Andriy Gapon > To: freebsd-fs@FreeBSD.org, freebsd-rc@FreeBSD.org > Subject: rc.d support for zfs boot environments > Message-ID: <51EFB254.8070807@FreeBSD.org> > Content-Type: text/plain; charset=X-VIET-VPS > > > I would like to add another rc.d script or extend the current rc.d/zfs script > for enhanced support of ZFS boot environments. > > To be short, a ZFS boot environment is a filesystem that typically has loader, > kernel and can be mounted as a root filesystem. By having multiple filesystems > of this kind a user can easily select which one to boot to. This allows for > things like having known good configurations, easily recovering from failed > upgrades, experimenting with new code, etc. > > One of the features of boot environments is support for subordinate filesystems. > For example: > NAME MOUNTPOINT CANMOUNT > pond/ROOT/20130331 /pond/ROOT/20130331 noauto > pond/ROOT/20130331/usr /usr off > pond/ROOT/20130331/usr/local /usr/local noauto > pond/ROOT/20130331/usr/local/etc /usr/local/etc noauto > pond/ROOT/kms /pond/ROOT/kms noauto > pond/ROOT/kms/usr /usr off > pond/ROOT/kms/usr/local /usr/local noauto > pond/ROOT/kms/usr/local/etc /usr/local/etc noauto > > 20130331 and kms are two boot environments here. > .../usr, .../usr/local, .../usr/local/etc are their subordinate datasets / > filesystems. > The idea is that one can have filesystems that are tied to a boot environment. > These filesystems hold files that must be in the boot environment but they are > better to be stored in a different filesystem than the main one. There can be > different reasons for this like a need for different ZFS properties or > convenience of separate management (snapshots, cloning, etc). > > Because these filesystems should not be automatically mounted during boot they > are configured with canmount=noauto. The root filesystem is mounted > automatically by the kernel. But the subordinate filesystems are not mounted by > rc.d/zfs -> zfs mount -a because of the canmount property. So they need to be > mounted explicitly. > > Below is a patch that I have for this case. > I would like to ask both fs@ and rc@ communities to review the patch for > correctness, soundness and style. I will appreciate any suggestions and comments. > If you are already using boot environments and think that you may need to use > subordinate datasets, then testing is most welcome too. > > commit df1df94f75a13f611a8234b01bfb9d6b43172c45 > Author: Andriy Gapon > Date: Sun Jul 7 21:01:27 2013 +0300 > > rc.d/zfsbe: a new script designed for boot environment support > > currently it ensures that subordinate datasets are mounted at the > right points. > > diff --git a/etc/rc.d/zfs b/etc/rc.d/zfs > index 598723a..3c40043 100755 > --- a/etc/rc.d/zfs > +++ b/etc/rc.d/zfs > @@ -4,7 +4,7 @@ > # > > # PROVIDE: zfs > -# REQUIRE: mountcritlocal > +# REQUIRE: zfsbe > > . /etc/rc.subr > > diff --git a/etc/rc.d/zfsbe b/etc/rc.d/zfsbe > new file mode 100755 > index 0000000..9e4c50e > --- /dev/null > +++ b/etc/rc.d/zfsbe > @@ -0,0 +1,70 @@ > +#!/bin/sh > +# > +# $FreeBSD$ > +# > + > +# PROVIDE: zfsbe > +# REQUIRE: mountcritlocal > + > +# Handle boot environment subordinate filesystems > +# that may have canmount property set to noauto. > +# For these filesystems mountpoint relative to / > +# must be the same as their dataset name relative > +# to BE root dataset. > + > +. /etc/rc.subr > + > +name="zfsbe" > +rcvar="zfs_enable" > +start_cmd="be_start" > +stop_cmd="be_stop" > +required_modules="zfs" > + > +mount_subordinate() > +{ > + local _be > + > + _be=$1 > + zfs list -rH -o mountpoint,name,canmount -s mountpoint -t filesystem $_be | \ > + while read _mp _name _canmount ; do > + [ "$_canmount" = "off" ] && continue > + case "$_mp" in > + "") > + ;; > + "legacy") > + ;; > + "/") > + ;; > + "/$_be") > + ;; > + "/$_be/"*) > + mount -t zfs $_name ${_mp#/$_be} > + ;; > + *) > + zfs mount $_name > + ;; > + esac > + done > +} > + > +be_start() > +{ > + if [ `$SYSCTL_N security.jail.jailed` -eq 1 ]; then > + : > + else > + mount -p | while read _dev _mp _type _rest; do > + [ $_mp = "/" ] || continue > + if [ $_type = "zfs" ] ; then > + mount_subordinate $_dev > + fi > + break > + done > + fi > +} > + > +be_stop() > +{ > +} > + > +load_rc_config $name > +run_rc_command "$1" > You might check out the logic in the excellent sysutils/beadm port. It's all shell and doesn't actually need rc support or even use it. However, loader(8) support for selecting a boot environment would be really useful. - Nikolai Lifanov From owner-freebsd-fs@FreeBSD.ORG Wed Jul 24 13:13:28 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EF10D4E9 for ; Wed, 24 Jul 2013 13:13:28 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 46F652F18 for ; Wed, 24 Jul 2013 13:13:28 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA21590; Wed, 24 Jul 2013 16:13:20 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V1ysZ-0008Lg-Pd; Wed, 24 Jul 2013 16:13:19 +0300 Message-ID: <51EFD2B7.4010001@FreeBSD.org> Date: Wed, 24 Jul 2013 16:12:23 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nikolai Lifanov Subject: Re: freebsd-fs Digest, Vol 527, Issue 3 References: <51EFD131.4090004@mail.lifanov.com> In-Reply-To: <51EFD131.4090004@mail.lifanov.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:13:29 -0000 on 24/07/2013 16:05 Nikolai Lifanov said the following: > You might check out the logic in the excellent sysutils/beadm port. Thank you for the suggestion. beadm has some bugs regarding subordinate support. > It's all shell and doesn't actually need rc support or even use it. I do not see why beadm would need or use rc support given that it is an administration utility. My rc script is for filesystem mounting during boot. > However, loader(8) support for selecting a boot environment would be really useful. It is there, although not very obvious and not properly documented. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Jul 24 13:50:05 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 31044DF6 for ; Wed, 24 Jul 2013 13:50:05 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 62B99208E for ; Wed, 24 Jul 2013 13:50:03 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA22436; Wed, 24 Jul 2013 16:49:56 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V1zRz-0008Om-NU; Wed, 24 Jul 2013 16:49:55 +0300 Message-ID: <51EFDB4C.90401@FreeBSD.org> Date: Wed, 24 Jul 2013 16:49:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nikolai Lifanov , freebsd-fs@FreeBSD.org Subject: Re: freebsd-fs Digest, Vol 527, Issue 3 References: <51EFD131.4090004@mail.lifanov.com> <51EFD2B7.4010001@FreeBSD.org> <51EFD6F9.7090303@mail.lifanov.com> In-Reply-To: <51EFD6F9.7090303@mail.lifanov.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:50:05 -0000 on 24/07/2013 16:30 Nikolai Lifanov said the following: > This is very interesting... > When I need to do this, I just set vfs.root.mountfrom= from the loader command > line. That's almost it. > If there is something else, could you point me to it please? http://ru.kyivbsd.org.ua/arhiv/2012/kyivbsd12-gapon-zfs.pdf?attredirects=0&d=1 Pages 17-22. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Jul 24 13:55:42 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1C203ECB; Wed, 24 Jul 2013 13:55:42 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF31320C4; Wed, 24 Jul 2013 13:55:40 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r6ODtUVq025161 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 06:55:32 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51EFDCCC.4040205@freebsd.org> Date: Wed, 24 Jul 2013 21:55:24 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: rc.d support for zfs boot environments References: <51EFB254.8070807@FreeBSD.org> In-Reply-To: <51EFB254.8070807@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@FreeBSD.org, freebsd-rc@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:55:42 -0000 On 7/24/13 6:54 PM, Andriy Gapon wrote: > I would like to add another rc.d script or extend the current rc.d/zfs script > for enhanced support of ZFS boot environments. isn't this what PC-BSD are working on? > > To be short, a ZFS boot environment is a filesystem that typically has loader, > kernel and can be mounted as a root filesystem. By having multiple filesystems > of this kind a user can easily select which one to boot to. This allows for > things like having known good configurations, easily recovering from failed > upgrades, experimenting with new code, etc. > > One of the features of boot environments is support for subordinate filesystems. > For example: > NAME MOUNTPOINT CANMOUNT > pond/ROOT/20130331 /pond/ROOT/20130331 noauto > pond/ROOT/20130331/usr /usr off > pond/ROOT/20130331/usr/local /usr/local noauto > pond/ROOT/20130331/usr/local/etc /usr/local/etc noauto > pond/ROOT/kms /pond/ROOT/kms noauto > pond/ROOT/kms/usr /usr off > pond/ROOT/kms/usr/local /usr/local noauto > pond/ROOT/kms/usr/local/etc /usr/local/etc noauto > > 20130331 and kms are two boot environments here. > .../usr, .../usr/local, .../usr/local/etc are their subordinate datasets / > filesystems. > The idea is that one can have filesystems that are tied to a boot environment. > These filesystems hold files that must be in the boot environment but they are > better to be stored in a different filesystem than the main one. There can be > different reasons for this like a need for different ZFS properties or > convenience of separate management (snapshots, cloning, etc). > > Because these filesystems should not be automatically mounted during boot they > are configured with canmount=noauto. The root filesystem is mounted > automatically by the kernel. But the subordinate filesystems are not mounted by > rc.d/zfs -> zfs mount -a because of the canmount property. So they need to be > mounted explicitly. > > Below is a patch that I have for this case. > I would like to ask both fs@ and rc@ communities to review the patch for > correctness, soundness and style. I will appreciate any suggestions and comments. > If you are already using boot environments and think that you may need to use > subordinate datasets, then testing is most welcome too. > > commit df1df94f75a13f611a8234b01bfb9d6b43172c45 > Author: Andriy Gapon > Date: Sun Jul 7 21:01:27 2013 +0300 > > rc.d/zfsbe: a new script designed for boot environment support > > currently it ensures that subordinate datasets are mounted at the > right points. > > diff --git a/etc/rc.d/zfs b/etc/rc.d/zfs > index 598723a..3c40043 100755 > --- a/etc/rc.d/zfs > +++ b/etc/rc.d/zfs > @@ -4,7 +4,7 @@ > # > > # PROVIDE: zfs > -# REQUIRE: mountcritlocal > +# REQUIRE: zfsbe > > . /etc/rc.subr > > diff --git a/etc/rc.d/zfsbe b/etc/rc.d/zfsbe > new file mode 100755 > index 0000000..9e4c50e > --- /dev/null > +++ b/etc/rc.d/zfsbe > @@ -0,0 +1,70 @@ > +#!/bin/sh > +# > +# $FreeBSD$ > +# > + > +# PROVIDE: zfsbe > +# REQUIRE: mountcritlocal > + > +# Handle boot environment subordinate filesystems > +# that may have canmount property set to noauto. > +# For these filesystems mountpoint relative to / > +# must be the same as their dataset name relative > +# to BE root dataset. > + > +. /etc/rc.subr > + > +name="zfsbe" > +rcvar="zfs_enable" > +start_cmd="be_start" > +stop_cmd="be_stop" > +required_modules="zfs" > + > +mount_subordinate() > +{ > + local _be > + > + _be=$1 > + zfs list -rH -o mountpoint,name,canmount -s mountpoint -t filesystem $_be | \ > + while read _mp _name _canmount ; do > + [ "$_canmount" = "off" ] && continue > + case "$_mp" in > + "") > + ;; > + "legacy") > + ;; > + "/") > + ;; > + "/$_be") > + ;; > + "/$_be/"*) > + mount -t zfs $_name ${_mp#/$_be} > + ;; > + *) > + zfs mount $_name > + ;; > + esac > + done > +} > + > +be_start() > +{ > + if [ `$SYSCTL_N security.jail.jailed` -eq 1 ]; then > + : > + else > + mount -p | while read _dev _mp _type _rest; do > + [ $_mp = "/" ] || continue > + if [ $_type = "zfs" ] ; then > + mount_subordinate $_dev > + fi > + break > + done > + fi > +} > + > +be_stop() > +{ > +} > + > +load_rc_config $name > +run_rc_command "$1" > > > > _______________________________________________ > 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 Wed Jul 24 14:02:57 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 241F427C; Wed, 24 Jul 2013 14:02:57 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E3C022124; Wed, 24 Jul 2013 14:02:55 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA22609; Wed, 24 Jul 2013 17:02:54 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V1zeX-0008QC-Q4; Wed, 24 Jul 2013 17:02:53 +0300 Message-ID: <51EFDE3D.6020107@FreeBSD.org> Date: Wed, 24 Jul 2013 17:01:33 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Julian Elischer Subject: Re: rc.d support for zfs boot environments References: <51EFB254.8070807@FreeBSD.org> <51EFDCCC.4040205@freebsd.org> In-Reply-To: <51EFDCCC.4040205@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-rc@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 14:02:57 -0000 on 24/07/2013 16:55 Julian Elischer said the following: > On 7/24/13 6:54 PM, Andriy Gapon wrote: >> I would like to add another rc.d script or extend the current rc.d/zfs script >> for enhanced support of ZFS boot environments. > > isn't this what PC-BSD are working on? What is 'this' exactly? An rc script? In either case, I have no clue. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Jul 25 02:13:16 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 25606B8F; Thu, 25 Jul 2013 02:13:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E7FE0260D; Thu, 25 Jul 2013 02:13:14 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r6P2D3Hl002024 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 19:13:11 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <51F089AB.4040505@elischer.org> Date: Thu, 25 Jul 2013 10:12:59 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: rc.d support for zfs boot environments References: <51EFB254.8070807@FreeBSD.org> <51EFDCCC.4040205@freebsd.org> <51EFDE3D.6020107@FreeBSD.org> In-Reply-To: <51EFDE3D.6020107@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-rc@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 02:13:16 -0000 On 7/24/13 10:01 PM, Andriy Gapon wrote: > on 24/07/2013 16:55 Julian Elischer said the following: >> On 7/24/13 6:54 PM, Andriy Gapon wrote: >>> I would like to add another rc.d script or extend the current rc.d/zfs script >>> for enhanced support of ZFS boot environments. >> isn't this what PC-BSD are working on? > What is 'this' exactly? An rc script? > In either case, I have no clue. > I believe they are setting up an infrastructure to support ZFS boot environments, including rc components and such. From owner-freebsd-fs@FreeBSD.ORG Thu Jul 25 02:18:35 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BD7D4C78 for ; Thu, 25 Jul 2013 02:18:35 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 512072642 for ; Thu, 25 Jul 2013 02:18:35 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id t57so96993wes.24 for ; Wed, 24 Jul 2013 19:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=laaXxzuC8JtY7Qmq3dkzaBunxG7Iv1YwXKeHY5+GJV0=; b=qIhdYOrA/yfC0k3VwlGWjRX2kYDf3Sx+A3bNCXk7eeitIlMc6Snm++yCsP65w5Ryor pmFHerZkx0txNfOAsX52VAdySNNOaINO12kfagLUQaWJ5T3+bXPjSK+cOczSQcwbmcXY +IaYBu4MXXtD2d6TR9ghA8Zer6ydLZE1eI0FIkQEf6dvHFrTg5nS/kYtFgmWf4p+QZAI useCDjNMwovhGiMyzo4tDhmV7UmieGe5tJLkEX6437tyZ8Wg9T51qS0R0QIy+ez4sab5 s6uFmWYKL8eS0bqSIelKAIkuf697lEwwjW85daiuuhi65SMNgham3u5+FI79jdMgR6my s8PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=laaXxzuC8JtY7Qmq3dkzaBunxG7Iv1YwXKeHY5+GJV0=; b=kHb21UsvX9zC9VbSr+UiJxhBzTVlbd8J99vN19I1OiGd6lyu50vQyuawB8OvSZKCKz +pCcYU1QnWXgzhhU80To8Pb6xbX1+FzgPIOUtIoxO1cZrhsQR7giKS1L6c0aVeg6EyHV fqhBcJzPp7CgppaoVwHzyW35aHQkWv+vjEwUp6CabN28wCB3Tispkd3wAbovT1vkpL+q 7winpgTsLuHCvwwG8qmMPyX+ewk7vdFluYyBgEOkJo3UcmfSW80HkFsCXdN/urYlzTCG gjxQhjtPnIHExssUMsrtXcFakps0guoktBYWDunMZGVF6WY1ZcokHcliiSqYm9CPV3W3 ZEBQ== MIME-Version: 1.0 X-Received: by 10.180.126.2 with SMTP id mu2mr261628wib.63.1374718713587; Wed, 24 Jul 2013 19:18:33 -0700 (PDT) Received: by 10.216.214.198 with HTTP; Wed, 24 Jul 2013 19:18:33 -0700 (PDT) Date: Thu, 25 Jul 2013 10:18:33 +0800 Message-ID: Subject: Samba + ZFS + sendfile() From: Marcelo Araujo To: "freebsd-fs@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 02:18:35 -0000 Hello Guys, I'm doing some benchmarks and also implement a new syscal recvfile() for zero copy. Pretty much similar like sendfile(2). However, using sendfile with Samba + ZFS has a very bad performance if we compare with Samba + sendfile() + UFS. I asked some people and they said it is because the data is cached twice once in ARC and in a second time on VFS cache. I got really confused with this approach, and I'm wondering if someone could give me some explanation how it happens. Best Regards, -- Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Thu Jul 25 07:53:52 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BF4FA112; Thu, 25 Jul 2013 07:53:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A00972349; Thu, 25 Jul 2013 07:53:51 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA04458; Thu, 25 Jul 2013 10:53:45 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V2GMq-000Cl6-UZ; Thu, 25 Jul 2013 10:53:44 +0300 Message-ID: <51F0D963.8010000@FreeBSD.org> Date: Thu, 25 Jul 2013 10:53:07 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Julian Elischer Subject: Re: rc.d support for zfs boot environments References: <51EFB254.8070807@FreeBSD.org> <51EFDCCC.4040205@freebsd.org> <51EFDE3D.6020107@FreeBSD.org> <51F089AB.4040505@elischer.org> In-Reply-To: <51F089AB.4040505@elischer.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-rc@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 07:53:52 -0000 on 25/07/2013 05:12 Julian Elischer said the following: > On 7/24/13 10:01 PM, Andriy Gapon wrote: >> on 24/07/2013 16:55 Julian Elischer said the following: >>> On 7/24/13 6:54 PM, Andriy Gapon wrote: >>>> I would like to add another rc.d script or extend the current rc.d/zfs script >>>> for enhanced support of ZFS boot environments. >>> isn't this what PC-BSD are working on? >> What is 'this' exactly? An rc script? >> In either case, I have no clue. >> > I believe they are setting up an infrastructure to support ZFS boot > environments, including rc components and such. > Ah cool, I didn't know about that. There was a number of contributions from a number of people who made BEs quite usable and convenient already. I hope that iX will make FreeBSD BE support polished and "professional". So I hope that either they comment on the proposed patch or disclose some of their work to the FreeBSD community. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Jul 25 15:34:24 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 81555CDE for ; Thu, 25 Jul 2013 15:34:24 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1530E2F87 for ; Thu, 25 Jul 2013 15:34:23 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1V2NYQ-0001Zo-1g for freebsd-fs@freebsd.org; Thu, 25 Jul 2013 17:34:10 +0200 Received: from ip-109-45-0-12.web.vodafone.de ([109.45.0.12]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Jul 2013 17:34:10 +0200 Received: from johannes by ip-109-45-0-12.web.vodafone.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Jul 2013 17:34:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Subject: Re: r253070 and "disappearing" zpool Date: Thu, 25 Jul 2013 16:33:58 +0100 Lines: 144 Message-ID: References: <20130710180548.GA2151@glenbarber.us> <51ECDF64.2020704@FreeBSD.org> <20130722203853.GB1400@garage.freebsd.pl> <51EFBEBF.601@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip-109-45-0-12.web.vodafone.de User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 In-Reply-To: <51EFBEBF.601@FreeBSD.org> Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 15:34:24 -0000 On 24/07/2013 12:47, Andriy Gapon wrote: > on 22/07/2013 23:38 Pawel Jakub Dawidek said the following: >> On Mon, Jul 22, 2013 at 10:29:40AM +0300, Andriy Gapon wrote: >>> I think that this setup (on ZFS level) is quite untypical, although not >>> impossible on FreeBSD (and perhaps only FreeBSD). >>> It's untypical because you have separate boot pool (where loader, loader.conf >>> and kernel are taken from) and root pool (where "/" is mounted from). >> >> As I said elsewhere, it is pretty typical when full disk encryption is >> used. > > I am judging by the number of reports / amount of feedback so far. I'm using a similar configuration too, where I have a USB stick with unencrypted kernel and /boot bits which load a GELI keyfile (from its own pool zboot), and then the rest of the system starts up from the fully encrypted HDD (from another pool zsystem, so boot and rootfs are on different pools). I'm not sure I understand the problem though. What exactly "broke" after your commit? The pool that contains the bits that would normally go to /boot is not imported automatically, but the rest is working (ie. /boot symlink pointing to nowhere)? Or does booting somehow fail? > >> The /boot/ has to be unencrypted and can be stored on eg. USB >> pendrive which is never left unattended, unlike laptop which can be left >> in eg. a hotel room, but with entire disk encrypted. > > As we discussed elsewhere, there are many options of configuring full disk > encryption. Including decisions whether root filesystem should be separate from > boot filesystem, choice of filesystem type for boot fs, ways of tying various > pieces together, and many more. > > I do not believe that my change is incompatible with full disk encryption in > general. > >>> So, I see three ways of resolving the problem that my changes caused for your >>> configuration. >>> >>> 1. [the easiest] Put zpool.cache loading instructions that used to be in >>> defaults/loader.conf into your loader.conf. This way everything should work as >>> before -- zpool.cache would be loaded from your boot pool. >>> >>> 2. Somehow (I don't want to go into any technical details here) arrange that >>> your root pool has /boot/zfs/zpool.cache that describes your boot pool. This is >>> probably hard given that your /boot is a symlink at the moment. This probably >>> would be easier to achieve if zpool.cache lived in /etc/zfs. >>> >>> 3. [my favorite] Remove an artificial difference between your boot and root >>> pools, so that they are a single root+boot pool (as zfs gods intended). As far >>> as I understand your setup, you use GELI to protect some sensitive data. >>> Apparently your kernel is not sensitive data, so I wonder if your /bin/sh or >>> /sbin/init are really sensitive either. >>> So perhaps you can arrange your unencrypted pool to hold all of the base system >>> (boot + root) and put all your truly sensitive filesystems (like e.g. /home or >>> /var/data or /opt/xyz) onto your encrypted pool. >> >> If all you care about is laptop being stolen, then that would work. >> >> If you however want to be protected from someone replacing your /sbin/init >> with something evil then you use encryption or even better integrity >> verification also supported by GELI. > > There are different ways to ensure that. Including storing cryptographic > checksums in a safe place or keeping init in the same place where kernel is > kept. And probably many more. > >> Remember, tools not policies. > > I am not trying to enforce any policy on end-users here. > >> There is also option number 4 - backing out your commit. > > That's definitely an option. I'll discuss it a few lines below. > >> When I saw your commit removing those entries from defaults/loader.conf, >> I thought it is fine, as we now don't require zpool.cache to import the >> root pool, which was, BTW, very nice and handy improvement. Now that we >> know it breaks existing installations I'd prefer the commit to be backed >> out. > > "breaks" sounds dramatic, but let's take a step back and see what exactly is broken. > The system in question still can boot without a problem, it is fully usable and > it is possible to change its configuration without any hassle. The only thing > that changed is that its boot pool is not imported automatically. > Let's also recall that the system was not created / configured by any of the > existing official or semi-official tools and thus it does not represent any > recommended way of setting up such systems. Glen configured it this way, but it > doesn't mean that that is the way. > > I think that there are many of ways of changing configuration of that system to > make behave as before again. > Three I mentioned already. Another is to add rc script to import the boot pool, > given that it is a special, designated pool. Yet another is to place > zpool.cache onto the root pool and use nullfs (instead of a symlink) to make > /boot be from the boot pool but /boot/zfs be from the root pool. > >> This is because apart from breaking some existing installations it >>> doesn't gain us anything. > > I think I addressed the "breaking" part, as to the gains - a few lines below. > >>> So I understand that my change causes a problem for a setup like yours, but I >>> believe that the change is correct. >> >> The change is clearly incorrect or incomplete as it breaks existing >> installations and doesn't allow for full disk encryption configuration >> on ZFS-only systems. > > I think I addressed the breaking part and also addressed your overly general > statement about full disk encryption. So I don't think that my change is > "clearly incorrect", otherwise that would be clear even to me. > >> BTW. If moving zpool.cache to /etc/zfs/ will work for both cases that's >> fine by me, although the migration might be tricky. > > Yes, that's migration that's scary to me too. > > > Now, about the postponed points. > I will reproduce a section from my email that you've snipped. > >>> P.S. >>> ZFS/FreeBSD boot process is extremely flexible. For example zfsboot can take >>> zfsloader from pool1/fsA, zfsloader can boot kernel from pool2/fsB and kernel >>> can mount / from pool3/fsC. Of these 3 filesystems from where should >>> zpool.cache be taken? >>> My firm opinion is that it should be taken from / (pool3/fsC in the example >>> above). Because it is the root filesystem that defines what a system is going >>> to do ultimately: what daemons are started, with what configurations, etc. >>> And thus it should also determine what pools to auto-import. >>> We can say that zpool.cache is analogous to /etc/fstab in this respect. > > So do you or do you not agree with my reasoning about from where zpool.cache > should be taken? > If you do not, then please explain why. > If you do, then please explain how this would be compatible with the old way of > loading zpool.cache. > > I think that ensuring that zpool.cache is always loaded from a root filesystem > is the gain from my change. > From owner-freebsd-fs@FreeBSD.ORG Thu Jul 25 15:39:38 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 50021F2C; Thu, 25 Jul 2013 15:39:38 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2499B2FCF; Thu, 25 Jul 2013 15:39:37 +0000 (UTC) Received: from glenbarber.us (unknown [IPv6:2001:470:8:120e:1:1:c57c:729]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 6E9FF8DCC; Thu, 25 Jul 2013 15:39:36 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 6E9FF8DCC Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Thu, 25 Jul 2013 11:39:34 -0400 From: Glen Barber To: Johannes Totz Subject: Re: r253070 and "disappearing" zpool Message-ID: <20130725153934.GA2075@glenbarber.us> References: <20130710180548.GA2151@glenbarber.us> <51ECDF64.2020704@FreeBSD.org> <20130722203853.GB1400@garage.freebsd.pl> <51EFBEBF.601@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 15:39:38 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 25, 2013 at 04:33:58PM +0100, Johannes Totz wrote: > On 24/07/2013 12:47, Andriy Gapon wrote: > >on 22/07/2013 23:38 Pawel Jakub Dawidek said the following: > >>On Mon, Jul 22, 2013 at 10:29:40AM +0300, Andriy Gapon wrote: > >>>I think that this setup (on ZFS level) is quite untypical, although not > >>>impossible on FreeBSD (and perhaps only FreeBSD). > >>>It's untypical because you have separate boot pool (where loader, load= er.conf > >>>and kernel are taken from) and root pool (where "/" is mounted from). > >> > >>As I said elsewhere, it is pretty typical when full disk encryption is > >>used. > > > >I am judging by the number of reports / amount of feedback so far. >=20 > I'm using a similar configuration too, where I have a USB stick with > unencrypted kernel and /boot bits which load a GELI keyfile (from > its own pool zboot), and then the rest of the system starts up from > the fully encrypted HDD (from another pool zsystem, so boot and > rootfs are on different pools). >=20 > I'm not sure I understand the problem though. What exactly "broke" > after your commit? The pool that contains the bits that would > normally go to /boot is not imported automatically, but the rest is > working (ie. /boot symlink pointing to nowhere)? Or does booting > somehow fail? >=20 "/boot" disappears and becomes a broken symlink. Glen --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJR8Ua2AAoJEFJPDDeguUajZLAH/3W+Z8J31TL8M5hG7lj0cPwB OsT/lehsktd/rD4TYgefUCxQiVBikIIElXLb4+jorW1v/Ml7TzigzMeoy5+PwfoF iewRyniyYcmMapGzB9g59UcJ+KD52WdILUyiM0f2pxB/ZKPIhnYcz83iRyqhxJQm v57DLisjhfOFRCdimXKy2jUdet9yv+fwe2y8rddr+NFSpLcaCzG/ewoQfrBPQQfP UqLDGgV0/Bvu9kqD/SeKNe9u0W/6yZHA4OmvKlkvn8778ODu2CbqaB2upnuSVJZe rHdPc9bY2U3+cGXULV6HTrU0twab4+UG6qzGJTD4X4q8K2Mg4ehX5wUmV0htMas= =HngW -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-freebsd-fs@FreeBSD.ORG Thu Jul 25 16:04:39 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 302CF8B8; Thu, 25 Jul 2013 16:04:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 080712118; Thu, 25 Jul 2013 16:04:39 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ED311B926; Thu, 25 Jul 2013 12:04:37 -0400 (EDT) From: John Baldwin To: Andriy Gapon Subject: Re: VOP_MKDIR/VOP_CREATE and namecache Date: Wed, 24 Jul 2013 15:52:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <51E968FC.20905@FreeBSD.org> <201307221110.32011.jhb@freebsd.org> <51EFC854.3090908@FreeBSD.org> In-Reply-To: <51EFC854.3090908@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201307241552.09988.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 25 Jul 2013 12:04:38 -0400 (EDT) Cc: freebsd-fs@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 16:04:39 -0000 On Wednesday, July 24, 2013 8:28:04 am Andriy Gapon wrote: > on 22/07/2013 18:10 John Baldwin said the following: > > On Friday, July 19, 2013 12:27:40 pm Andriy Gapon wrote: > >> > >> Should VOP_MKDIR and VOP_CREATE immediately insert newly created vnodes into the > >> namecache? If yes, where would it be done best? FS code, VFS code, VOP > >> post-hooks, something else? > > > > Hmm, I'm not sure. However, if it is done, I think it needs to be done in the > > FS code (e.g., NFS needs to be able to add it's special timestamps). > > > > In UFS you could do this by just adding a cache_enter() call to ufs_direnter(). > > For NFS you would want the post-op attrs from the RPC reply (assuming it includes > > attrs for the parent directory). > > > > I've read this as "don't bother" :-) > Thank you for the feedback! Well, for UFS it would be a one-line change. If there is a common workload where this would help it might be interesting to benchmark. Note that UFS is careful to prime new directory entries into the existing dirhash for example (which may make priming the namecache less of a win for UFS). -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Thu Jul 25 19:47:30 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 64E09B2D; Thu, 25 Jul 2013 19:47:30 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 571162C58; Thu, 25 Jul 2013 19:47:27 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id AC1881E5; Thu, 25 Jul 2013 21:42:21 +0200 (CEST) Date: Thu, 25 Jul 2013 21:48:03 +0200 From: Pawel Jakub Dawidek To: Andriy Gapon Subject: Re: r253070 and "disappearing" zpool Message-ID: <20130725194803.GA1400@garage.freebsd.pl> References: <20130710180548.GA2151@glenbarber.us> <51ECDF64.2020704@FreeBSD.org> <20130722203853.GB1400@garage.freebsd.pl> <51EFBEBF.601@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <51EFBEBF.601@FreeBSD.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org, Glen Barber , FreeBSD Current X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 19:47:30 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2013 at 02:47:11PM +0300, Andriy Gapon wrote: > on 22/07/2013 23:38 Pawel Jakub Dawidek said the following: > > The /boot/ has to be unencrypted and can be stored on eg. USB > > pendrive which is never left unattended, unlike laptop which can be left > > in eg. a hotel room, but with entire disk encrypted. >=20 > As we discussed elsewhere, there are many options of configuring full disk > encryption. Including decisions whether root filesystem should be separa= te from > boot filesystem, choice of filesystem type for boot fs, ways of tying var= ious > pieces together, and many more. >=20 > I do not believe that my change is incompatible with full disk encryption= in > general. Maybe you can imagine many ways of configuring it, but definiately the most typical one is to have separate /boot/ from /, where /boot/ is unencrypted and where you use one file system type for both (UFS or ZFS). > Let's also recall that the system was not created / configured by any of = the > existing official or semi-official tools and thus it does not represent a= ny > recommended way of setting up such systems. Glen configured it this way,= but it > doesn't mean that that is the way. Note that there are no official tools to install FreeBSD on ZFS. Is that enough reason to stop supporting it? What Glen did is the recommended way of setting up full disk encryption with ZFS. I'd do it the same way and I'd recommend this configuration to anyone who will (or did) ask me. > I think that there are many of ways of changing configuration of that sys= tem to > make behave as before again. > Three I mentioned already. Another is to add rc script to import the boo= t pool, > given that it is a special, designated pool. Yet another is to place > zpool.cache onto the root pool and use nullfs (instead of a symlink) to m= ake > /boot be from the boot pool but /boot/zfs be from the root pool. Come on... > > BTW. If moving zpool.cache to /etc/zfs/ will work for both cases that's > > fine by me, although the migration might be tricky. >=20 > Yes, that's migration that's scary to me too. >=20 >=20 > Now, about the postponed points. > I will reproduce a section from my email that you've snipped. >=20 > >> P.S. > >> ZFS/FreeBSD boot process is extremely flexible. For example zfsboot c= an take > >> zfsloader from pool1/fsA, zfsloader can boot kernel from pool2/fsB and= kernel > >> can mount / from pool3/fsC. Of these 3 filesystems from where should > >> zpool.cache be taken? > >> My firm opinion is that it should be taken from / (pool3/fsC in the ex= ample > >> above). Because it is the root filesystem that defines what a system = is going > >> to do ultimately: what daemons are started, with what configurations, = etc. > >> And thus it should also determine what pools to auto-import. > >> We can say that zpool.cache is analogous to /etc/fstab in this respect. >=20 > So do you or do you not agree with my reasoning about from where zpool.ca= che > should be taken? > If you do not, then please explain why. > If you do, then please explain how this would be compatible with the old = way of > loading zpool.cache. I don't have a strong opinion about this. As I said above I'm fine with moving zpool.cache to /etc/zfs/ if we can ensure it won't break existing installations. Still I'm not sure this was your initial goal, because you weren't aware of systems with separate boot pool until recently (if you were aware of this I hope you wouldn't commit the change without prior discussion). Which means in your eyes zpool.cache was always part of the root pool, because /boot/ was. > I think that ensuring that zpool.cache is always loaded from a root files= ystem > is the gain from my change. Were people complaining about zpool.cache being loaded from /boot/zfs/ and not from /etc/zfs/? I don't think so. But people do complain about boot pool not being autoimported. In my opinion for the end user it doesn't really matter if it is /etc/zfs/zpool.cache or /boot/zfs/zpool.cache, as both directories are available once the system is booted. For most people those two directories are placed on the same file system. For some people who actually care if this is /etc/zfs/ or /boot/zfs/, because those are separate file systems the latter works, the former doesn't. In my opinion the gain, if any, is only theoretical. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHxgPMACgkQForvXbEpPzReWQCgkMDxrjg0k3SuZ6aWKb4kIpiY IB8AoMwG4xOx8ncJX2KGtip2br8AtQjo =bkm1 -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- From owner-freebsd-fs@FreeBSD.ORG Fri Jul 26 09:17:05 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C8EA51D4 for ; Fri, 26 Jul 2013 09:17:05 +0000 (UTC) (envelope-from krh@kirkholz.com.au) Received: from baha.lunarbreeze.com (baha.lunarbreeze.com [67.210.123.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A7B942E08 for ; Fri, 26 Jul 2013 09:17:05 +0000 (UTC) Received: from localhost ([127.0.0.1]:34838 helo=baha.lunarbreeze.com) by baha.lunarbreeze.com with esmtpa (Exim 4.80.1) (envelope-from ) id 1V2dSP-0005WV-NK for freebsd-fs@freebsd.org; Fri, 26 Jul 2013 01:33:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 26 Jul 2013 01:33:01 -0700 From: Kirk Richard Holz To: Subject: Trying to recover 2-element zfs striped (raid0) filesystem Organization: KRH Custom Computing Message-ID: <1b756c89576eb509d1197c4d9ab66fea@kirkholz.com> X-Sender: krh@kirkholz.com.au User-Agent: Roundcube Webmail/0.8.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - baha.lunarbreeze.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - kirkholz.com.au X-Get-Message-Sender-Via: baha.lunarbreeze.com: authenticated_id: krh@kirkholz.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 09:17:05 -0000 I have a server which got hit with some kind of power shock. Clearly it was poorly configured, partially by me -- all I want to do now is get as much data as possible from it. -- # uname -a FreeBSD server 9.1-RELEASE FreeBSD 9.1-RELEASE root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 -- The partition table of one of the two disks in a zfs striped (raid0) array has been corrupted. When the drive's GPT partition table was corrupted it apparently picked up the backup partition table, which wasn't current. I'm not sure how that happened. ZFS / zpool can't bring the filesystem back to full functionality and just hangs instead of producing any kind of verbose diagnostic data. This is what I get from zfs: -- # zpool list -v NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT zShare 2.72T 796G 1.94T 28% 1.00x UNAVAIL - ada1 928G 362G 566G - 8683733800792668130 1.81T 433G 1.39T 16.0E -- Now, ada1 is available, and the 1.81T drive is available, but the 1.81T drive appears like this now: -- Geom name: ada3 modified: false state: OK fwheads: 16 fwsectors: 63 last: 3907029167 first: 63 entries: 4 scheme: MBR Providers: 1. Name: ada3s1 Mediasize: 2000397795328 (1.8T) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r0w0e0 rawtype: 131 length: 2000397795328 offset: 1048576 type: linux-data index: 1 end: 3907028991 start: 2048 Consumers: 1. Name: ada3 Mediasize: 2000398934016 (1.8T) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r0w0e0 -- Drive ada3 is the only candidate for the second element of the filesystem: -- # zpool status -xv pool: zShare state: UNAVAIL status: One or more devices are faulted in response to IO failures. action: Make sure the affected devices are connected, then run 'zpool clear'. see: http://illumos.org/msg/ZFS-8000-HC scan: none requested config: NAME STATE READ WRITE CKSUM zShare UNAVAIL 0 0 0 ada1 ONLINE 0 0 0 8683733800792668130 UNAVAIL 0 0 0 was /dev/ada3s1 errors: Permanent errors have been detected in the following files: zShare:<0x7386> -- I have run zpool clear. I need help with the best queries to pinpoint the problem and attempt recovery. Thank you in advance, Kirk From owner-freebsd-fs@FreeBSD.ORG Fri Jul 26 10:11:06 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 09E8C1C4 for ; Fri, 26 Jul 2013 10:11:06 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 53A792015 for ; Fri, 26 Jul 2013 10:11:04 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA23771; Fri, 26 Jul 2013 13:10:56 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V2ezA-000Hmv-GQ; Fri, 26 Jul 2013 13:10:56 +0300 Message-ID: <51F24AF8.5070106@FreeBSD.org> Date: Fri, 26 Jul 2013 13:10:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kirk Richard Holz Subject: Re: Trying to recover 2-element zfs striped (raid0) filesystem References: <1b756c89576eb509d1197c4d9ab66fea@kirkholz.com> In-Reply-To: <1b756c89576eb509d1197c4d9ab66fea@kirkholz.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 10:11:06 -0000 on 26/07/2013 11:33 Kirk Richard Holz said the following: > When the drive's GPT partition table was corrupted it apparently picked up the > backup partition table, which wasn't current. I'm not sure how that happened. I'd recommend that you do not do any destructive actions. Then try to recall how the disk was partitioned. Then carefully re-create its partitioning setup. If you do everything right your data should be intact and accessible. It would be wise to make a full disk copy of the disk before doing anything with it. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Jul 26 21:44:51 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CD754D6A; Fri, 26 Jul 2013 21:44:51 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A03372218; Fri, 26 Jul 2013 21:44:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6QLip3i038224; Fri, 26 Jul 2013 21:44:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6QLipcR038223; Fri, 26 Jul 2013 21:44:51 GMT (envelope-from linimon) Date: Fri, 26 Jul 2013 21:44:51 GMT Message-Id: <201307262144.r6QLipcR038223@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/180876: [zfs] [hast] ZFS with trim, bio_flush or bio_delete locks hast device write operations X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 21:44:51 -0000 Old Synopsis: ZFS with trim,bio_flush or bio_delete locks hast device write operations New Synopsis: [zfs] [hast] ZFS with trim,bio_flush or bio_delete locks hast device write operations Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jul 26 21:44:29 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=180876 From owner-freebsd-fs@FreeBSD.ORG Fri Jul 26 22:02:18 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6868C408 for ; Fri, 26 Jul 2013 22:02:18 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE88E2306 for ; Fri, 26 Jul 2013 22:02:16 +0000 (UTC) Received: from server.rulingia.com (c220-239-237-213.belrs5.nsw.optusnet.com.au [220.239.237.213]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r6QM26WB056771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 27 Jul 2013 08:02:06 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.7/8.14.7) with ESMTP id r6QM20cn050668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 27 Jul 2013 08:02:00 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.7/8.14.7/Submit) id r6QM1xkK050656; Sat, 27 Jul 2013 08:01:59 +1000 (EST) (envelope-from peter) Date: Sat, 27 Jul 2013 08:01:59 +1000 From: Peter Jeremy To: Kirk Richard Holz Subject: Re: Trying to recover 2-element zfs striped (raid0) filesystem Message-ID: <20130726220159.GI86483@server.rulingia.com> References: <1b756c89576eb509d1197c4d9ab66fea@kirkholz.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK" Content-Disposition: inline In-Reply-To: <1b756c89576eb509d1197c4d9ab66fea@kirkholz.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 22:02:18 -0000 --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Jul-26 01:33:01 -0700, Kirk Richard Holz wrot= e: >The partition table of one of the two disks in a zfs striped (raid0)=20 >array has been corrupted. Once you recover the partition table for ada3, ZFS should be OK (as long as you haven't written too much to the pool). If zShare is your boot device, I strongly recommend booting off alternative media. Ideally, you should take full physical copies of both disks. If you are unable to remember the partition layout, you should be able to recover it by looking for the ZFS vdev labels: Each ZFS vdev has 4 256KiB labels - 2 at the start of the partition and 2 at the end of the partition so locating those will identify the start and end of the partition - if you used the entire disk for ZFS, they will be close to the start & end of the disk and "hd /dev/ada3|less" should be enough to find the first label. The first label on all my vdevs begins: 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |..............= =2E.| * 00003fd0 00 00 00 00 00 00 00 00 11 7a 0c b1 7a da 10 02 |.........z..z.= =2E.| 00003fe0 3f 2a 6e 7f 80 8f f4 97 fc ce aa 58 16 9f 90 af |?*n........X..= =2E.| 00003ff0 8b b4 6d ff 57 ea d1 cb ab 5f 46 0d db 92 c6 6e |..m.W...._F...= =2En| 00004000 01 01 00 00 00 00 00 00 00 00 00 01 00 00 00 24 |..............= =2E$| 00004010 00 00 00 20 00 00 00 07 76 65 72 73 69 6f 6e 00 |... ....versio= n.| 00004020 00 00 00 08 00 00 00 01 00 00 00 00 00 00 13 88 |..............= =2E.| 00004030 00 00 00 24 00 00 00 20 00 00 00 04 6e 61 6d 65 |...$... ....na= me| If you look at the output of "zdb -C zShare", the 'asize' value is the usable size of the vdev in bytes - the physical size is a slightly larger (~4.5MB for me) but the labels are at the end of the physical partition. For more details, see the ZFS On-Disk Specification (ondiskformat0822.pdf) --=20 Peter Jeremy --/NkBOFFp2J2Af1nK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHy8dcACgkQ/opHv/APuIfvQQCfYsdZGPiPS0o+/HQ5fJIBl415 s0IAoIHWbhiBzZyKRv9Nvvl1GhTIDEpx =WlyL -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK-- From owner-freebsd-fs@FreeBSD.ORG Sat Jul 27 11:49:25 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BFF4F58F; Sat, 27 Jul 2013 11:49:25 +0000 (UTC) (envelope-from david.i.noel@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 344CB2184; Sat, 27 Jul 2013 11:49:25 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id c10so1731048wiw.4 for ; Sat, 27 Jul 2013 04:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=G24H1ayJoOqM8SEy8HRByYgTftTAS8yvt7ZmF/k++ag=; b=hQOdkk2El5h82CeHGfe6VRGF6tHztPunsOsEpbofgB+58R88pMxdpU4Fc9Kpo2aZPx HIAGX5HAfvZJYSMjJ5MgWOS4ffjrKybAC4/LE4okTVZRaHOoxFjE72SyGumu3ygb2594 1UV+ZEQt+P0kDS6zf4qsH1qf6/XYaLl4ya5HIk0gXtOxCXfXoiLzV0i74YKWKg3i6EEU fyJMJhLhtY5S8QsIyy6DdJPUFnCgidFpX0cEJjPazqB7O+ZEm78vLm1N8u7Uo2nPLGtJ 0aQo87cWya2dUS1+bJ+ZPxi8h1mK5PVFFZFKK62ovgiiU8wVYC/lJAX8VR7oTjgsW3lu AxBg== MIME-Version: 1.0 X-Received: by 10.180.198.79 with SMTP id ja15mr1787288wic.36.1374925763374; Sat, 27 Jul 2013 04:49:23 -0700 (PDT) Received: by 10.216.180.138 with HTTP; Sat, 27 Jul 2013 04:49:23 -0700 (PDT) Date: Sat, 27 Jul 2013 06:49:23 -0500 Message-ID: Subject: Delete a directory, crash the system From: David Noel To: freebsd-questions@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: David.I.Noel@gmail.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 11:49:25 -0000 I had a strange experience on my laptop yesterday. I was deleting a directory and the system crashed. It spat out a message along the lines of "ufs_dirrem bad link count 2 on parent". I thought it was so strange I repeated the process several times, and each time it crashed. Is this behavior EXPECTED? I can't for the life of me think of a time or operating system I've run where I've ever had a system crash on me from doing something as basic as deleting a file. Anyway I couldn't boot into single user for some reason so I booted from a USB image, ran fsck, and then everything was fine. From owner-freebsd-fs@FreeBSD.ORG Sat Jul 27 12:12:36 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 651734B8; Sat, 27 Jul 2013 12:12:36 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C71F02383; Sat, 27 Jul 2013 12:12:35 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id j13so1535602wgh.1 for ; Sat, 27 Jul 2013 05:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=auNXhtmmP3ua6oZ+izz8pxHqZZdZkTWvMsGh8Kg4GwU=; b=m2XudBKYQtoKNH2qUmzTaBRB9WfikiSyIZevrnaTrdP3K4GeLCPDoaYAUZvjFcrD0V j0v2wvFB0ZNbuja3/SN2dwqe5qdWKRLP77gbEuK9lRgChRofjBMz7qYJXlUqIQ+4FFij gkUD/YBKUmZ71EnsHcGNPNp7UtX2CLGdLe8FoePYKLGjJn3WF3hl7Tq3ectQC3fLthlF IzM2TgghkhjenB8k/4K6mMteAz0Ft53mtC4N+OUyCVgzAraPubXDOvG1sOOK12Lr6gTW y+OAP8I2NH/m+PA8L6UDlweE8wGL3m+cNiaJODZu8KK1e0OcAuDhE3K8h2xiIwJIqxFb lg7A== MIME-Version: 1.0 X-Received: by 10.194.243.129 with SMTP id wy1mr37488055wjc.47.1374927154052; Sat, 27 Jul 2013 05:12:34 -0700 (PDT) Received: by 10.180.187.162 with HTTP; Sat, 27 Jul 2013 05:12:33 -0700 (PDT) Received: by 10.180.187.162 with HTTP; Sat, 27 Jul 2013 05:12:33 -0700 (PDT) In-Reply-To: References: Date: Sat, 27 Jul 2013 14:12:33 +0200 Message-ID: Subject: Re: Delete a directory, crash the system From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= To: David.I.Noel@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@freebsd.org, User Questions X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 12:12:36 -0000 El 27/07/2013 13:49, "David Noel" escribi=F3: > > I had a strange experience on my laptop yesterday. I was deleting a > directory and the system crashed. It spat out a message along the > lines of "ufs_dirrem bad link count 2 on parent". I thought it was so > strange I repeated the process several times, and each time it > crashed. Is this behavior EXPECTED? I can't for the life of me think > of a time or operating system I've run where I've ever had a system > crash on me from doing something as basic as deleting a file. Anyway I > couldn't boot into single user for some reason so I booted from a USB > image, ran fsck, and then everything was fine. Was it a kernel crash? Did you get a core? > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Sat Jul 27 12:16:45 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 96711624; Sat, 27 Jul 2013 12:16:45 +0000 (UTC) (envelope-from david.i.noel@gmail.com) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 059D823CF; Sat, 27 Jul 2013 12:16:44 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id x55so2703448wes.32 for ; Sat, 27 Jul 2013 05:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=DMBaBiwNM11Buis5d11Y9Raj/CELF3vG7ZmRxuFghVc=; b=DiLoR+30vP2OlvzMietaTUdVY/C33zK2Km9/jdCR/F+ro35QldUqjrYOpT2iNd6lzd YCKIorjtikxF9NqsTT+NPKSSca9hLSOoIJTccFkIRmva9L2oCkbVrdcIYyeiUNaT5OXf SDDH/3EB1rIHlWxw4X0IeBFD0jrldpkBDWnIixGAItVyWQvlyeXVRs96DXHTqd87Y2C/ oiUbJLc70xYlu+tffDiRDcMi2ugq8LrRLoTpg3BRvrKGhqR2/KqLWf078YVQrHLAm2vO o4IJQ6M3JjOjtjp1ERc6wNdKPe6qFMwotF/9VucC6T3GYr7jB1TNeMurwRlVx04GqGbX xB5w== MIME-Version: 1.0 X-Received: by 10.180.206.164 with SMTP id lp4mr1941063wic.1.1374927402234; Sat, 27 Jul 2013 05:16:42 -0700 (PDT) Received: by 10.216.180.138 with HTTP; Sat, 27 Jul 2013 05:16:42 -0700 (PDT) In-Reply-To: References: Date: Sat, 27 Jul 2013 07:16:42 -0500 Message-ID: Subject: Re: Delete a directory, crash the system From: David Noel To: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, User Questions X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: David.I.Noel@gmail.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 12:16:45 -0000 Yes On 7/27/13, Fernando Apestegu=EDa wrote: > El 27/07/2013 13:49, "David Noel" escribi=F3: >> >> I had a strange experience on my laptop yesterday. I was deleting a >> directory and the system crashed. It spat out a message along the >> lines of "ufs_dirrem bad link count 2 on parent". I thought it was so >> strange I repeated the process several times, and each time it >> crashed. Is this behavior EXPECTED? I can't for the life of me think >> of a time or operating system I've run where I've ever had a system >> crash on me from doing something as basic as deleting a file. Anyway I >> couldn't boot into single user for some reason so I booted from a USB >> image, ran fsck, and then everything was fine. > > Was it a kernel crash? Did you get a core? > >> _______________________________________________ >> freebsd-questions@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Sat Jul 27 12:25:33 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DE0077D7; Sat, 27 Jul 2013 12:25:33 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B62A243F; Sat, 27 Jul 2013 12:25:33 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id en1so1634435wid.2 for ; Sat, 27 Jul 2013 05:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NI0+XcaHyoEwzgwQ8xk734JZfBPi2Hq497fDDxmfW5E=; b=hO7BZ5nbYQyx6cCBj5IieS8jl63lKZT0PJSaBW0+1alMcIGQANymquLjr+1Gup7uL0 178QtuksNzTxRmQW/0LxYsgPpsHUvqwmUj8RdnJk1X2mJJWK6E3eqPTpemrAWGgqDoNn M+cmF9uHWQYccvWJNDZmjLBGQp4B3wMLualIRjGfPwzTMTbfBTQLo7Sd5XdKt9qz2s8E 4OBHs7IeTGAwUE9tCwPTtoY/tgUNcIkd4Vou5z7QxOyyIcqbMFY9ksd/61269pYNURlm CwbK6qX2AH2R7MU2YdXw1T3Dxj5Kn89AyDe8OXpll4c+7PY9G/dRzZnAeQGHxhlz+lL9 AujA== MIME-Version: 1.0 X-Received: by 10.194.239.225 with SMTP id vv1mr37752053wjc.63.1374927931587; Sat, 27 Jul 2013 05:25:31 -0700 (PDT) Received: by 10.180.187.162 with HTTP; Sat, 27 Jul 2013 05:25:31 -0700 (PDT) Received: by 10.180.187.162 with HTTP; Sat, 27 Jul 2013 05:25:31 -0700 (PDT) In-Reply-To: References: Date: Sat, 27 Jul 2013 14:25:31 +0200 Message-ID: Subject: Re: Delete a directory, crash the system From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= To: David.I.Noel@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@freebsd.org, User Questions X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 12:25:33 -0000 El 27/07/2013 14:16, "David Noel" escribi=F3: > > Yes Post the stack trace of the core and maybe someone can help you. > > On 7/27/13, Fernando Apestegu=EDa wrote: > > El 27/07/2013 13:49, "David Noel" escribi=F3: > >> > >> I had a strange experience on my laptop yesterday. I was deleting a > >> directory and the system crashed. It spat out a message along the > >> lines of "ufs_dirrem bad link count 2 on parent". I thought it was so > >> strange I repeated the process several times, and each time it > >> crashed. Is this behavior EXPECTED? I can't for the life of me think > >> of a time or operating system I've run where I've ever had a system > >> crash on me from doing something as basic as deleting a file. Anyway I > >> couldn't boot into single user for some reason so I booted from a USB > >> image, ran fsck, and then everything was fine. > > > > Was it a kernel crash? Did you get a core? > > > >> _______________________________________________ > >> freebsd-questions@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions > >> To unsubscribe, send any mail to " > > freebsd-questions-unsubscribe@freebsd.org" > > From owner-freebsd-fs@FreeBSD.ORG Sat Jul 27 12:58:17 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A5D91B1D; Sat, 27 Jul 2013 12:58:17 +0000 (UTC) (envelope-from david.i.noel@gmail.com) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 14B1C2555; Sat, 27 Jul 2013 12:58:16 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id l18so3624407wgh.35 for ; Sat, 27 Jul 2013 05:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yG3rvnI1NDV9htjGziQS/Bgv0j1/0g3XagW4q/NfHZ8=; b=SflNuB9CBxkRCEwhybTPMBtFjJpRg7EbD5pLENaZhzahxqVuIgxD4XUNIe199+fyRw C/rP/h6n09dw8pZdIGL19j4VcMmzOWNimaqfVmAgGQuXCILpgICRMcRuvm4nZe1xdBsc DgN1ncr/HNVzoQldqpW+P8aYyLb0VcN1DItc3lURSoucqOK7FrnpEDqy3bEYAbtjjjex ZjQxJUBnDAP3vAK+FzpJvOcNjGb+ozrIGu4t4uih5eB0PKrt84bmeKl3II1PJIRmedHC 7eQ2NuMwBTusk++5FqMVBFrXfSMZ1b82EhjNmiK4924pkqb5tXv1/vK6A0e4YBfZU8ee 2Kjw== MIME-Version: 1.0 X-Received: by 10.194.19.130 with SMTP id f2mr37055456wje.22.1374929895329; Sat, 27 Jul 2013 05:58:15 -0700 (PDT) Received: by 10.216.180.138 with HTTP; Sat, 27 Jul 2013 05:58:15 -0700 (PDT) In-Reply-To: References: Date: Sat, 27 Jul 2013 07:58:15 -0500 Message-ID: Subject: Re: Delete a directory, crash the system From: David Noel To: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, User Questions X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: David.I.Noel@gmail.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 12:58:17 -0000 > Post the stack trace of the core and maybe someone can help you. panic: ufs_dirrem: Bad link count 2 on parent cpuid = 0 KDB: stack backtrace: #0 0xffffffff808680fe at kdb_backtrace+0x5e #1 0xffffffff80832cb7 at panic+0x187 #2 0xffffffff80a700e3 at ufs_rmdir+0x1c3 #3 0xffffffff80b7d484 at VOP_RMDIR_APV+0x34 #4 0xffffffff808ca32a at kern_rmdirat+0x21a #5 0xffffffff80b17cf0 at amd64_syscall+0x450 #6 0xffffffff80b03427 at Xfast_syscall+0xf7