From owner-freebsd-fs@FreeBSD.ORG Sun Jan 29 04:56:19 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41CBE106566B for ; Sun, 29 Jan 2012 04:56:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id CAA058FC08 for ; Sun, 29 Jan 2012 04:56:18 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0T4Qm1d023888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jan 2012 06:26:48 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0T4QlHS084833; Sun, 29 Jan 2012 06:26:47 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0T4QlNP084832; Sun, 29 Jan 2012 06:26:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 29 Jan 2012 06:26:47 +0200 From: Kostik Belousov To: Uffe Jakobsen Message-ID: <20120129042647.GJ2726@deviant.kiev.zoral.com.ua> References: <201201272310.q0RNABvZ065758@freefall.freebsd.org> <20120128004755.GA89980@icarus.home.lan> <4F246CA9.30803@uffe.org> <4F248B44.1090304@uffe.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SfgfV7onya2wNU+g" Content-Disposition: inline In-Reply-To: <4F248B44.1090304@uffe.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 04:56:19 -0000 --SfgfV7onya2wNU+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 29, 2012 at 12:56:52AM +0100, Uffe Jakobsen wrote: >=20 >=20 > On 2012-01-28 23:31, Chris Rees wrote: > > > >On 28 Jan 2012 22:14, "Uffe Jakobsen" >> wrote: > > > > > > > > > > > > On 2012-01-28 01:47, Jeremy Chadwick wrote: > > >> > > >> On Fri, Jan 27, 2012 at 11:10:11PM +0000, Uffe Jakobsen wrote: > > >>> > > >>> The following reply was made to PR kern/164516; it has been noted > >by GNATS. > > >>> > > >>> From: Uffe Jakobsen> > > >>> To: bug-followup@FreeBSD.org > > >>> Cc: > > >>> Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem > > >>> Date: Fri, 27 Jan 2012 20:49:05 +0100 > > >>> > > >>> > > > >>> > Not a bug. The file system type name is "ext2fs" not "ext2". > > >>> > Use "mount -t ext2fs /dev/md0 /mnt/tmp0" instead. > > >>> > > > >>> > > >>> Instead of reporting "Operation not supported by device" > > >>> Shouldn't it report unknown filesystem type ? > > >> > > >> > > >> Please look through /usr/include/errno.h and let us know what error= =20 > > code > > >> would represent "unknown filesystem type". :-) > > >> > > > > > > There are plenty of other places in the mount src where we exit > >without a specific error code. Question is if there exists a scenario > >where the requested filesystem type would/could not be found by > >getvfsbyname() ? > > > > > > I've met this problem myself a number of times - and even in this > >case I did not spot the spelling error right away ('ext2fs' and not=20 > >'ext2'). > > > > > > The returned error 'Operation not supported by device' - atleast to > >me - indicates that the mount process got much further before running > >into some kind of problem. The times when I've met this error I've begun > >inspecting mount options etc before realizing that the fstype had a typo. > > > > > > >Normally when an error comes up I check the manpage. >=20 > Manpage for mount does not at all mention any error conditions. >=20 > You'll have to know the inner workings of mount in order to know that in= =20 > certain cases everything is thrown into nmount() and any error that=20 > comes up would come directly from nmount() >=20 > Anyway - would you accept a patch that checked the fstype using=20 > getvfsbyname() before calling nmount() ? Kernel tries to load the named module if it is not registered in the list of know VFSes. Your proposal would break this functionality. --SfgfV7onya2wNU+g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8kyocACgkQC3+MBN1Mb4hTRQCfabRZ11enKcKWKeNQeSoAeJQy o3kAoNzkr8mcXCWXNjVQiZAz2RgHH8Xx =scsm -----END PGP SIGNATURE----- --SfgfV7onya2wNU+g-- From owner-freebsd-fs@FreeBSD.ORG Sun Jan 29 07:03:37 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59C8C1065670 for ; Sun, 29 Jan 2012 07:03:37 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 3C5D38FC16 for ; Sun, 29 Jan 2012 07:03:37 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RrOnY-000J6C-0k for freebsd-fs@freebsd.org; Sun, 29 Jan 2012 07:03:36 +0000 Date: Sun, 29 Jan 2012 16:03:35 +0900 Message-ID: From: Randy Bush To: FreeBSD FS In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: trying to whack a glabel for a zfs mirror X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 07:03:37 -0000 as usual, i am a bit clueless here. NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror DEGRADED 0 0 0 label/m00-d01 REMOVED 0 0 0 label/m00-d00 ONLINE 0 0 0 mirror ONLINE 0 0 0 label/m01-d00 ONLINE 0 0 0 label/m01-d01c ONLINE 0 0 0 mirror ONLINE 0 0 0 label/m02-d00c ONLINE 0 0 0 label/m02-d01c ONLINE 0 0 0 mirror ONLINE 0 0 0 label/m03-d00 ONLINE 0 0 0 label/m03-d01c ONLINE 0 0 0 mirror ONLINE 0 0 0 label/m04-d00 ONLINE 0 0 0 label/m04-d01 ONLINE 0 0 0 mirror ONLINE 0 0 0 label/m05-d01 ONLINE 0 0 0 label/m05-d00 ONLINE 0 0 0 Geom name: da2s3 Providers: 1. Name: label/m00-d01 Mediasize: 1965957073408 (1.8T) Sectorsize: 512 Mode: r0w0e0 secoffset: 0 offset: 0 seclength: 3839759909 length: 1965957073408 index: 0 Consumers: 1. Name: da2s3 Mediasize: 1965957073920 (1.8T) Sectorsize: 512 Mode: r0w0e0 # zpool attach tank label/m00-d00 label/m00-d01 cannot use '/dev/label/m00-d01': must be a GEOM provider or regular file # glabel label m00-d01 /dev/da2s3 glabel: Can't store metadata on /dev/da2s3: Invalid argument. # sysctl kern.geom.debugflags=17 kern.geom.debugflags: 0 -> 17 # dd if=/dev/zero of=/dev/da2s3 dd: /dev/da2s3: Invalid argument randy From owner-freebsd-fs@FreeBSD.ORG Sun Jan 29 08:10:03 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 821E51065673; Sun, 29 Jan 2012 08:10:03 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (unknown [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id 5C66B8FC19; Sun, 29 Jan 2012 08:10:03 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id q0T89xrA070840; Sun, 29 Jan 2012 00:09:59 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201201290809.q0T89xrA070840@chez.mckusick.com> To: Yamagi Burmeister In-reply-to: <20120127093934.ae7ca125.lists@yamagi.org> Date: Sun, 29 Jan 2012 00:09:59 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: antonio.trindade@gmail.com, freebsd-fs@freebsd.org Subject: Re: kernel: panic: softdep_sync_buf: Unknown type jnewblk X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 08:10:03 -0000 > Date: Fri, 27 Jan 2012 09:39:34 +0100 > From: Yamagi Burmeister > To: freebsd@jdc.parodius.com > Cc: antonio.trindade@gmail.com, freebsd-fs@freebsd.org, dougb@freebsd.org, > freebsd-stable@freebsd.org > Subject: Re: kernel: panic: softdep_sync_buf: Unknown type jnewblk > > Hi :) > > On Thu, 26 Jan 2012 17:54:30 -0800 > Jeremy Chadwick wrote: > > > I'll also point out, though the OP isn't using snapshots, that it's > > confirmed use of snapshots on SU+J can result in a full filesystem hang. > > Confirmation is from Kirk McKusick (author of SU and designer of SU+J): > > > > http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013429.html > > > > Something really needs to be done about this combination of problems. > > > > Since SU+J is the default choice for all UFS filesystems on 9.0-RELEASE, > > the only solution I can think of is to send a massive announcement to > > relevant mailing lists, AND put something on the freebsd.org home page > > about these issues. > > The problem was analyzed but no immediate solution found. Therefor > snapshots on filesystems with SU+J (but not SU alone) were disabled > by Kirk McKusick in SVN r230250. The MFC to 9-STABLE has still to > be done. Maybe this fix is a candidate for an errata notice / patch, > distributed by freebsd-update? With revision 230725 I have MFC'ed to 9 the above change to disable snapshots when running SU+J. Hopefully Jeff and I will manage to get a fix for snapshots so as to be able to run them reliably with SU+J. The above change is not relevant to 8 or earlier systems, so this MFC will not be applied to them. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Sun Jan 29 08:50:58 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF9F8106566B for ; Sun, 29 Jan 2012 08:50:58 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6F46B8FC17 for ; Sun, 29 Jan 2012 08:50:58 +0000 (UTC) Received: by iaeo4 with SMTP id o4so6593749iae.13 for ; Sun, 29 Jan 2012 00:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=sI3rt8kntm4s2OiGt+KcTwKZ9eO8uHNYj3EqPwJVsOI=; b=DQSFG8ryiqm4fVzWtm8Xp0cze8eanBhXUBlRhjDHrquHCF8tzF+fN/xbgey1DQMJl2 VDYKsGpQ07ayTBRECMADPHxd95X9I4QqFnoZkUGBFn02AQ9dbE0Qy7rFyLr5v376PZ/z 1EmtuAEFYKg6g6P/JUMnynBAwulds57ZtciHI= Received: by 10.50.178.70 with SMTP id cw6mr16966747igc.4.1327827057690; Sun, 29 Jan 2012 00:50:57 -0800 (PST) Received: from DataIX.net ([99.19.42.1]) by mx.google.com with ESMTPS id ba5sm7061533igb.6.2012.01.29.00.50.54 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jan 2012 00:50:56 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q0T8op2o051804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jan 2012 03:50:51 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q0T8okP2051667; Sun, 29 Jan 2012 03:50:46 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Sun, 29 Jan 2012 03:50:46 -0500 From: Jason Hellenthal To: Randy Bush Message-ID: <20120129085045.GA26210@DataIX.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: Cc: FreeBSD FS Subject: Re: trying to whack a glabel for a zfs mirror X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 08:50:58 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 29, 2012 at 04:03:35PM +0900, Randy Bush wrote: > as usual, i am a bit clueless here. >=20 > NAME STATE READ WRITE CKSUM > tank DEGRADED 0 0 0 > mirror DEGRADED 0 0 0 > label/m00-d01 REMOVED 0 0 0 > label/m00-d00 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > label/m01-d00 ONLINE 0 0 0 > label/m01-d01c ONLINE 0 0 0 > mirror ONLINE 0 0 0 > label/m02-d00c ONLINE 0 0 0 > label/m02-d01c ONLINE 0 0 0 > mirror ONLINE 0 0 0 > label/m03-d00 ONLINE 0 0 0 > label/m03-d01c ONLINE 0 0 0 > mirror ONLINE 0 0 0 > label/m04-d00 ONLINE 0 0 0 > label/m04-d01 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > label/m05-d01 ONLINE 0 0 0 > label/m05-d00 ONLINE 0 0 0 >=20 > Geom name: da2s3 > Providers: > 1. Name: label/m00-d01 > Mediasize: 1965957073408 (1.8T) > Sectorsize: 512 > Mode: r0w0e0 > secoffset: 0 > offset: 0 > seclength: 3839759909 > length: 1965957073408 > index: 0 > Consumers: > 1. Name: da2s3 > Mediasize: 1965957073920 (1.8T) > Sectorsize: 512 > Mode: r0w0e0 >=20 > # zpool attach tank label/m00-d00 label/m00-d01 > cannot use '/dev/label/m00-d01': must be a GEOM provider or regular file >=20 > # glabel label m00-d01 /dev/da2s3 > glabel: Can't store metadata on /dev/da2s3: Invalid argument. >=20 > # sysctl kern.geom.debugflags=3D17 > kern.geom.debugflags: 0 -> 17 >=20 > # dd if=3D/dev/zero of=3D/dev/da2s3 > dd: /dev/da2s3: Invalid argument >=20 > randy Once again the use of glabel(8) that causes and can cause loss of data with= in ZFS disks... DO NOT USE GLABEL! it is not a solution that you are lookin= g for and in the long run you will shoot yourself in the foot for using it. What you are seeing is glabel blatently refusing to write meta-data to part= s of the disk where something may already exist. This is a good thing. In turn use something like gpart(8) to adjust the gpt label and/or set your= disks up properly. This is not the same thing as glabel(8) which in turn i= s a hack and not a solution and severely needs to be shot into outerspace f= rom world. --=20 ;s =3D; --opJtzjQTFsWo+cga Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJPJQhlAAoJEJBXh4mJ2FR+NioIAI8SFSdoGJ6Y5Q/tfh9s1c+g TiEcBX9O0mr977m/MJa91WQHscVlMI37vCrA81lVBnJmAA0sWhem+r8rgqm+K2Cb L/hm/bc61iN5wtRrYkuXRrGHyFr5m+xn5LHhovNZ043FilJi/P8oJH31cmx5kYL+ B/pNzN0jnxPxUMMkjE6rvJDOdkBWzEaa+xddER6Wqkb/adsubqN4fdKg3tHa0rxK e70s9D5zviaPxMvd226e5pfBMi7Jyl7gNo2xjHvUEsBgFOO/OxvULWTt8LZgaDaO 2xmfiEYoWTkk5OiCYBp51kN0Vt37LgSHN074fdBBQYn1jS90c2I1lm4t7WuieNU= =sZQM -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From owner-freebsd-fs@FreeBSD.ORG Sun Jan 29 09:00:28 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78338106566B for ; Sun, 29 Jan 2012 09:00:28 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 44C748FC0C for ; Sun, 29 Jan 2012 09:00:28 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RrQcc-000JIo-U0; Sun, 29 Jan 2012 09:00:27 +0000 Date: Sun, 29 Jan 2012 18:00:25 +0900 Message-ID: From: Randy Bush To: Jason Hellenthal In-Reply-To: <20120129085045.GA26210@DataIX.net> References: <20120129085045.GA26210@DataIX.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD FS Subject: Re: trying to whack a glabel for a zfs mirror X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 09:00:28 -0000 > Once again the use of glabel(8) that causes and can cause loss of data > within ZFS disks... DO NOT USE GLABEL! it is not a solution that you > are looking for and in the long run you will shoot yourself in the > foot for using it. > > What you are seeing is glabel blatently refusing to write meta-data to > parts of the disk where something may already exist. This is a good > thing. > > In turn use something like gpart(8) to adjust the gpt label and/or set > your disks up properly. This is not the same thing as glabel(8) which > in turn is a hack and not a solution and severely needs to be shot > into outerspace from world. i gather you do not like glabel :) as you might have guessed from the ad0s3, the disks are gparted. the reason that they are also glabeled is that this is on a disk controller from hell, an hpt 16-port, which seems to occasionally renumber the drives, for example when one is removed. so i wanted constant labels. randy From owner-freebsd-fs@FreeBSD.ORG Sun Jan 29 10:34:11 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 302E91065672 for ; Sun, 29 Jan 2012 10:34:11 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by mx1.freebsd.org (Postfix) with ESMTP id D07748FC12 for ; Sun, 29 Jan 2012 10:34:10 +0000 (UTC) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta15.westchester.pa.mail.comcast.net with comcast id TNXT1i0021vXlb85FNaALB; Sun, 29 Jan 2012 10:34:10 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta17.westchester.pa.mail.comcast.net with comcast id TNa91i01C1t3BNj3dNaAo1; Sun, 29 Jan 2012 10:34:10 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 91C3A102C1E; Sun, 29 Jan 2012 02:34:08 -0800 (PST) Date: Sun, 29 Jan 2012 02:34:08 -0800 From: Jeremy Chadwick To: Randy Bush Message-ID: <20120129103408.GA21680@icarus.home.lan> References: <20120129085045.GA26210@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD FS , Jason Hellenthal Subject: Re: trying to whack a glabel for a zfs mirror X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 10:34:11 -0000 On Sun, Jan 29, 2012 at 06:00:25PM +0900, Randy Bush wrote: > > Once again the use of glabel(8) that causes and can cause loss of data > > within ZFS disks... DO NOT USE GLABEL! it is not a solution that you > > are looking for and in the long run you will shoot yourself in the > > foot for using it. > > > > What you are seeing is glabel blatently refusing to write meta-data to > > parts of the disk where something may already exist. This is a good > > thing. > > > > In turn use something like gpart(8) to adjust the gpt label and/or set > > your disks up properly. This is not the same thing as glabel(8) which > > in turn is a hack and not a solution and severely needs to be shot > > into outerspace from world. > > i gather you do not like glabel :) > > as you might have guessed from the ad0s3, the disks are gparted. the > reason that they are also glabeled is that this is on a disk controller > from hell, an hpt 16-port, which seems to occasionally renumber the > drives, for example when one is removed. so i wanted constant labels. You can't statically assign the controller ports to individual indexes/numbers? An example (on a different controller though, but it should work regardless of controller though the obvious semantics have to be changed). Taken from our /boot/loader.conf -- # "Wire down" device names (ada[0-5]) to each individual port # on the SATA/AHCI controller. This ensures that if we reboot # with a disk missing, the device names stay the same, and stay # attached to the same SATA/AHCI controller. # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html # hint.scbus.0.at="ahcich0" hint.scbus.1.at="ahcich1" hint.scbus.2.at="ahcich2" hint.scbus.3.at="ahcich3" hint.scbus.4.at="ahcich4" hint.scbus.5.at="ahcich5" hint.ada.0.at="scbus0" hint.ada.1.at="scbus1" hint.ada.2.at="scbus2" hint.ada.3.at="scbus3" hint.ada.4.at="scbus4" hint.ada.5.at="scbus5" IMO, this is a hell of a lot better than dealing with all of this labelling nonsense that FreeBSD has introduced over the years. Every single time I read about it on the mailing lists there is always some nonsensical complexity or annoyance with it. I guess some people just like pain. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sun Jan 29 14:32:04 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B93821065673; Sun, 29 Jan 2012 14:32:04 +0000 (UTC) (envelope-from antonio.trindade@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id E58F78FC0C; Sun, 29 Jan 2012 14:32:03 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so4009226wib.13 for ; Sun, 29 Jan 2012 06:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer:x-virus-scanned; bh=X8a/gZMLKViN+V3Eqz+0tsNNzlHOS5W3OOVwgQoPouc=; b=CdDsU9neXVgy3NkkaPfMcuR0EWGe9pvrpDITitUPzWuRwn/tgnLl8ERkbtpxkH92R6 8iPftJ7+6Kb7+2iQ167Lt/oDJOMBsqgaezdN8St6B3JgDAS5W2gfgcBDNq3sGp7wqjHN 1SIOstRr97BXZsPAhYKqF5vqmNVm6EY/PlAxg= Received: by 10.180.86.105 with SMTP id o9mr22130947wiz.4.1327847523007; Sun, 29 Jan 2012 06:32:03 -0800 (PST) Received: from gatekeeper.darklair.homeunix.net (a89-153-149-64.cpe.netcabo.pt. [89.153.149.64]) by mx.google.com with ESMTPS id fv6sm42905017wib.8.2012.01.29.06.32.00 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jan 2012 06:32:01 -0800 (PST) Received: from gatekeeper.darklair.homeunix.net (localhost [127.0.0.1]) by gatekeeper.darklair.homeunix.net (Postfix) with ESMTP id 6096CCF01A; Sun, 29 Jan 2012 14:31:59 +0000 (WET) Received: from altair-wifi.darklair.homeunix.net (altair-wifi.darklair.homeunix.net [10.0.0.11]) by gatekeeper.darklair.homeunix.net (Postfix) with ESMTPA id C3814CF018; Sun, 29 Jan 2012 14:31:58 +0000 (WET) From: =?iso-8859-1?Q?Ant=F3nio_Trindade?= Mime-Version: 1.0 (Apple Message framework v1084) Date: Sun, 29 Jan 2012 14:31:56 +0000 In-Reply-To: <201201290809.q0T89xrA070840@chez.mckusick.com> To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, freebsd-bugs@freebsd.org References: <201201290809.q0T89xrA070840@chez.mckusick.com> Message-Id: <5CDF3EE0-2FC6-4445-9BC4-502CA95BE70C@gmail.com> X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: ClamAV using ClamSMTP Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: kernel: panic: softdep_sync_buf: Unknown type jnewblk X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 14:32:04 -0000 Hi. I'm pretty sure this will be considered almost as spam, but I = reactivated SU+J a day and half ago and it still did not panic. However, I also activated dumpdev, so I'll be prepared to provide = additional information in case of a panic. Cumprimentos/Best regards/Mit freundlichen Gr=FC=DFen, Ant=F3nio Trindade Antonio Trindade gmail.com S=EDtios pessoais: Galeria Fotogr=E1fica: http://trindade.myphotos.cc/fotos/ Blog de fotografia: http://trindade.myphotos.cc/fotografia/ Blog de not=EDcias: http://trindade.myphotos.cc/noticiasavulsas/ Blog pessoal: http://trindade.myphotos.cc/pensamentosnoar/ On 2012/01/29, at 08:09, Kirk McKusick wrote: >> Date: Fri, 27 Jan 2012 09:39:34 +0100 >> From: Yamagi Burmeister >> To: freebsd@jdc.parodius.com >> Cc: antonio.trindade@gmail.com, freebsd-fs@freebsd.org, = dougb@freebsd.org, >> freebsd-stable@freebsd.org >> Subject: Re: kernel: panic: softdep_sync_buf: Unknown type jnewblk >>=20 >> Hi :) >>=20 >> On Thu, 26 Jan 2012 17:54:30 -0800 >> Jeremy Chadwick wrote: >>=20 >>> I'll also point out, though the OP isn't using snapshots, that it's >>> confirmed use of snapshots on SU+J can result in a full filesystem = hang. >>> Confirmation is from Kirk McKusick (author of SU and designer of = SU+J): >>>=20 >>> = http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013429.html >>>=20 >>> Something really needs to be done about this combination of = problems. >>>=20 >>> Since SU+J is the default choice for all UFS filesystems on = 9.0-RELEASE, >>> the only solution I can think of is to send a massive announcement = to >>> relevant mailing lists, AND put something on the freebsd.org home = page >>> about these issues. >>=20 >> The problem was analyzed but no immediate solution found. Therefor >> snapshots on filesystems with SU+J (but not SU alone) were disabled >> by Kirk McKusick in SVN r230250. The MFC to 9-STABLE has still to >> be done. Maybe this fix is a candidate for an errata notice / patch, >> distributed by freebsd-update? >=20 > With revision 230725 I have MFC'ed to 9 the above change to disable > snapshots when running SU+J. Hopefully Jeff and I will manage to get > a fix for snapshots so as to be able to run them reliably with SU+J. > The above change is not relevant to 8 or earlier systems, so this MFC > will not be applied to them. >=20 > Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Sun Jan 29 17:51:20 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9488106566B for ; Sun, 29 Jan 2012 17:51:20 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6E7EF8FC0C for ; Sun, 29 Jan 2012 17:51:20 +0000 (UTC) Received: by ghbg15 with SMTP id g15so1596179ghb.13 for ; Sun, 29 Jan 2012 09:51:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=zywtK9h9++WYyKSThtaP6fHsTnEv+tsXkVWvpCYYZ4U=; b=jGKi2argFoGEkMyq5vP5080a2RM8MOe/AuDmg92xwN7CWFOfmePEq2DVoZ5EMTfTt4 lkN7f/dYGzzFaE+V2ll8ImcWhY3/hmYwV/7OsZiTpwkqwf7Ys510VlwE9vAqcsDY1hfu M33RCBcUXmuqCeXcn78sWCmlphvqyhSEXGquE= Received: by 10.236.131.38 with SMTP id l26mr22054068yhi.70.1327859479646; Sun, 29 Jan 2012 09:51:19 -0800 (PST) Received: from DataIX.net (adsl-99-19-42-1.dsl.klmzmi.sbcglobal.net. [99.19.42.1]) by mx.google.com with ESMTPS id j41sm11825824yhm.16.2012.01.29.09.51.17 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jan 2012 09:51:18 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q0THpDKr043614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jan 2012 12:51:13 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q0THp6tQ043494; Sun, 29 Jan 2012 12:51:06 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Sun, 29 Jan 2012 12:51:06 -0500 From: Jason Hellenthal To: Randy Bush Message-ID: <20120129175106.GA86040@DataIX.net> References: <20120129085045.GA26210@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: FreeBSD FS Subject: Re: trying to whack a glabel for a zfs mirror X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 17:51:20 -0000 On Sun, Jan 29, 2012 at 06:00:25PM +0900, Randy Bush wrote: > > Once again the use of glabel(8) that causes and can cause loss of data > > within ZFS disks... DO NOT USE GLABEL! it is not a solution that you > > are looking for and in the long run you will shoot yourself in the > > foot for using it. > > > > What you are seeing is glabel blatently refusing to write meta-data to > > parts of the disk where something may already exist. This is a good > > thing. > > > > In turn use something like gpart(8) to adjust the gpt label and/or set > > your disks up properly. This is not the same thing as glabel(8) which > > in turn is a hack and not a solution and severely needs to be shot > > into outerspace from world. > > i gather you do not like glabel :) > The idea is good but the end result usually turns out to be what you are seeing. > as you might have guessed from the ad0s3, the disks are gparted. the > reason that they are also glabeled is that this is on a disk controller > from hell, an hpt 16-port, which seems to occasionally renumber the > drives, for example when one is removed. so i wanted constant labels. > Jeremy's solution is quite sensible, but seeing you have these disks gpart(1)'d not neccesarily meaning they are using GPT but if they were then you would be able to use /dev/gpt/ that would be statically available until you used gpart(8) to remove it. gpart create -s GPT ad0 gpart add -t freebsd-zfs -l zfs-disk1 ad0 and then add /dev/gpt/zfs-disk1 to your pool. This is different than creating a MBR partitioning scheme that leaves you to using glabel(8) to store meta-data within possibly used space and the "It is not compatible with other systems shoot yourself in the foot.". glabel(8) should be for thumbdrives only! I see you are using the original ATA driver still. You might want to also check into ATA_CAM option for the kernel. It might break away part of your headaches with all these suggestions. Jeremy's suggesting is explicitly hinting at using that as well. "hint.ada." -- ;s =; From owner-freebsd-fs@FreeBSD.ORG Sun Jan 29 22:24:55 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CEDE106564A for ; Sun, 29 Jan 2012 22:24:55 +0000 (UTC) (envelope-from uffe@uffe.org) Received: from mail.starion.dk (mx0.starion.dk [93.162.70.34]) by mx1.freebsd.org (Postfix) with SMTP id A0B9E8FC0A for ; Sun, 29 Jan 2012 22:24:54 +0000 (UTC) Received: (qmail 2690 invoked by uid 1004); 29 Jan 2012 22:25:15 -0000 Message-ID: <4F25C710.6000806@uffe.org> Date: Sun, 29 Jan 2012 23:24:16 +0100 From: Uffe Jakobsen X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <201201272310.q0RNABvZ065758@freefall.freebsd.org> <20120128004755.GA89980@icarus.home.lan> <4F246CA9.30803@uffe.org> <4F248B44.1090304@uffe.org> <20120129042647.GJ2726@deviant.kiev.zoral.com.ua> In-Reply-To: <20120129042647.GJ2726@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 22:24:55 -0000 On 2012-01-29 05:26, Kostik Belousov wrote: > On Sun, Jan 29, 2012 at 12:56:52AM +0100, Uffe Jakobsen wrote: >>> Question is if there exists a scenario >>> where the requested filesystem type would/could not be found by >>> getvfsbyname() ? >>>> >> Anyway - would you accept a patch that checked the fstype using >> getvfsbyname() before calling nmount() ? > > Kernel tries to load the named module if it is not registered in the > list of know VFSes. Your proposal would break this functionality. Thanks that was exactly the info I asked for - I had a feeling that there was some sort of catch. I was not aware of that functionality in nmount - it is not mentioned in the manpage and I admit that i did not look deep into its source. Well that settles the question - it is a no go - thx for your answer. /Uffe From owner-freebsd-fs@FreeBSD.ORG Mon Jan 30 04:10:37 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8E4C106566B for ; Mon, 30 Jan 2012 04:10:37 +0000 (UTC) (envelope-from antonio.trindade@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2AD5E8FC13 for ; Mon, 30 Jan 2012 04:10:36 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so3922952wgb.31 for ; Sun, 29 Jan 2012 20:10:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-virus-scanned; bh=FgqN70vz5K8FOuXTVBrBcrG4rLvmBj33u9ZyLh17lG4=; b=g2Fkh8GgB0BsLcizHWMvV2L8QzYUEIwJ8lQpOpw3GmAAeeIO4+n9rtPNIMiSecS0Gt aPRTGskbJdwy4cojsUHoBBvOIkpv+Vm5eViqnilyinpEJlDzutFaZggIHkxrF1v10IOj Tr5dYcezRprikp5L774X5OHgi5vONh3kBhwX4= Received: by 10.180.80.8 with SMTP id n8mr24941521wix.14.1327896636149; Sun, 29 Jan 2012 20:10:36 -0800 (PST) Received: from gatekeeper.darklair.homeunix.net (a89-153-149-64.cpe.netcabo.pt. [89.153.149.64]) by mx.google.com with ESMTPS id j16sm48341249wie.4.2012.01.29.20.10.33 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jan 2012 20:10:35 -0800 (PST) Received: from gatekeeper.darklair.homeunix.net (localhost [127.0.0.1]) by gatekeeper.darklair.homeunix.net (Postfix) with ESMTP id 4E8E3CF01A; Mon, 30 Jan 2012 04:10:34 +0000 (WET) Received: from altair-wifi.darklair.homeunix.net (altair-wifi.darklair.homeunix.net [10.0.0.11]) by gatekeeper.darklair.homeunix.net (Postfix) with ESMTPA id CE6A1CF018; Mon, 30 Jan 2012 04:10:33 +0000 (WET) Mime-Version: 1.0 (Apple Message framework v1084) From: =?iso-8859-1?Q?Ant=F3nio_Trindade?= In-Reply-To: <11DA12B60F0A4CC68EE81E79A6D82B62@white> Date: Mon, 30 Jan 2012 04:10:30 +0000 Message-Id: References: <201201290809.q0T89xrA070840@chez.mckusick.com> <5CDF3EE0-2FC6-4445-9BC4-502CA95BE70C@gmail.com> <11DA12B60F0A4CC68EE81E79A6D82B62@white> To: "Dewayne Geraghty" X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: ClamAV using ClamSMTP Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: kernel: panic: softdep_sync_buf: Unknown type jnewblk X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 04:10:37 -0000 Excuse me, Dewayne, but I never said I was using snapshots... In fact, I = rarely use them and, for my knowledge (other than any obscure software = functions), they were not in use during any of the panics I observed. Because of this, I think there could be other problem(s) with SU+J yet = to be identified. Cumprimentos/Best regards/Mit freundlichen Gr=FC=DFen, Ant=F3nio Trindade Antonio Trindade gmail.com S=EDtios pessoais: Galeria Fotogr=E1fica: http://trindade.myphotos.cc/fotos/ Blog de fotografia: http://trindade.myphotos.cc/fotografia/ Blog de not=EDcias: http://trindade.myphotos.cc/noticiasavulsas/ Blog pessoal: http://trindade.myphotos.cc/pensamentosnoar/ On 2012/01/30, at 03:18, Dewayne Geraghty wrote: > Antonio, It has been identified that there is a problem with su+j & = using snapshots. I doubt if anyone can help further. >=20 > Refer:=20 > Confirmation of the problem > http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013429.html > Short term solution in 9.0 stable > = http://lists.freebsd.org/pipermail/svn-src-stable-9/2012-January/000837.ht= ml >=20 > Kind regards, Dewayne > PS Thanks to Jeremy Chadwick for pointing out the confirmation >=20 From owner-freebsd-fs@FreeBSD.ORG Mon Jan 30 04:13:19 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDEB61065678; Mon, 30 Jan 2012 04:13:19 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AFAFC8FC24; Mon, 30 Jan 2012 04:13:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0U4DJbE092053; Mon, 30 Jan 2012 04:13:19 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0U4DJIh092049; Mon, 30 Jan 2012 04:13:19 GMT (envelope-from linimon) Date: Mon, 30 Jan 2012 04:13:19 GMT Message-Id: <201201300413.q0U4DJIh092049@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/164472: [ufs] fsck -B panics on particular data inconsistency X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 04:13:20 -0000 Old Synopsis: fsck -B panics on particular data inconsistency New Synopsis: [ufs] fsck -B panics on particular data inconsistency Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 30 04:13:00 UTC 2012 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=164472 From owner-freebsd-fs@FreeBSD.ORG Mon Jan 30 04:30:16 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3A22106564A for ; Mon, 30 Jan 2012 04:30:15 +0000 (UTC) (envelope-from feld@feld.me) Received: from mwi1.coffeenet.org (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id BB6B28FC0C for ; Mon, 30 Jan 2012 04:30:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=Message-Id:From:Mime-Version:Date:Subject:To:Content-Type; bh=wsm0H9dx6i+QnkW7OzFsce1LvC5O7mDeS0UXOMFCbWM=; b=bu7WxRT3xw6Tw86lnnakztmVD39xx/Ac87iqzLV6PFdcw9fyEty4Vc0xAGjq//1wnvP4XpEhtXUAgG1oShuWt5+XX14d4YoskJqwiDRDaISov6PlnWqSkKJtgXdGuC5h; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by mwi1.coffeenet.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rrisg-000NpI-BI for freebsd-fs@freebsd.org; Sun, 29 Jan 2012 22:30:15 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1327897808-18602-18600/5/3; Mon, 30 Jan 2012 04:30:08 +0000 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Date: Sun, 29 Jan 2012 22:30:06 -0600 Mime-Version: 1.0 From: Mark Felder Message-Id: User-Agent: Opera Mail/11.60 (Win32) X-SA-Score: -1.0 Subject: ZFS sync / ZIL clarification X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 04:30:16 -0000 I believe I was told something misleading a few weeks ago and I'd like to have this officially clarified. NFS on ZFS is horrible unless you have sync = disabled. I was told this was effectively disabling the ZIL, which is of course naughty. Now I stumbled upon this tonight: > Just for the archives... sync=disabled won't disable disable the zil, > it'll disable waiting for a disk-flush on fsync etc. With a battery > backed controller cache, those flushes should go to cache, and bepretty > mich free. You end up tossing away something for nothing. Is this accurate? From owner-freebsd-fs@FreeBSD.ORG Mon Jan 30 05:40:13 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85EC6106564A for ; Mon, 30 Jan 2012 05:40:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 565508FC08 for ; Mon, 30 Jan 2012 05:40:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0U5eD0h068368 for ; Mon, 30 Jan 2012 05:40:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0U5eDYi068367; Mon, 30 Jan 2012 05:40:13 GMT (envelope-from gnats) Date: Mon, 30 Jan 2012 05:40:13 GMT Message-Id: <201201300540.q0U5eDYi068367@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Kostik Belousov Cc: Subject: Re: kern/164472: [ufs] fsck -B panics on particular data inconsistency X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kostik Belousov List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 05:40:13 -0000 The following reply was made to PR kern/164472; it has been noted by GNATS. From: Kostik Belousov To: bug-followup@FreeBSD.org, eugene@zhegan.in Cc: Subject: Re: kern/164472: [ufs] fsck -B panics on particular data inconsistency Date: Mon, 30 Jan 2012 07:30:04 +0200 You failed to mention which panic you got. Was it 'dup alloc' ? A backtace would be also useful. If it was indeed 'dup alloc', then there is nothing fsck or snapshots can be accused for. Your filesystem is in inconsistent state, which requires full fsck to recover. It must be not mounted while not repaired. Somewhat more interesting is how the fs got into this state. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 30 07:47:55 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12E1E1065672 for ; Mon, 30 Jan 2012 07:47:55 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id 844E48FC0A for ; Mon, 30 Jan 2012 07:47:54 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MELXc-1RpcEh2sA4-00FsOh; Mon, 30 Jan 2012 08:47:51 +0100 Message-ID: <4F264B27.6060502@brockmann-consult.de> Date: Mon, 30 Jan 2012 08:47:51 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.1.2 X-Provags-ID: V02:K0:IuM+mxJSp1oSplrzaQCsVkAjwQVjvDP9yDvBgv8eIQn 7NZROE1JY+bQrgAifdPzbG9xTzEV/lbGCTp98pGC9lxaU1GVEV cz0xpo+ejYZw8pC0f2Rc3i5XxfVrLwgISm/KE3DnTc+f4B9lc/ wU6HNJfy/tOb3OB5v0qVWA4CI1ZDvTISRnlM4kl7beNz5obpiK IBrSCM1+JPWIaaU7peD3Gyj+9WxK/txPzY0QGCuzda8BhWT/m1 2PatsrENs8EQSFgURZ2HU4z2LEZqXKRBfVppHp5FPcX1Yo+fFH 9qQbYfajKMjrsS8Ia55m6NTzT3j+ElBLwCYaaP6P+ici31TQjg O/QdLp7YevPb23CaGAgzTY8+NwgEsb0/HAytBOv/i Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ZFS sync / ZIL clarification X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 07:47:55 -0000 On 01/30/2012 05:30 AM, Mark Felder wrote: > I believe I was told something misleading a few weeks ago and I'd like > to have this officially clarified. > > NFS on ZFS is horrible unless you have sync = disabled. With ESXi = true with others = depends on your definition of horrible > I was told this was effectively disabling the ZIL, which is of course > naughty. Now I stumbled upon this tonight: > true only for the specific dataset you specified eg. zfs set sync=disabled tank/esxi >> Just for the archives... sync=disabled won't disable disable the >> zil,it'll disable waiting for a disk-flush on fsync etc. Same thing... "waiting for a disk-flush" is the only time the ZIL is used, from what I understand. >> With a batterybacked controller cache, those flushes should go to >> cache, and bepretty mich free. You end up tossing away something for >> nothing. False I guess. Would be nice, but how do you battery back your RAM, which ZFS uses as a write cache? (If you know something I don't know, please share.) > > Is this accurate? sync=disabled caused data corruption for me. So you need to have battery backed cache... unfortunately, the cache we are talking about is in RAM, not your IO controller. So put a UPS on there, and you are safe except when you get a kernel panic (which is what happened to cause my corruption). But if you get something like the Gigabyte iRAM or the Acard ANS-9010 , set it as your ZIL, and leave sync=standard, you should be safer. (I don't know if the iRAM works in FreeBSD, but someone told me he uses the ANS-9010) And NFS with ZFS is not horrible, except with ESXi's built in NFS client it uses for datastores. (the same someone that said he uses the ANS-9010 also provides a 'patch' for the FreeBSD NFS server that disables ESXi's stupid behavior, without disabling sync entirely, but also possibly disables it for others that use it responsibly [a database perhaps]) here is a fantastic study about NFS; dunno if this study resulted in patches now in use or not, or how old it is [newest reference is 2002, so at most 10 years old]. In my experience, the write caching in use today still sucks. If I run async with sync=disabled, I can still see a huge improvement (20% on large files, up to 100% for smaller files <200MB) using an ESXi virtual disk (with ext4 doing write caching) compared to NFS directly. Here begins the rant about ESXi, which may be off topic: ESXi goes 7 MB/s with an SSD ZIL at 100% load, and 80 MB/s with a ramdisk ZIL at 100% load (pathetic!), something I can't reproduce (thought it was just a normal Linux client with "-o sync" over 10 Gbps ethernet) got over 70MB/s with the ZIL at 70-90% load, and other clients set to "-o sync,noatime,..." or "-o noatime,..."with the ZIL only randomly 0-5% load, but go faster than 100 MB/s. I didn't test "async", and without "sync", they seem to go the same speed. setting sync=disabled always goes around 100 MB/s, and changes the load on the ZIL to 0%. The thing I can't reproduce might have been only possible on a pool that I created with FreeBSD 8.2-RELEASE and then upgraded, which I no longer have. Or maybe it was with "sync" without "noatime". I am going to test with 9000 MTU, and if it is not much faster, I am giving up on NFS. My original plan was to use ESXi with a ZFS datastore with a replicated backup. That works terribly using the ESXi NFS client. Netbooting the OSses to bypass the ESXi client works much better, but still not good enough for many servers. NFS is poorly implemented, with terrible write caching on the client side. Now my plan is to use FreeBSD with VirtualBox and ZFS all in one system, and send replication snapshots from there. I wanted to use ESXi, but I guess I can't. And the worst thing about ESXi, is if you have 1 client going 7MB/s, the second client has to share that 7MB/s, and non-ESXi clients will still go horribly slow. If you have 10 non-ESXi clients going at 100 MB/s, each one is limited to around 100 MB/s (again I only tested this with 1500 MTU so far), but together they can write much more. Just now I tested 2 clients writing 100+100 MB/s (reported by GNU dd), and 3 writing 50+60+60 MB/s (reported by GNU dd) Output from "zpool iostat 5": two clients: tank 38.7T 4.76T 0 1.78K 25.5K 206M (matches 100+100) three clients: tank 38.7T 4.76T 1 2.44K 205K 245M (does not match 60+60+50) (one client is a Linux netboot, and the others are using the Linux NFS client) But I am not an 'official', so this cannot be considered 'officially clarified' ;) > _______________________________________________ > 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" -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Mon Jan 30 08:10:12 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFD7B106564A for ; Mon, 30 Jan 2012 08:10:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 944478FC18 for ; Mon, 30 Jan 2012 08:10:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0U8AC2T033654 for ; Mon, 30 Jan 2012 08:10:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0U8ACGj033653; Mon, 30 Jan 2012 08:10:12 GMT (envelope-from gnats) Date: Mon, 30 Jan 2012 08:10:12 GMT Message-Id: <201201300810.q0U8ACGj033653@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Eugene M. Zheganin" Cc: Subject: Re: kern/164472: [ufs] fsck -B panics on particular data inconsistency X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Eugene M. Zheganin" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 08:10:12 -0000 The following reply was made to PR kern/164472; it has been noted by GNATS. From: "Eugene M. Zheganin" To: bug-followup@FreeBSD.org, eugene@zhegan.in Cc: Subject: Re: kern/164472: [ufs] fsck -B panics on particular data inconsistency Date: Mon, 30 Jan 2012 13:50:35 +0600 This state can be achieved (and sometimes is achieved) after a server hangup and/or reset. I cannot agree that using fsck -B should lead to panic, because there is no way to distinguish filesystem between the state where it can be cured with fsck -B and where it can not. After all, this is what the bgfsck is for. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 30 10:11:52 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0B91106566B; Mon, 30 Jan 2012 10:11:52 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6788FC0A; Mon, 30 Jan 2012 10:11:51 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 584FC6AA3; Mon, 30 Jan 2012 10:11:50 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 345668570; Mon, 30 Jan 2012 11:11:50 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Attilio Rao References: <201111081018.pA8AI7ha027020@svn.freebsd.org> Date: Mon, 30 Jan 2012 11:11:50 +0100 In-Reply-To: (Attilio Rao's message of "Sat, 28 Jan 2012 17:03:11 +0100") Message-ID: <86wr89jy8p.fsf_-_@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD FS , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Retiring non-mpsafe filesystems (was: Re: svn commit: r227333 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/kern sys/mips/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 10:11:52 -0000 Attilio Rao writes: > In one month I'm going to disable VFS_ALLOW_NONMPSAFE by defaults in > order to see how well the users do with this option down. At the > present times this means that from 1st March you won't be able to > mount smbfs or ntfs volumes, for example. Hmm, wasn't there a GSoC project to reimplement NTFS? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Mon Jan 30 11:07:33 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88212106566B for ; Mon, 30 Jan 2012 11:07:33 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 74B158FC18 for ; Mon, 30 Jan 2012 11:07:33 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0UB7XP5005393 for ; Mon, 30 Jan 2012 11:07:33 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0UB7WKt005390 for freebsd-fs@FreeBSD.org; Mon, 30 Jan 2012 11:07:32 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 Jan 2012 11:07:32 GMT Message-Id: <201201301107.q0UB7WKt005390@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 11:07:33 -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/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164462 fs [nfs] NFSv4 mounting fails to mount; asks for stronger 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/162362 fs [snapshots] [panic] ufs with snapshot(s) panics when g o kern/162083 fs [zfs] [panic] zfs unmount -f pool o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161897 fs [zfs] [patch] zfs partition probing causing long delay o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161674 fs [ufs] snapshot on journaled ufs doesn't work 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/161511 fs [unionfs] Filesystem deadlocks when using multiple uni 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 o 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/159971 fs [ffs] [panic] panic with soft updates journaling durin o kern/159930 fs [ufs] [panic] kernel core o kern/159663 fs [socket] [nullfs] sockets don't work though nullfs mou 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/158711 fs [ffs] [panic] panic in ffs_blkfree and ffs_valloc o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157722 fs [geli] unable to newfs a geli encrypted partition 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 f 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/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/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/151111 fs [zfs] vnodes leakage during zfs unmount o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/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/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server 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/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files f sparc/123566 fs [zfs] zpool import issue: EOVERFLOW o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/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 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 f kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/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 kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/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 kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o 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 265 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 30 14:46:44 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93712106564A for ; Mon, 30 Jan 2012 14:46:44 +0000 (UTC) (envelope-from feld@feld.me) Received: from mwi1.coffeenet.org (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5E62C8FC13 for ; Mon, 30 Jan 2012 14:46:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=CxOyQiiVexNXbxbOdi8C36I+h/fgMCsG4xTvQ/k+eU4=; b=QOrkwwVt/v22Aq8efUSXGN7AWLqOAZBWph8X5X30r6LP1wXJ5xmF35D2Zlq+Di1UVleEVhWAa0JKJFgd5TacL7HUOmLOrgjKlExONtWLFA3FKkkuXA2msUUL7PyjnxV0; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by mwi1.coffeenet.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RrsVE-000EC6-DW for freebsd-fs@freebsd.org; Mon, 30 Jan 2012 08:46:43 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1327934794-18602-18600/5/5; Mon, 30 Jan 2012 14:46:34 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-fs@freebsd.org References: <4F264B27.6060502@brockmann-consult.de> Date: Mon, 30 Jan 2012 08:46:34 -0600 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <4F264B27.6060502@brockmann-consult.de> User-Agent: Opera Mail/12.00 (FreeBSD) X-SA-Score: -1.5 Subject: Re: ZFS sync / ZIL clarification X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 14:46:44 -0000 Thanks Peter. You're also confirming my original suspicions and the results of my testing. I'm going to continue forward with this ZFS SAN backend for ESXi project with iSCSI via istgt, which actually works surprisingly well. Honestly, NFS would have been quite useful, but it never would have made sense in our environment because you can't properly multipath to it without pNFS / NFS 4.1, which isn't available in FreeBSD yet and will take some time to prove its stability anyway. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 30 20:30:37 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 360C3106564A for ; Mon, 30 Jan 2012 20:30:37 +0000 (UTC) (envelope-from freebsd@pki2.com) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) by mx1.freebsd.org (Postfix) with ESMTP id F3D298FC14 for ; Mon, 30 Jan 2012 20:30:36 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.5/8.14.5) with ESMTP id q0UKUOnE024926; Mon, 30 Jan 2012 12:30:24 -0800 (PST) (envelope-from freebsd@pki2.com) From: Dennis Glatting To: Peter Maloney In-Reply-To: <4F264B27.6060502@brockmann-consult.de> References: <4F264B27.6060502@brockmann-consult.de> Content-Type: text/plain; charset="ISO-8859-1" Date: Mon, 30 Jan 2012 12:30:23 -0800 Message-ID: <1327955423.22960.0.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Dennis Glatting X-yoursite-MailScanner-ID: q0UKUOnE024926 X-yoursite-MailScanner: Found to be clean X-MailScanner-From: freebsd@pki2.com Cc: freebsd-fs@freebsd.org Subject: Re: ZFS sync / ZIL clarification X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 20:30:37 -0000 On Mon, 2012-01-30 at 08:47 +0100, Peter Maloney wrote: > On 01/30/2012 05:30 AM, Mark Felder wrote: > > I believe I was told something misleading a few weeks ago and I'd like > > to have this officially clarified. > > > > NFS on ZFS is horrible unless you have sync = disabled. > With ESXi = true > with others = depends on your definition of horrible > > > I was told this was effectively disabling the ZIL, which is of course > > naughty. Now I stumbled upon this tonight: > > > true only for the specific dataset you specified > eg. > zfs set sync=disabled tank/esxi > > >> Just for the archives... sync=disabled won't disable disable the > >> zil,it'll disable waiting for a disk-flush on fsync etc. > Same thing... "waiting for a disk-flush" is the only time the ZIL is > used, from what I understand. > > >> With a batterybacked controller cache, those flushes should go to > >> cache, and bepretty mich free. You end up tossing away something for > >> nothing. > False I guess. Would be nice, but how do you battery back your RAM, > which ZFS uses as a write cache? (If you know something I don't know, > please share.) > > > > Is this accurate? > > sync=disabled caused data corruption for me. So you need to have battery > backed cache... unfortunately, the cache we are talking about is in RAM, > not your IO controller. So put a UPS on there, and you are safe except > when you get a kernel panic (which is what happened to cause my > corruption). But if you get something like the Gigabyte iRAM or the > Acard ANS-9010 > , > set it as your ZIL, and leave sync=standard, you should be safer. (I > don't know if the iRAM works in FreeBSD, but someone > > told me he uses the ANS-9010) > > And NFS with ZFS is not horrible, except with ESXi's built in NFS client > it uses for datastores. (the same someone that said he uses the > ANS-9010 also provides a 'patch' for the FreeBSD NFS server that > disables ESXi's stupid behavior, without disabling sync entirely, but > also possibly disables it for others that use it responsibly [a database > perhaps]) > > here > > is a fantastic study about NFS; dunno if this study resulted in patches > now in use or not, or how old it is [newest reference is 2002, so at > most 10 years old]. In my experience, the write caching in use today > still sucks. If I run async with sync=disabled, I can still see a huge > improvement (20% on large files, up to 100% for smaller files <200MB) > using an ESXi virtual disk (with ext4 doing write caching) compared to > NFS directly. > > > Here begins the rant about ESXi, which may be off topic: > ESXi 3.5, 4.0, 4.1, 5.0, or all of the above? > ESXi goes 7 MB/s with an SSD ZIL at 100% load, and 80 MB/s with a > ramdisk ZIL at 100% load (pathetic!), > something I can't reproduce (thought it was just a normal Linux client > with "-o sync" over 10 Gbps ethernet) got over 70MB/s with the ZIL at > 70-90% load, > and other clients set to "-o sync,noatime,..." or "-o noatime,..."with > the ZIL only randomly 0-5% load, but go faster than 100 MB/s. I didn't > test "async", and without "sync", they seem to go the same speed. > setting sync=disabled always goes around 100 MB/s, and changes the load > on the ZIL to 0%. > > The thing I can't reproduce might have been only possible on a pool that > I created with FreeBSD 8.2-RELEASE and then upgraded, which I no longer > have. Or maybe it was with "sync" without "noatime". > > I am going to test with 9000 MTU, and if it is not much faster, I am > giving up on NFS. My original plan was to use ESXi with a ZFS datastore > with a replicated backup. That works terribly using the ESXi NFS client. > Netbooting the OSses to bypass the ESXi client works much better, but > still not good enough for many servers. NFS is poorly implemented, with > terrible write caching on the client side. Now my plan is to use FreeBSD > with VirtualBox and ZFS all in one system, and send replication > snapshots from there. I wanted to use ESXi, but I guess I can't. > > And the worst thing about ESXi, is if you have 1 client going 7MB/s, the > second client has to share that 7MB/s, and non-ESXi clients will still > go horribly slow. If you have 10 non-ESXi clients going at 100 MB/s, > each one is limited to around 100 MB/s (again I only tested this with > 1500 MTU so far), but together they can write much more. > > Just now I tested 2 clients writing 100+100 MB/s (reported by GNU dd), > and 3 writing 50+60+60 MB/s (reported by GNU dd) > Output from "zpool iostat 5": > two clients: > tank 38.7T 4.76T 0 1.78K 25.5K 206M (matches 100+100) > three clients: > tank 38.7T 4.76T 1 2.44K 205K 245M (does not match > 60+60+50) > > (one client is a Linux netboot, and the others are using the Linux NFS > client) > > But I am not an 'official', so this cannot be considered 'officially > clarified' ;) > > > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > From owner-freebsd-fs@FreeBSD.ORG Tue Jan 31 05:29:27 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB647106566C for ; Tue, 31 Jan 2012 05:29:27 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 919DE8FC08 for ; Tue, 31 Jan 2012 05:29:27 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAFJ7J0+DaFvO/2dsb2JhbABDhQuqXYFyAQEFI1YbDgoCAg0ZAlkGrzWRdYEviVMBBQICHQMEAQ4BCAUDAwkNEoJxAgYFAgQMBg0DCQICcxkCBIIjgRYEiECMXpJw X-IronPort-AV: E=Sophos;i="4.71,594,1320642000"; d="scan'208";a="154396201" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 31 Jan 2012 00:29:26 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 7CECBB3F24; Tue, 31 Jan 2012 00:29:26 -0500 (EST) Date: Tue, 31 Jan 2012 00:29:26 -0500 (EST) From: Rick Macklem To: Jeremy Chadwick Message-ID: <1413501962.445071.1327987766416.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120126082208.GA49394@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: Is doing mount -u -o udp useful for you on an NFS mount? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 05:29:27 -0000 Jeremy Chadwick wrote: > On Wed, Jan 25, 2012 at 11:01:41PM -0500, Rick Macklem wrote: > > Using a "mount -u" to change from TCP to UDP for an > > NFS mount is somewhat broken for both NFS clients. > > To make it work correctly is not trivial. > > > > As such, I'd like to find out if anyone needs this > > capability? (Note, I am not talking about UDP mounts > > in general, just the case of switching a TCP mount to > > a UDP mount without doing an unmount/mount.) > > I've never seen any SAN admin do this, even on our production server > at > work (Solaris with a NetApp SAN). When it comes to NFS, the moral of > the story is always "reboot the machine" (which is good anyway, make > sure everything comes up on boot, else months from now you'll find out > the hard way). > > However, to squelch people from doing it, could mount_nfs(8) actually > be > modified to spit out a nastygram when someone attempts to do this, so > at > least the admin would know that such isn't supported due to the > extreme > complexities involved? > I've just committed a patch that sends a log warning message when someone does this. Thanks for the suggestion, rick From owner-freebsd-fs@FreeBSD.ORG Tue Jan 31 08:09:23 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 020C8106566C for ; Tue, 31 Jan 2012 08:09:23 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 85FC58FC15 for ; Tue, 31 Jan 2012 08:09:22 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LwGGE-1Sf13v0hcU-017W4I; Tue, 31 Jan 2012 09:09:21 +0100 Message-ID: <4F27A1B0.2060303@brockmann-consult.de> Date: Tue, 31 Jan 2012 09:09:20 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: Dennis Glatting References: <4F264B27.6060502@brockmann-consult.de> <1327955423.22960.0.camel@btw.pki2.com> In-Reply-To: <1327955423.22960.0.camel@btw.pki2.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:DTBbGIIym/q/RG8GdPw54YxlsW2vlYW3fatMjpRGUhn C1MWiC6fBCX9+iH/Oy8EYnhiovV07N2Rdg+8gKcv/2vwFrit+X hty4kyGynB7jNODGs3ekeUO7UA83+0HqPmZb+2FYfzNJgoBnin pZuNa/IdnWTOakeg0pQgGwveN+26RRIiPNf/AEYZ6c8jwzoQG4 7vom3IKWJ28bQvSYb6atkjaO2KlFi5eL9NWHL9m2ggUwwT+XsT hICl03gMfzyx24f/viWDwsR5x4cIph63LF/4czFbtArhBGhzbx aSdSQf3leF4DR3JQLbwAiQuBao8xXlqEg6SrZtfsIL58qGpbq+ aKrR904NaeXJ/4CpQrsGiMdAsqDbsGwDKY8yRPl29 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS sync / ZIL clarification X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 08:09:23 -0000 On 01/30/2012 09:30 PM, Dennis Glatting wrote: > On Mon, 2012-01-30 at 08:47 +0100, Peter Maloney wrote: >> On 01/30/2012 05:30 AM, Mark Felder wrote: >>> I believe I was told something misleading a few weeks ago and I'd like >>> to have this officially clarified. >>> >>> NFS on ZFS is horrible unless you have sync = disabled. >> With ESXi = true >> with others = depends on your definition of horrible >> >>> I was told this was effectively disabling the ZIL, which is of course >>> naughty. Now I stumbled upon this tonight: >>> >> true only for the specific dataset you specified >> eg. >> zfs set sync=disabled tank/esxi >> >>>> Just for the archives... sync=disabled won't disable disable the >>>> zil,it'll disable waiting for a disk-flush on fsync etc. >> Same thing... "waiting for a disk-flush" is the only time the ZIL is >> used, from what I understand. >> >>>> With a batterybacked controller cache, those flushes should go to >>>> cache, and bepretty mich free. You end up tossing away something for >>>> nothing. >> False I guess. Would be nice, but how do you battery back your RAM, >> which ZFS uses as a write cache? (If you know something I don't know, >> please share.) >>> Is this accurate? >> sync=disabled caused data corruption for me. So you need to have battery >> backed cache... unfortunately, the cache we are talking about is in RAM, >> not your IO controller. So put a UPS on there, and you are safe except >> when you get a kernel panic (which is what happened to cause my >> corruption). But if you get something like the Gigabyte iRAM or the >> Acard ANS-9010 >> , >> set it as your ZIL, and leave sync=standard, you should be safer. (I >> don't know if the iRAM works in FreeBSD, but someone >> >> told me he uses the ANS-9010) >> >> And NFS with ZFS is not horrible, except with ESXi's built in NFS client >> it uses for datastores. (the same someone that said he uses the >> ANS-9010 also provides a 'patch' for the FreeBSD NFS server that >> disables ESXi's stupid behavior, without disabling sync entirely, but >> also possibly disables it for others that use it responsibly [a database >> perhaps]) >> >> here >> >> is a fantastic study about NFS; dunno if this study resulted in patches >> now in use or not, or how old it is [newest reference is 2002, so at >> most 10 years old]. In my experience, the write caching in use today >> still sucks. If I run async with sync=disabled, I can still see a huge >> improvement (20% on large files, up to 100% for smaller files <200MB) >> using an ESXi virtual disk (with ext4 doing write caching) compared to >> NFS directly. >> >> >> Here begins the rant about ESXi, which may be off topic: >> > ESXi 3.5, 4.0, 4.1, 5.0, or all of the above? > I didn't know 5.0.0 was available for free. Thanks for the notice. My testing has been with 4.1.0 build 348481, but if you look around on the net, you will find no official sensible workarounds/fixes/etc.. They don't even acknowledge the issue is in the ESXi NFS client... even though it is obvious. So I doubt the problem will be fixed any time soon. Even using the "sync" option is discouraged, and they actually go do the absolute worst thing and send O_SYNC with every write (even when saving state of a VM; I turn off sync in zfs when I do this). Some groups have some solutions that mitigate but do not eliminate the problem. The issue also exists with other file systems and platforms, but it seems the worst on ZFS. I couldn't find anything equivalent to those solutions that work on FreeBSD and ZFS. The closest is the patch I mentioned above (http://christopher-technicalmusings.blogspot.com/2011/06/speeding-up-freebsds-nfs-on-zfs-for-esx.html) which possibly would result in data corruption for non-ESXi connections to your NFS server that responsibly use the O_SYNC flag. I didn't test that patch, because I would rather just throw away ESXi. I hate how much it limits you (no software raid, no file system choice, no rsync, no firewall, top, iostat, etc.). And it handles network interruptions terribly... in some cases you need to reboot to get it to find all the .vmx files again. In other cases hacks work to reconnect to the NFS mounts. But many just simply switch to iSCSI. And from what I've heard, iSCSI also sucks on ESXi with the default settings, but a single setting fixes most of the problem. I'm not sure if this applies to FreeBSD or ZFS (didn't test it yet). Here are some pages from the starwind forum (where we can assume their servers are Windows based): Here they say "doing Write-Back Cache helps but not completely" (Windows specific) http://www.starwindsoftware.com/forums/starwind-f5/esxi-iscsi-initiator-write-speed-t2398-15.html And here is something (Windows specific) about changing the ACK timing: http://www.starwindsoftware.com/forums/starwind-f5/esxi-iscsi-initiator-write-speed-t2398.html And here is some other page that ended up in my bookmarks: http://www.starwindsoftware.com/forums/starwind-f5/recommended-settings-for-esx-iscsi-initiator-t2296.html Somewhere on those 3 or linked somewhere (can't find it now), there are instructions to turn off "Delayed ACK" (in ESXi): in ESXi, click the host click "Configuration" tab. Click "Storage Adapters" find and select the "iSCSI Software Adapter" click "properties" (a blue link on the right, in the "details" section) click "advanced" (must be enabled or this button is greyed out) look for the "Delayed ACK" option in there somewhere (at the end in my list), and uncheck the box. And this is said to improve things considerably, but I didn't iSCSI at all on ESXi or ZFS. I wanted to test iSCSI on ZFS, but I found zvols to be buggy... so I decided to avoid them. So I am not very motivated to try again. I guess I can work around buggy zvols by using a loop device for a file instead of a zvol... but I am always too busy. Give it a few months. >> ESXi goes 7 MB/s with an SSD ZIL at 100% load, and 80 MB/s with a >> ramdisk ZIL at 100% load (pathetic!), >> something I can't reproduce (thought it was just a normal Linux client >> with "-o sync" over 10 Gbps ethernet) got over 70MB/s with the ZIL at >> 70-90% load, >> and other clients set to "-o sync,noatime,..." or "-o noatime,..."with >> the ZIL only randomly 0-5% load, but go faster than 100 MB/s. I didn't >> test "async", and without "sync", they seem to go the same speed. >> setting sync=disabled always goes around 100 MB/s, and changes the load >> on the ZIL to 0%. >> >> The thing I can't reproduce might have been only possible on a pool that >> I created with FreeBSD 8.2-RELEASE and then upgraded, which I no longer >> have. Or maybe it was with "sync" without "noatime". >> >> I am going to test with 9000 MTU, and if it is not much faster, I am >> giving up on NFS. My original plan was to use ESXi with a ZFS datastore >> with a replicated backup. That works terribly using the ESXi NFS client. >> Netbooting the OSses to bypass the ESXi client works much better, but >> still not good enough for many servers. NFS is poorly implemented, with >> terrible write caching on the client side. Now my plan is to use FreeBSD >> with VirtualBox and ZFS all in one system, and send replication >> snapshots from there. I wanted to use ESXi, but I guess I can't. >> >> And the worst thing about ESXi, is if you have 1 client going 7MB/s, the >> second client has to share that 7MB/s, and non-ESXi clients will still >> go horribly slow. If you have 10 non-ESXi clients going at 100 MB/s, >> each one is limited to around 100 MB/s (again I only tested this with >> 1500 MTU so far), but together they can write much more. >> >> Just now I tested 2 clients writing 100+100 MB/s (reported by GNU dd), >> and 3 writing 50+60+60 MB/s (reported by GNU dd) >> Output from "zpool iostat 5": >> two clients: >> tank 38.7T 4.76T 0 1.78K 25.5K 206M (matches 100+100) >> three clients: >> tank 38.7T 4.76T 1 2.44K 205K 245M (does not match >> 60+60+50) >> >> (one client is a Linux netboot, and the others are using the Linux NFS >> client) >> >> But I am not an 'official', so this cannot be considered 'officially >> clarified' ;) >> >> >>> _______________________________________________ >>> 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" >> > -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Tue Jan 31 09:36:26 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80BA6106568B for ; Tue, 31 Jan 2012 09:36:26 +0000 (UTC) (envelope-from kykypyky2@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 3CAF58FC1D for ; Tue, 31 Jan 2012 09:36:25 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Rs9rT-0002c6-0J for freebsd-fs@freebsd.org; Tue, 31 Jan 2012 01:18:47 -0800 Date: Tue, 31 Jan 2012 01:18:47 -0800 (PST) From: Shelm To: freebsd-fs@freebsd.org Message-ID: <1328001527003-5444043.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Hast Unable to listen on address X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 09:36:26 -0000 hi Unable to listen on address 10.20.4.7: Can't assign requested address hast.conf on m1(real domain) { listen 10.10.4.7 } on m2(real domain) { listen 10.20.4.7 } resource shared { on m1 { local /dev/da1 remote 10.20.4.7 } on m2 { local /dev/da1 remote 10.10.4.7 } } m1 connect --Unable to listen on address 10.20.4.7: Can't assign requested address m2 connect --hastctl status shared: role: init provname: shared localpath: /dev/da1 extentsize: 0 keepdirty: 0 remoteaddr: 10.10.4.7 replication: memsync dirty: 0 bytes -- View this message in context: http://freebsd.1045724.n5.nabble.com/Hast-Unable-to-listen-on-address-tp5444043p5444043.html Sent from the freebsd-fs mailing list archive at Nabble.com. From owner-freebsd-fs@FreeBSD.ORG Tue Jan 31 09:55:28 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 845851065670 for ; Tue, 31 Jan 2012 09:55:28 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 2E3DB8FC16 for ; Tue, 31 Jan 2012 09:55:27 +0000 (UTC) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta13.westchester.pa.mail.comcast.net with comcast id U9s11i0021GhbT85D9vU5N; Tue, 31 Jan 2012 09:55:28 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta07.westchester.pa.mail.comcast.net with comcast id U9vT1i00P1t3BNj3T9vTyE; Tue, 31 Jan 2012 09:55:28 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CA9FA102C1E; Tue, 31 Jan 2012 01:55:25 -0800 (PST) Date: Tue, 31 Jan 2012 01:55:25 -0800 From: Jeremy Chadwick To: Shelm Message-ID: <20120131095525.GA67112@icarus.home.lan> References: <1328001527003-5444043.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1328001527003-5444043.post@n5.nabble.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Hast Unable to listen on address X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 09:55:28 -0000 On Tue, Jan 31, 2012 at 01:18:47AM -0800, Shelm wrote: > hi > Unable to listen on address 10.20.4.7: Can't assign requested address > > hast.conf > > on m1(real domain) > { > listen 10.10.4.7 > } > > on m2(real domain) > { > listen 10.20.4.7 > } > > resource shared > { > on m1 > { > local /dev/da1 > remote 10.20.4.7 > } > on m2 > { > local /dev/da1 > remote 10.10.4.7 > } > } > > > > m1 connect --Unable to listen on address 10.20.4.7: Can't assign requested > address > m2 connect --hastctl status > shared: > role: init > provname: shared > localpath: /dev/da1 > extentsize: 0 > keepdirty: 0 > remoteaddr: 10.10.4.7 > replication: memsync > dirty: 0 bytes Please provide the following from the machine "m2" (the box which clims to be 10.20.4.7): * Output from: ifconfig -a * Output from: netstat -rn * Whether or not the machine uses ipfw or pf - If so, which - Provide the rules you're using -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Tue Jan 31 10:09:03 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12747106566C for ; Tue, 31 Jan 2012 10:09:03 +0000 (UTC) (envelope-from kykypyky2@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id DE3708FC08 for ; Tue, 31 Jan 2012 10:09:02 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RsAe6-00005m-9T for freebsd-fs@freebsd.org; Tue, 31 Jan 2012 02:09:02 -0800 Date: Tue, 31 Jan 2012 02:09:02 -0800 (PST) From: Shelm To: freebsd-fs@freebsd.org Message-ID: <1328004542281-5444145.post@n5.nabble.com> In-Reply-To: <20120131095525.GA67112@icarus.home.lan> References: <1328001527003-5444043.post@n5.nabble.com> <20120131095525.GA67112@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Hast Unable to listen on address X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 10:09:03 -0000 ifconfig -a em0: flags=8843 metric 0 mtu 1500 options=219b ether 00:*********** inet 213.***.***.*** netmask 0xfffffff8 broadcast 213.***.***.*** media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=219b ether 00:*********** inet 10.20.4.7 netmask 0xffffff00 broadcast 10.20.4.255 media: Ethernet autoselect (1000baseT ) status: active netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 213.***.****.*** UGS 3 2061 em0 10.0.0.0/16 10.20.4.10 UGS 0 0 em1 10.10.4.0/24 10.20.4.10 UGS 2 2926 em1 10.20.4.0/24 link#2 U 0 43 em1 10.20.4.7 link#2 UHS 0 0 lo0 127.0.0.1 link#4 UH 0 14157 lo0 131.0.0.0/24 10.20.4.10 UGS 0 0 em1 213.***.****.*** /29 link#1 U 0 0 em0 213.***.****.*** link#1 UHS 0 0 lo0 ipfw rule OPEN -- View this message in context: http://freebsd.1045724.n5.nabble.com/Hast-Unable-to-listen-on-address-tp5444043p5444145.html Sent from the freebsd-fs mailing list archive at Nabble.com. From owner-freebsd-fs@FreeBSD.ORG Tue Jan 31 11:39:28 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58C061065670 for ; Tue, 31 Jan 2012 11:39:28 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) by mx1.freebsd.org (Postfix) with ESMTP id 16C798FC1D for ; Tue, 31 Jan 2012 11:39:28 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by btw.pki2.com (8.14.5/8.14.5) with ESMTP id q0VBdK9p072083; Tue, 31 Jan 2012 03:39:20 -0800 (PST) (envelope-from freebsd@penx.com) From: Dennis Glatting To: Peter Maloney In-Reply-To: <4F27A1B0.2060303@brockmann-consult.de> References: <4F264B27.6060502@brockmann-consult.de> <1327955423.22960.0.camel@btw.pki2.com> <4F27A1B0.2060303@brockmann-consult.de> Content-Type: text/plain; charset="us-ascii" Date: Tue, 31 Jan 2012 03:39:20 -0800 Message-ID: <1328009960.24125.26.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Dennis Glatting X-yoursite-MailScanner-ID: q0VBdK9p072083 X-yoursite-MailScanner: Found to be clean X-MailScanner-From: freebsd@penx.com Cc: freebsd-fs@freebsd.org Subject: Re: ZFS sync / ZIL clarification X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 11:39:28 -0000 On Tue, 2012-01-31 at 09:09 +0100, Peter Maloney wrote: > On 01/30/2012 09:30 PM, Dennis Glatting wrote: > > On Mon, 2012-01-30 at 08:47 +0100, Peter Maloney wrote: > >> On 01/30/2012 05:30 AM, Mark Felder wrote: > >>> I believe I was told something misleading a few weeks ago and I'd like > >>> to have this officially clarified. > >>> > >>> NFS on ZFS is horrible unless you have sync = disabled. > >> With ESXi = true > >> with others = depends on your definition of horrible > >> > >>> I was told this was effectively disabling the ZIL, which is of course > >>> naughty. Now I stumbled upon this tonight: > >>> > >> true only for the specific dataset you specified > >> eg. > >> zfs set sync=disabled tank/esxi > >> > >>>> Just for the archives... sync=disabled won't disable disable the > >>>> zil,it'll disable waiting for a disk-flush on fsync etc. > >> Same thing... "waiting for a disk-flush" is the only time the ZIL is > >> used, from what I understand. > >> > >>>> With a batterybacked controller cache, those flushes should go to > >>>> cache, and bepretty mich free. You end up tossing away something for > >>>> nothing. > >> False I guess. Would be nice, but how do you battery back your RAM, > >> which ZFS uses as a write cache? (If you know something I don't know, > >> please share.) > >>> Is this accurate? > >> sync=disabled caused data corruption for me. So you need to have battery > >> backed cache... unfortunately, the cache we are talking about is in RAM, > >> not your IO controller. So put a UPS on there, and you are safe except > >> when you get a kernel panic (which is what happened to cause my > >> corruption). But if you get something like the Gigabyte iRAM or the > >> Acard ANS-9010 > >> , > >> set it as your ZIL, and leave sync=standard, you should be safer. (I > >> don't know if the iRAM works in FreeBSD, but someone > >> > >> told me he uses the ANS-9010) > >> > >> And NFS with ZFS is not horrible, except with ESXi's built in NFS client > >> it uses for datastores. (the same someone that said he uses the > >> ANS-9010 also provides a 'patch' for the FreeBSD NFS server that > >> disables ESXi's stupid behavior, without disabling sync entirely, but > >> also possibly disables it for others that use it responsibly [a database > >> perhaps]) > >> > >> here > >> > >> is a fantastic study about NFS; dunno if this study resulted in patches > >> now in use or not, or how old it is [newest reference is 2002, so at > >> most 10 years old]. In my experience, the write caching in use today > >> still sucks. If I run async with sync=disabled, I can still see a huge > >> improvement (20% on large files, up to 100% for smaller files <200MB) > >> using an ESXi virtual disk (with ext4 doing write caching) compared to > >> NFS directly. > >> > >> > >> Here begins the rant about ESXi, which may be off topic: > >> > > ESXi 3.5, 4.0, 4.1, 5.0, or all of the above? > > > I didn't know 5.0.0 was available for free. Thanks for the notice. > I downloaded ESXi 5.0 when it was free eval but since licensed it. > My testing has been with 4.1.0 build 348481, but if you look around on > the net, you will find no official sensible workarounds/fixes/etc.. They > don't even acknowledge the issue is in the ESXi NFS client... even > though it is obvious. So I doubt the problem will be fixed any time > soon. Even using the "sync" option is discouraged, and they actually go > do the absolute worst thing and send O_SYNC with every write (even when > saving state of a VM; I turn off sync in zfs when I do this). Some > groups have some solutions that mitigate but do not eliminate the > problem. The issue also exists with other file systems and platforms, > but it seems the worst on ZFS. I couldn't find anything equivalent to > those solutions that work on FreeBSD and ZFS. The closest is the patch I > mentioned above > (http://christopher-technicalmusings.blogspot.com/2011/06/speeding-up-freebsds-nfs-on-zfs-for-esx.html) > which possibly would result in data corruption for non-ESXi connections > to your NFS server that responsibly use the O_SYNC flag. I didn't test > that patch, because I would rather just throw away ESXi. I hate how much > it limits you (no software raid, no file system choice, no rsync, no > firewall, top, iostat, etc.). And it handles network interruptions > terribly... in some cases you need to reboot to get it to find all the > .vmx files again. In other cases hacks work to reconnect to the NFS mounts. > > But many just simply switch to iSCSI. And from what I've heard, iSCSI > also sucks on ESXi with the default settings, but a single setting fixes > most of the problem. I'm not sure if this applies to FreeBSD or ZFS > (didn't test it yet). Here are some pages from the starwind forum (where > we can assume their servers are Windows based): > A buddy does iSCSI by default. I can't say he ever tried NFS. He mentioned performance questions but hadn't recent data. My server, presently, is a PoS in need of a rebuild (it started out as ESXi 5.0 eval but then became useful) -- obtaining disks and other priorities are the present impediment to rebuild. I need to include shares and I /think/ remote disks (I also want to do some analysis of combining disparate remote disks). I've been working with big data (<35TB) and want to assign an instance (FreeBSD) as one of my engines. About 80% of my ESXi usage is prototyping and product eval. > Here they say "doing Write-Back Cache helps but not completely" (Windows > specific) > http://www.starwindsoftware.com/forums/starwind-f5/esxi-iscsi-initiator-write-speed-t2398-15.html > > And here is something (Windows specific) about changing the ACK timing: > http://www.starwindsoftware.com/forums/starwind-f5/esxi-iscsi-initiator-write-speed-t2398.html > > And here is some other page that ended up in my bookmarks: > http://www.starwindsoftware.com/forums/starwind-f5/recommended-settings-for-esx-iscsi-initiator-t2296.html > > Somewhere on those 3 or linked somewhere (can't find it now), there are > instructions to turn off "Delayed ACK" (in ESXi): > > in ESXi, click the host > click "Configuration" tab. > Click "Storage Adapters" > find and select the "iSCSI Software Adapter" > click "properties" (a blue link on the right, in the "details" section) > click "advanced" (must be enabled or this button is greyed out) > look for the "Delayed ACK" option in there somewhere (at the end in my > list), and uncheck the box. > > And this is said to improve things considerably, but I didn't iSCSI at > all on ESXi or ZFS. > > I wanted to test iSCSI on ZFS, but I found zvols to be buggy... so I > decided to avoid them. So I am not very motivated to try again. > > I guess I can work around buggy zvols by using a loop device for a file > instead of a zvol... but I am always too busy. Give it a few months. > When I looked into iSCSI/zvol, ZFS was 1.5 under FreeBSD and the limitations were many. I haven't looked at 2.8. I can't say I find ESXi the most wonderful thing in the world but if I started to rant this text would go on for pages. Thanks for the info. > >> ESXi goes 7 MB/s with an SSD ZIL at 100% load, and 80 MB/s with a > >> ramdisk ZIL at 100% load (pathetic!), > >> something I can't reproduce (thought it was just a normal Linux client > >> with "-o sync" over 10 Gbps ethernet) got over 70MB/s with the ZIL at > >> 70-90% load, > >> and other clients set to "-o sync,noatime,..." or "-o noatime,..."with > >> the ZIL only randomly 0-5% load, but go faster than 100 MB/s. I didn't > >> test "async", and without "sync", they seem to go the same speed. > >> setting sync=disabled always goes around 100 MB/s, and changes the load > >> on the ZIL to 0%. > >> > >> The thing I can't reproduce might have been only possible on a pool that > >> I created with FreeBSD 8.2-RELEASE and then upgraded, which I no longer > >> have. Or maybe it was with "sync" without "noatime". > >> > >> I am going to test with 9000 MTU, and if it is not much faster, I am > >> giving up on NFS. My original plan was to use ESXi with a ZFS datastore > >> with a replicated backup. That works terribly using the ESXi NFS client. > >> Netbooting the OSses to bypass the ESXi client works much better, but > >> still not good enough for many servers. NFS is poorly implemented, with > >> terrible write caching on the client side. Now my plan is to use FreeBSD > >> with VirtualBox and ZFS all in one system, and send replication > >> snapshots from there. I wanted to use ESXi, but I guess I can't. > >> > >> And the worst thing about ESXi, is if you have 1 client going 7MB/s, the > >> second client has to share that 7MB/s, and non-ESXi clients will still > >> go horribly slow. If you have 10 non-ESXi clients going at 100 MB/s, > >> each one is limited to around 100 MB/s (again I only tested this with > >> 1500 MTU so far), but together they can write much more. > >> > >> Just now I tested 2 clients writing 100+100 MB/s (reported by GNU dd), > >> and 3 writing 50+60+60 MB/s (reported by GNU dd) > >> Output from "zpool iostat 5": > >> two clients: > >> tank 38.7T 4.76T 0 1.78K 25.5K 206M (matches 100+100) > >> three clients: > >> tank 38.7T 4.76T 1 2.44K 205K 245M (does not match > >> 60+60+50) > >> > >> (one client is a Linux netboot, and the others are using the Linux NFS > >> client) > >> > >> But I am not an 'official', so this cannot be considered 'officially > >> clarified' ;) > >> > >> > >>> _______________________________________________ > >>> freebsd-fs@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs > >>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > >> > > > > From owner-freebsd-fs@FreeBSD.ORG Tue Jan 31 16:16:12 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 883791065673 for ; Tue, 31 Jan 2012 16:16:12 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) by mx1.freebsd.org (Postfix) with ESMTP id 55D178FC0C for ; Tue, 31 Jan 2012 16:16:12 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by btw.pki2.com (8.14.5/8.14.5) with ESMTP id q0VGG62p080930; Tue, 31 Jan 2012 08:16:06 -0800 (PST) (envelope-from freebsd@penx.com) From: Dennis Glatting To: Peter Maloney In-Reply-To: <4F27A1B0.2060303@brockmann-consult.de> References: <4F264B27.6060502@brockmann-consult.de> <1327955423.22960.0.camel@btw.pki2.com> <4F27A1B0.2060303@brockmann-consult.de> Content-Type: text/plain; charset="us-ascii" Date: Tue, 31 Jan 2012 08:16:06 -0800 Message-ID: <1328026566.80275.11.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Dennis Glatting X-yoursite-MailScanner-ID: q0VGG62p080930 X-yoursite-MailScanner: Found to be clean X-MailScanner-From: freebsd@penx.com Cc: freebsd-fs@freebsd.org Subject: Re: ZFS sync / ZIL clarification X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 16:16:12 -0000 It was pointed out off-list that my prior message was unclear and confusing. This is my attempt at unconfusing. :) My notation of "ZFS 2.8" is "ZFS Version 28," and "ZFS 1.5" to ZFS Version 15. In reference to confusion to FreeBSD versions, I run two, which is RELENG_8 generally being migrated to RELENG_9. There are three servers in one rack that are likely never to be upgraded and I hope to roll that rack to permanent storage and replace it with a newer design (it would literally be wrapped in plastic and rolled into a warehouse). I designed (generally), built, and I am running three infrastructures. Two of them are in the manufacturing industry and one is my personal lab, currently at 58 cores on its way to 74 by the end of the week, if you don't count one of the servers, various PCs and laptops, and Hyper Threading on the Intel chips. Some of those servers are over clocked and some liquid cooled simply because I was bored and it sounded fun. Oh, and the spouse has banished my noisy servers to the garage (work in progress -- cabling power, etc). From owner-freebsd-fs@FreeBSD.ORG Tue Jan 31 20:36:43 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6A43106564A for ; Tue, 31 Jan 2012 20:36:43 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 63F568FC12 for ; Tue, 31 Jan 2012 20:36:42 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so481361wib.13 for ; Tue, 31 Jan 2012 12:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EJJhxh2Wm97vMcGYqpANIA/ANaXHKcDEbllyKwIVW9s=; b=ErHV7VVAtfMR87Mz6GzWMcNd7B6cmSKJPY6xU16FhrTSrjGQ5loBsfnAM+DN53/I0k clb0NQXDNfsufw0S9Qo9HMkVhEo0D+aBVm26LpmuK5vbHav6Yjpf8l6d+29YtsxRwL8j DHTNRQ4Km7fQLWsHRXoe3ubHRXguEczrViisQ= Received: by 10.180.94.97 with SMTP id db1mr37228173wib.16.1328042200851; Tue, 31 Jan 2012 12:36:40 -0800 (PST) Received: from [192.168.1.14] (5ED0E470.cm-7-1d.dynamic.ziggo.nl. [94.208.228.112]) by mx.google.com with ESMTPS id fr8sm66337385wib.10.2012.01.31.12.36.39 (version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 12:36:39 -0800 (PST) Message-ID: <4F2850D4.9000207@gmail.com> Date: Tue, 31 Jan 2012 21:36:36 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Mark Felder References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: ZFS sync / ZIL clarification X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 20:36:43 -0000 Mark Felder schreef: > I believe I was told something misleading a few weeks ago and I'd like > to have this officially clarified. > > NFS on ZFS is horrible unless you have sync = disabled. I was told > this was effectively disabling the ZIL, which is of course naughty. > Now I stumbled upon this tonight: Well i did a test from my ESXi 5.0 server. That server has a local store (2 x 146 GB 15k SAS drives) The ESXi server is a HP proliant ML380 with 60 GB mem. The ZFS server is a supermicro 3U 16 bay storage server, with a zpool created with mirrors from all the old disk we have. this are 80 GB drives, 250 GB drives 750 GB drives, all sata and some of them nearly passes smartctl and one is already marked failed :D.. The machines are connected through a simple 8 port HP 1Gb switch. If i do a copy from the local store to the NFS store, performance is bad, well very bad. Below is the performance graph from the esxi host. During the copy i did the zfs set sync=disabled sanstore/ESXishare-bck command. http://doub.home.xs4all.nl/bench/sync.png You see that the speed goes up, not a little, but it almost makes the older copy graph invisable. ESXi + ZFS without sync is disabled is a no go. regards Johan Hendriks From owner-freebsd-fs@FreeBSD.ORG Wed Feb 1 01:14:14 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72E04106564A for ; Wed, 1 Feb 2012 01:14:14 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 584528FC18 for ; Wed, 1 Feb 2012 01:14:14 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id q1110pfM092973 for ; Tue, 31 Jan 2012 17:00:55 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201202010100.q1110pfM092973@gw.catspoiler.org> Date: Tue, 31 Jan 2012 17:00:51 -0800 (PST) From: Don Lewis To: freebsd-fs@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: Subject: CFR patch to improve fsdb sparse file handling X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 01:14:14 -0000 A while back I noticed that fsdb bailed out early if it was asked to print the block list for a file with a hole in its direct block list. At the time I just commented out the early return. Recently I had a chance to revisit this code and came up with what I think is a better patch. I thought it would be more informative to print out the NULL block pointers to make it clear that the file is sparse even though the existing code that handles the indirect blocks skips over the holes. The code that printed the fragment count looked too much like an entry in an obfuscated C contest, so I simplified it a bit. I tried to match the existing style instead of changing it to match style(9). Index: sbin/fsdb/fsdbutil.c =================================================================== --- sbin/fsdb/fsdbutil.c (revision 230604) +++ sbin/fsdb/fsdbutil.c (working copy) @@ -293,22 +293,21 @@ printf("Blocks for inode %d:\n", inum); printf("Direct blocks:\n"); ndb = howmany(DIP(dp, di_size), sblock.fs_bsize); - for (i = 0; i < NDADDR; i++) { - if (DIP(dp, di_db[i]) == 0) { - putchar('\n'); - return; - } + for (i = 0; i < NDADDR && i < ndb; i++) { if (i > 0) printf(", "); blkno = DIP(dp, di_db[i]); printf("%jd", (intmax_t)blkno); - if (--ndb == 0 && (offset = blkoff(&sblock, DIP(dp, di_size))) != 0) { + } + if (ndb <= NDADDR) { + offset = blkoff(&sblock, DIP(dp, di_size)); + if (offset != 0) { nfrags = numfrags(&sblock, fragroundup(&sblock, offset)); printf(" (%d frag%s)", nfrags, nfrags > 1? "s": ""); } } putchar('\n'); - if (ndb == 0) + if (ndb <= NDADDR) return; bufp = malloc((unsigned int)sblock.fs_bsize); From owner-freebsd-fs@FreeBSD.ORG Wed Feb 1 06:14:12 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B73C1065672; Wed, 1 Feb 2012 06:14:12 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (unknown [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id 457C38FC08; Wed, 1 Feb 2012 06:14:12 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id q116E4Fo057942; Tue, 31 Jan 2012 22:14:04 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201202010614.q116E4Fo057942@chez.mckusick.com> To: Don Lewis In-reply-to: <201202010100.q1110pfM092973@gw.catspoiler.org> Date: Tue, 31 Jan 2012 22:14:04 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: freebsd-fs@freebsd.org Subject: Re: CFR patch to improve fsdb sparse file handling X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 06:14:12 -0000 Your change looks reasonable to me. A more elaborate (e.g., compact listing) scheme that I wrote for printing out block numbers is given below. Not sure if it is worth adapting to use in fsdb. Kirk McKusick =-=-= /* * Copyright (c) 1998 Marshall Kirk McKusick. All Rights Reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY MARSHALL KIRK MCKUSICK ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL MARSHALL KIRK MCKUSICK BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ #include #include #include #include #include #include #include #include #include #include #include #include #include union dinode { struct ufs1_dinode *dp1; struct ufs2_dinode *dp2; }; struct fs *sbp; char *fsname; int fd; void indirprt(int blksperindir, int lbn, ufs2_daddr_t blkno, int lastlbn); void printblk(int lbn, ufs2_daddr_t blkno, int numblks, int lastlbn); /* * Possible superblock locations ordered from most to least likely. */ static int sblock_try[] = SBLOCKSEARCH; int main(argc, argv) int argc; char *argv[]; { int i, len, lbn, frags, inonum, numblks, blksperindir; char sblock[SBLOCKSIZE], ibuf[MAXBSIZE]; ufs2_daddr_t blkno; off_t size, offset; union dinode dp; if (argc < 3) { (void)fprintf(stderr,"usage: prtblknos filesystem inode ...\n"); exit(1); } fsname = *++argv; /* get the superblock. */ if ((fd = open(fsname, O_RDONLY, 0)) < 0) err(1, "%s", fsname); for (i = 0; sblock_try[i] != -1; i++) { if (lseek(fd, sblock_try[i], SEEK_SET) < 0) err(1, "lseek: %s", fsname); if (read(fd, sblock, (long)SBLOCKSIZE) != SBLOCKSIZE) err(1, "can't read superblock: %s", fsname); sbp = (struct fs *)sblock; if ((sbp->fs_magic == FS_UFS1_MAGIC || (sbp->fs_magic == FS_UFS2_MAGIC && sbp->fs_sblockloc == sblock_try[i])) && sbp->fs_bsize <= MAXBSIZE && sbp->fs_bsize >= sizeof(struct fs)) break; } if (sblock_try[i] == -1) errx(1, "Cannot find file system superblock\n"); /* remaining arguments are inode numbers. */ while (*++argv) { /* get the inode number. */ if ((inonum = atoi(*argv)) <= 0) errx(1, "%s is not a valid inode number", *argv); (void)printf("%d:", inonum); /* read in the appropriate block. */ offset = ino_to_fsba(sbp, inonum); /* inode to fs blk */ offset = fsbtodb(sbp, offset); /* fs blk disk blk */ offset *= DEV_BSIZE; /* disk blk to bytes */ /* seek and read the block */ if (lseek(fd, offset, SEEK_SET) < 0) err(1, "%s", fsname); if (read(fd, ibuf, sbp->fs_bsize) != sbp->fs_bsize) err(1, "%s", fsname); /* get the inode within the block. */ if (sbp->fs_magic == FS_UFS1_MAGIC) { dp.dp1 = &((struct ufs1_dinode *)(ibuf)) [ino_to_fsbo(sbp, inonum)]; size = dp.dp1->di_size; } else { dp.dp2 = &((struct ufs2_dinode *)(ibuf)) [ino_to_fsbo(sbp, inonum)]; size = dp.dp2->di_size; } numblks = howmany(size, sbp->fs_bsize); if (numblks == 0) { printf(" empty file\n"); continue; } len = numblks < NDADDR ? numblks : NDADDR; for (i = 0; i < len; i++) { if (i < numblks - 1) frags = sbp->fs_frag; else frags = howmany(size % sbp->fs_bsize, sbp->fs_fsize); if (sbp->fs_magic == FS_UFS1_MAGIC) blkno = dp.dp1->di_db[i]; else blkno = dp.dp2->di_db[i]; printblk(i, blkno, frags, numblks); } blksperindir = 1; len = numblks - NDADDR; lbn = NDADDR; for (i = 0; len > 0 && i < NIADDR; i++) { if (sbp->fs_magic == FS_UFS1_MAGIC) blkno = dp.dp1->di_ib[i]; else blkno = dp.dp2->di_ib[i]; indirprt(blksperindir, lbn, blkno, numblks); blksperindir *= NINDIR(sbp); lbn += blksperindir; len -= blksperindir; } /* dummy print to hopefully flush out last extent */ printblk(numblks, 0, frags, numblks); } (void)close(fd); exit(0); } void indirprt(blksperindir, lbn, blkno, lastlbn) int blksperindir; int lbn; ufs2_daddr_t blkno; int lastlbn; { char indir[MAXBSIZE]; off_t offset; int i, last; /* read in the indirect block. */ offset = fsbtodb(sbp, blkno); /* fs blk disk blk */ offset *= DEV_BSIZE; /* disk blk to bytes */ if (lseek(fd, offset, SEEK_SET) < 0) err(1, "%s", fsname); if (read(fd, indir, sbp->fs_bsize) != sbp->fs_bsize) err(1, "%s", fsname); last = howmany(lastlbn - lbn, blksperindir) < NINDIR(sbp) ? howmany(lastlbn - lbn, blksperindir) : NINDIR(sbp); if (blksperindir == 1) { for (i = 0; i < last; i++) { if (sbp->fs_magic == FS_UFS1_MAGIC) blkno = ((ufs1_daddr_t *)indir)[i]; else blkno = ((ufs2_daddr_t *)indir)[i]; printblk(lbn + i, blkno, sbp->fs_frag, lastlbn); } return; } for (i = 0; i < last; i++) { if (sbp->fs_magic == FS_UFS1_MAGIC) blkno = ((ufs1_daddr_t *)indir)[i]; else blkno = ((ufs2_daddr_t *)indir)[i]; indirprt(blksperindir / NINDIR(sbp), lbn + blksperindir * i, blkno, lastlbn); } } void printblk(lbn, blkno, numblks, lastlbn) int lbn; ufs2_daddr_t blkno; int numblks; int lastlbn; { static int seq; static daddr_t firstblk; if (lbn == 0) { seq = 1; firstblk = blkno; return; } if (lbn < lastlbn && ((firstblk == 0 && blkno == 0) || (firstblk == BLK_NOCOPY && blkno == BLK_NOCOPY) || (firstblk == BLK_SNAP && blkno == BLK_SNAP) || blkno == firstblk + seq * numblks)) { seq++; return; } if (firstblk <= BLK_SNAP) { if (seq == 1) printf("\tlbn %d %s\n", lbn - seq, firstblk == 0 ? "hole" : firstblk == BLK_NOCOPY ? "nocopy" : "snapblk"); else printf("\tlbn %d-%d %s\n", lbn - seq, lbn - 1, firstblk == 0 ? "hole" : firstblk == BLK_NOCOPY ? "nocopy" : "snapblk"); seq = 1; firstblk = blkno; return; } if (seq == 1) { if (numblks == 1) printf("\tlbn %d blkno %jd\n", lbn - seq, (intmax_t)firstblk); else printf("\tlbn %d blkno %jd-%jd\n", lbn - seq, (intmax_t)firstblk, (intmax_t)(firstblk + numblks - 1)); firstblk = blkno; return; } printf("\tlbn %d-%d blkno %jd-%jd\n", lbn - seq, lbn - 1, (intmax_t)firstblk, (intmax_t)(firstblk + (seq - 1) * sbp->fs_frag + numblks - 1)); seq = 1; firstblk = blkno; } From owner-freebsd-fs@FreeBSD.ORG Wed Feb 1 06:26:49 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AA0C106566B; Wed, 1 Feb 2012 06:26:49 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (unknown [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id D915F8FC13; Wed, 1 Feb 2012 06:26:48 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id q116Qhvf060616; Tue, 31 Jan 2012 22:26:44 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201202010626.q116Qhvf060616@chez.mckusick.com> To: eugene@zhegan.in In-reply-to: <201201300540.q0U5eDYi068367@freefall.freebsd.org> Date: Tue, 31 Jan 2012 22:26:43 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: freebsd-fs@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/164472: [ufs] fsck -B panics on particular data inconsistency X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 06:26:49 -0000 > From: Kostik Belousov > To: bug-followup@FreeBSD.org, eugene@zhegan.in > Cc: > Subject: Re: kern/164472: [ufs] fsck -B panics on particular data inconsistency > Date: Mon, 30 Jan 2012 07:30:04 +0200 > > You failed to mention which panic you got. Was it 'dup alloc' ? A > backtace would be also useful. > > If it was indeed 'dup alloc', then there is nothing fsck or snapshots > can be accused for. Your filesystem is in inconsistent state, which > requires full fsck to recover. It must be not mounted while not > repaired. > > Somewhat more interesting is how the fs got into this state. Thanks for your report and in particular a small file image that demonstrates the problem. I have been able to reproduce your panic reliably on my test machine. Running a normal fsck on the image does indeed show that the filesystem has corruption that is unexpected on a filesystem running with soft updates. So, in the end, if the background fsck were able to run, it would fail and notify the system that it needed to be checked by a full fsck. But as you have aptly demonstrated, the background fsck crashes the system as it tries to take a snapshot of the filesystem on which to run its check. The cause of the crash is because in taking a snapshot, the filesystem needs to allocate an inode for the snapshot. As it turns out, the inode that it tries to allocate is marked free in the inode map, but is in fact already allocated which leads to the panic. I am still mulling over how to resolve this problem, but have not yet come up with one. I am looking for a solution that effectively will let the snapshot fail rather than crashing the system so that the fsck -B can then gracefully fail and lead to the full fsck as is needed in this case. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Wed Feb 1 06:30:21 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C6971065673 for ; Wed, 1 Feb 2012 06:30:21 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F0AC68FC19 for ; Wed, 1 Feb 2012 06:30:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q116UKm4043577 for ; Wed, 1 Feb 2012 06:30:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q116UKZC043576; Wed, 1 Feb 2012 06:30:20 GMT (envelope-from gnats) Date: Wed, 1 Feb 2012 06:30:20 GMT Message-Id: <201202010630.q116UKZC043576@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Kirk McKusick Cc: Subject: Re: kern/164472: [ufs] fsck -B panics on particular data inconsistency X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kirk McKusick List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 06:30:21 -0000 The following reply was made to PR kern/164472; it has been noted by GNATS. From: Kirk McKusick To: eugene@zhegan.in Cc: bug-followup@FreeBSD.org, freebsd-fs@FreeBSD.org, Kostik Belousov Subject: Re: kern/164472: [ufs] fsck -B panics on particular data inconsistency Date: Tue, 31 Jan 2012 22:26:43 -0800 > From: Kostik Belousov > To: bug-followup@FreeBSD.org, eugene@zhegan.in > Cc: > Subject: Re: kern/164472: [ufs] fsck -B panics on particular data inconsistency > Date: Mon, 30 Jan 2012 07:30:04 +0200 > > You failed to mention which panic you got. Was it 'dup alloc' ? A > backtace would be also useful. > > If it was indeed 'dup alloc', then there is nothing fsck or snapshots > can be accused for. Your filesystem is in inconsistent state, which > requires full fsck to recover. It must be not mounted while not > repaired. > > Somewhat more interesting is how the fs got into this state. Thanks for your report and in particular a small file image that demonstrates the problem. I have been able to reproduce your panic reliably on my test machine. Running a normal fsck on the image does indeed show that the filesystem has corruption that is unexpected on a filesystem running with soft updates. So, in the end, if the background fsck were able to run, it would fail and notify the system that it needed to be checked by a full fsck. But as you have aptly demonstrated, the background fsck crashes the system as it tries to take a snapshot of the filesystem on which to run its check. The cause of the crash is because in taking a snapshot, the filesystem needs to allocate an inode for the snapshot. As it turns out, the inode that it tries to allocate is marked free in the inode map, but is in fact already allocated which leads to the panic. I am still mulling over how to resolve this problem, but have not yet come up with one. I am looking for a solution that effectively will let the snapshot fail rather than crashing the system so that the fsck -B can then gracefully fail and lead to the full fsck as is needed in this case. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Thu Feb 2 02:10:08 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 699AE106564A for ; Thu, 2 Feb 2012 02:10:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 551EE8FC15 for ; Thu, 2 Feb 2012 02:10:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q122A8N4065844 for ; Thu, 2 Feb 2012 02:10:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q122A8QF065843; Thu, 2 Feb 2012 02:10:08 GMT (envelope-from gnats) Date: Thu, 2 Feb 2012 02:10:08 GMT Message-Id: <201202020210.q122A8QF065843@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Scot Hetzel Cc: Subject: Re: amd64/164516: unable to mount EXT2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Scot Hetzel List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 02:10:08 -0000 The following reply was made to PR kern/164516; it has been noted by GNATS. From: Scot Hetzel To: vermaden Cc: freebsd-gnats-submit@freebsd.org Subject: Re: amd64/164516: unable to mount EXT2 filesystem Date: Wed, 1 Feb 2012 19:33:51 -0600 On Thu, Jan 26, 2012 at 9:22 AM, vermaden wrote: > # mount -t ext2 /dev/md0 /mnt/tmp0 > mount: /dev/md0 : Operation not supported by device > The reason you can't mount the ext2fs is that you are using the wrong filesystem type, according to the ext2fs man page you should be using: mount -t ext2fs /dev/md0 /mnt/tmp0 ext2fs(5) - http://www.freebsd.org/cgi/man.cgi?query=ext2fs&sektion=5&apropos=0&manpath=FreeBSD+9.0-RELEASE Scot From owner-freebsd-fs@FreeBSD.ORG Thu Feb 2 10:40:07 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D02D61065670 for ; Thu, 2 Feb 2012 10:40:07 +0000 (UTC) (envelope-from kykypyky2@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 9A75F8FC12 for ; Thu, 2 Feb 2012 10:40:07 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Rsu5G-0000ex-F9 for freebsd-fs@freebsd.org; Thu, 02 Feb 2012 02:40:06 -0800 Date: Thu, 2 Feb 2012 02:40:06 -0800 (PST) From: Shelm To: freebsd-fs@freebsd.org Message-ID: <1328179206463-5450286.post@n5.nabble.com> In-Reply-To: <1328004542281-5444145.post@n5.nabble.com> References: <1328001527003-5444043.post@n5.nabble.com> <20120131095525.GA67112@icarus.home.lan> <1328004542281-5444145.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Hast Unable to listen on address X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 10:40:07 -0000 why the same value on two servers kern.hostuuid -- View this message in context: http://freebsd.1045724.n5.nabble.com/Hast-Unable-to-listen-on-address-tp5444043p5450286.html Sent from the freebsd-fs mailing list archive at Nabble.com. From owner-freebsd-fs@FreeBSD.ORG Thu Feb 2 11:24:46 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEA7D106566B for ; Thu, 2 Feb 2012 11:24:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id 9AC668FC17 for ; Thu, 2 Feb 2012 11:24:46 +0000 (UTC) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta14.westchester.pa.mail.comcast.net with comcast id UzJU1i0010vyq2s5EzQmGt; Thu, 02 Feb 2012 11:24:46 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta05.westchester.pa.mail.comcast.net with comcast id UzQm1i0011t3BNj3RzQm4C; Thu, 02 Feb 2012 11:24:46 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7ED80102C1E; Thu, 2 Feb 2012 03:24:44 -0800 (PST) Date: Thu, 2 Feb 2012 03:24:44 -0800 From: Jeremy Chadwick To: Shelm Message-ID: <20120202112444.GA16854@icarus.home.lan> References: <1328001527003-5444043.post@n5.nabble.com> <20120131095525.GA67112@icarus.home.lan> <1328004542281-5444145.post@n5.nabble.com> <1328179206463-5450286.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1328179206463-5450286.post@n5.nabble.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Hast Unable to listen on address X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 11:24:46 -0000 On Thu, Feb 02, 2012 at 02:40:06AM -0800, Shelm wrote: > why the same value on two servers kern.hostuuid Please read the code in /etc/rc.d/hostid to understand. You will also need to look at /etc/defaults/rc.conf to know what $hostid_file is. kern.hostuuid and kern.hostid are generated on-the-fly when the system does not have /etc/hostid. You can reset this simply by removing the file and rebooting, or by running "/etc/rc.d/hostid reset". I do not believe a reboot will be needed after doing the latter, but you will almost certainly have to restart daemons. If you read the above script it should (mostly) make sense. Likely root cause: When you made these two systems, you probably mistakingly copied /etc/hostid from one to the other (or you copied /etc from one to the other). Administrator error. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Fri Feb 3 04:21:33 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EA19106566B for ; Fri, 3 Feb 2012 04:21:33 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 1DA178FC08 for ; Fri, 3 Feb 2012 04:21:32 +0000 (UTC) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q132Gr2t018049 for ; Fri, 3 Feb 2012 13:16:53 +1100 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q132Goje007152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Feb 2012 13:16:51 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q132GngV028162 for ; Fri, 3 Feb 2012 13:16:49 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id q132Gnix028161 for freebsd-fs@freebsd.org; Fri, 3 Feb 2012 13:16:49 +1100 (EST) (envelope-from peter) Date: Fri, 3 Feb 2012 13:16:49 +1100 From: Peter Jeremy To: freebsd-fs@freebsd.org Message-ID: <20120203021649.GA87521@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cmJC7u66zC7hs+87" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Subject: ZFS boot problems revisited X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 04:21:33 -0000 --cmJC7u66zC7hs+87 Content-Type: multipart/mixed; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I recently ran into the dreaded "all blocks unavailable" error whilst upgrading to a recent 8-stable with a 3-way mirrored ZFS root. Installing the latest gptzfsboot helped a bit but still reported errors and the boot failed. I was under the impression that the latest boot code had resolved all the problems but it seems there are still some cases it can't cope with. Comparing the code I built with the latest head shows no relevant differences (disabling SSE3 & FP and changing a constant used for RAIDZ parity calculations). Are there any known cases that the boot code still doesn't handle? The failures led me to investigate zfsboottest & zfsboottest.sh. Unfortunately, these tools still have some problems:=20 1) zfsboottest is still built as native dynamic executable. I'm not sure if being dynamic presents a problem (I would hope it didn't) but it should be an i386 executable on amd64. The attached patch changes it to be a static i386 executable. 2) vfs.root.mountfrom is documented (in sys/kern/vfs_mountroot.c in 9.x and later or sys/kern/vfs_mount.c in 8.x and earlier) to take a space-separated list of :[]. zfsboottest.sh expects it to be a bare zpool name. The attached patch adds the "zfs:" prefix but still limits it to a single item. 3) The "you may not be able to boot" message will never appear because it's testing the result of the preceeding "rm -f", rather than the diff (as wanted). The attached patch fixes this. I'm still not confident that the flags used to build zfsboottest are equivalent to those used to build gptzfsboot but will leave that for later investigation. The attached patches are relative to 8-stable CVS but there are no differences to head. --=20 Peter Jeremy --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="zfsboottest.diff" Content-Transfer-Encoding: quoted-printable Index: Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/ncvs/src/tools/tools/zfsboottest/Makefile,v retrieving revision 1.3.2.2 diff -u -r1.3.2.2 Makefile --- Makefile 7 Jan 2012 02:35:00 -0000 1.3.2.2 +++ Makefile 3 Feb 2012 00:18:44 -0000 @@ -17,11 +17,14 @@ -fdiagnostics-show-option \ -W -Wextra -Wno-sign-compare -Wno-unused-parameter \ -Werror -LDFLAGS+=3D-lmd +LDFLAGS+=3D-static +LDADD=3D-lmd =20 .if ${MACHINE_ARCH} =3D=3D "amd64" beforedepend zfsboottest.o: machine CLEANFILES+=3D machine +CFLAGS+=3D-m32 +LDFLAGS+=3D-m32 machine: ln -sf ${.CURDIR}/../../../sys/i386/include machine .endif Index: zfsboottest.sh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/ncvs/src/tools/tools/zfsboottest/zfsboottest.sh,v retrieving revision 1.1.6.2 diff -u -r1.1.6.2 zfsboottest.sh --- zfsboottest.sh 7 Jan 2012 02:35:00 -0000 1.1.6.2 +++ zfsboottest.sh 3 Feb 2012 00:20:03 -0000 @@ -73,7 +73,7 @@ # or vfs.root.mountfrom variable set in /boot/loader.conf. egrep -q '^'"${bootfs}"'[[:space:]]+/[[:space:]]+zfs[[:space:]]+' "${mount= point}/etc/fstab" 2>/dev/null if [ $? -ne 0 ]; then - egrep -q 'vfs.root.mountfrom=3D"?'"${bootfs}"'"?[[:space:]]*$' "${mountpo= int}/boot/loader.conf" 2>/dev/null + egrep -q 'vfs.root.mountfrom=3D"?zfs:'"${bootfs}"'"?[[:space:]]*$' "${mou= ntpoint}/boot/loader.conf" 2>/dev/null if [ $? -ne 0 ]; then echo "To be able to boot from \"${bootfs}\", you need to declare" >&2 echo "\"${bootfs}\" as being root file system in ${mountpoint}/etc/fstab= " >&2 @@ -121,7 +121,7 @@ =20 rm -f "${list0}" "${list1}" =20 -if [ $? -ne 0 ]; then +if [ $ec -ne 0 ]; then echo >&2 echo "You may not be able to boot." >&2 exit 1 --HlL+5n6rz5pIUxbD-- --cmJC7u66zC7hs+87 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8rQ5EACgkQ/opHv/APuIe2YwCeOMx9wOZh0QAtHopT6AZ97Ekr H2MAnR9WwGvyS3g9BYXWEkKn/fE/qhM3 =N+1v -----END PGP SIGNATURE----- --cmJC7u66zC7hs+87-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 3 13:09:15 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 449F11065670; Fri, 3 Feb 2012 13:09:15 +0000 (UTC) (envelope-from antonio.trindade@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 689848FC08; Fri, 3 Feb 2012 13:09:13 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so3893513wgb.31 for ; Fri, 03 Feb 2012 05:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:disposition-notification-to:from :in-reply-to:date:message-id:references:to:x-mailer:x-virus-scanned; bh=jg3WT95Yy3MO1T+52Lrr4ugbN8EqwkQcqenjoAHO3O0=; b=gvGjR8qfL0EZAef5+EPDOh1wdZR3wTP3AFeB25AdznQLRmrkkpWbFi78kOOy0uWFao 4iu654CTCX2EmUolbAuh37Wwyv/FHxR7JuxRwgpcQoS4gaVUhuoWpiqrPeIxqWmM+q0X wwspzNvrkfoCZNqkCZG3HY4kLyR/hmE52HpxE= Received: by 10.180.81.35 with SMTP id w3mr11372749wix.10.1328274553214; Fri, 03 Feb 2012 05:09:13 -0800 (PST) Received: from gatekeeper.darklair.homeunix.net (a89-153-149-64.cpe.netcabo.pt. [89.153.149.64]) by mx.google.com with ESMTPS id l8sm17248697wiy.5.2012.02.03.05.09.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Feb 2012 05:09:12 -0800 (PST) Received: from gatekeeper.darklair.homeunix.net (localhost [127.0.0.1]) by gatekeeper.darklair.homeunix.net (Postfix) with ESMTP id D1B54CF06A; Fri, 3 Feb 2012 13:09:09 +0000 (WET) Received: from altair-wifi.darklair.homeunix.net (altair-wifi.darklair.homeunix.net [10.0.0.11]) by gatekeeper.darklair.homeunix.net (Postfix) with ESMTPA id 739BBCF069; Fri, 3 Feb 2012 13:09:09 +0000 (WET) Mime-Version: 1.0 (Apple Message framework v1084) From: "=?iso-8859-1?Q?Ant=F3nio_Trindade?=" In-Reply-To: Date: Fri, 3 Feb 2012 13:09:08 +0000 Message-Id: <32F9152B-5B6A-400A-9353-A050C89A336E@gmail.com> References: <315A1E95-9064-494F-A3B8-48F1C4951624@gmail.com> To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org, freebsd-bugs@freebsd.org X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: ClamAV using ClamSMTP Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: kernel: panic: softdep_sync_buf: Unknown type jnewblk X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 13:09:15 -0000 Hi! After a few days, I finally got a kernel panic like the one I reported = earlier. I attach the file info.0. I'm not attaching the vmcore.0 and core.txt.0 = files, because they are over 100MB in size. If needed, they can be = downloaded from http://trindade.myphotos.cc/crash/vmcore.0.gz and = http://trindade.myphotos.cc/crash/core.txt.0. I remind you that I am not using snapshots, at least conscientiously. Hope this helps diagnosing the problem. Meanwhile I deactivated SU+J again and reverted back to plain old SU. Best regards. ------ BEGIN info.0 ------ Dump header from device /dev/ad0s1b Architecture: i386 Architecture Version: 2 Dump Length: 193622016B (184 MB) Blocksize: 512 Dumptime: Thu Feb 2 22:57:19 2012 Hostname: gatekeeper.darklair.homeunix.net Magic: FreeBSD Kernel Dump Version String: FreeBSD 9.0-RELEASE #0: Sun Jan 15 01:22:14 WET 2012 = root@gatekeeper.darklair.homeunix.net:/usr/obj/usr/src/sys/GATEKEEPER Panic String: softdep_sync_buf: Unknown type jnewblk Dump Parity: 3424763946 Bounds: 0 Dump Status: good ------ END info.0 ------ Ant=F3nio Trindade Antonio Trindade gmail.com S=EDtios pessoais: Galeria Fotogr=E1fica: http://trindade.myphotos.cc/fotos/ Blog de fotografia: http://trindade.myphotos.cc/fotografia/ Blog de not=EDcias: http://trindade.myphotos.cc/noticiasavulsas/ Blog pessoal: http://trindade.myphotos.cc/pensamentosnoar/ On 2012/01/27, at 01:03, Ant=F3nio Trindade wrote: > I'm sorry for so many mails... >=20 > Please cc me about this, because I'm not on any of the FreeBSD mailing = lists... >=20 > Thanks in advance. >=20 > Cumprimentos/Best regards/Mit freundlichen Gr=FC=DFen, > Ant=F3nio Trindade > Antonio Trindade gmail.com >=20 > S=EDtios pessoais: > Galeria Fotogr=E1fica: http://trindade.myphotos.cc/fotos/ > Blog de fotografia: http://trindade.myphotos.cc/fotografia/ > Blog de not=EDcias: http://trindade.myphotos.cc/noticiasavulsas/ > Blog pessoal: http://trindade.myphotos.cc/pensamentosnoar/ >=20 > On 2012/01/27, at 00:44, Ant=F3nio Trindade wrote: >=20 >>=20 >>> From: Ant=F3nio Trindade >>> Date: 27 de Janeiro de 2012 00:40:06 WET >>> To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org, = freebsd-bugs@freebsd.org >>> Subject: kernel: panic: softdep_sync_buf: Unknown type jnewblk >>>=20 >>> Cheers. >>>=20 >>> I recently updated my system to FreeBSD-9.0 and activated softupdate = journaling for a number of file systems (name /home, /var, /usr). >>>=20 >>> Since then I have been experiencing kernel panics: >>> kernel: panic: softdep_sync_buf: Unknown type jnewblk >>>=20 >>> Yesterday, Jan 26th, I got 6 (six) automatic reboots due to these = kernel panics. >>>=20 >>> I have now disabled softupdates journaling in the hope that the = panics disappear. >>>=20 >>> I am sorry for not providing more information about the panic, but = I'll gladly try to gather more info if instructed how to. >>>=20 >>> Cumprimentos/Best regards/Mit freundlichen Gr=FC=DFen, >>> Ant=F3nio Trindade >>> Antonio Trindade gmail.com >>>=20 >>> S=EDtios pessoais: >>> Galeria Fotogr=E1fica: http://trindade.myphotos.cc/fotos/ >>> Blog de fotografia: http://trindade.myphotos.cc/fotografia/ >>> Blog de not=EDcias: http://trindade.myphotos.cc/noticiasavulsas/ >>> Blog pessoal: http://trindade.myphotos.cc/pensamentosnoar/ >>>=20 >>=20 >> I forgot some additional info: >> To deactivate softupdates journaling, I rebooted into single-user = mode and ran full fsck to every file system I had activated journaling = for. >> To my surprise, fsck reported errors (namely wrong block counts and = bitmap errors, nothing serious). >>=20 >> Cumprimentos/Best regards/Mit freundlichen Gr=FC=DFen, >> Ant=F3nio Trindade >> Antonio Trindade gmail.com >>=20 >> S=EDtios pessoais: >> Galeria Fotogr=E1fica: http://trindade.myphotos.cc/fotos/ >> Blog de fotografia: http://trindade.myphotos.cc/fotografia/ >> Blog de not=EDcias: http://trindade.myphotos.cc/noticiasavulsas/ >> Blog pessoal: http://trindade.myphotos.cc/pensamentosnoar/ >>=20 >=20 From owner-freebsd-fs@FreeBSD.ORG Fri Feb 3 13:46:37 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C33C106566C for ; Fri, 3 Feb 2012 13:46:37 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id 056018FC13 for ; Fri, 3 Feb 2012 13:46:36 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0McRqW-1SAqM744YK-00I6ne; Fri, 03 Feb 2012 14:46:36 +0100 Message-ID: <4F2BE53A.2030301@brockmann-consult.de> Date: Fri, 03 Feb 2012 14:46:34 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20120203021649.GA87521@server.vk2pj.dyndns.org> In-Reply-To: <20120203021649.GA87521@server.vk2pj.dyndns.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:2hl+oHtqEQW+8E8MgYOe+6o8Asr9cP2qSsKwuhyRHHG PiwMQH0yCXcNg+N1nbCA6kdROeoqq0bYfYySSESec5iRRZwUg3 Ak7Oo+QDHtYdRPMgRJbQeSRnnBRIyL5hSrvxNXykmlZwwS1mOh q07X4ovyBUB//sdie0gqV6PGDf8dNZA0Dpp3NXE7PCzPOaoer6 MbFAqPDC0EIyXsVJSLNJ4uvOnJm6xoamiaQJM3evVq323dGPfC XOKSp95LtOOomfKJw/OsyIHY6f8WjZAhGwK6Estaez504mFEI5 iP4AZxmmDP7jOtFnEKkL0p3BotqZjZ0o7aVknDmu9IMHwn/Tsp 20BMMtjPMUe42Xv8y1+Pg7mpfBLcdyUM4IWl8NAUR Subject: Re: ZFS boot problems revisited X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 13:46:37 -0000 The causes of some zfs boot failures are unknown. I don't know why it does it. I updated 2 nearly identical systems to 8-STABLE from 8.2-RELEASE and (if I remember correctly) got the same error as you on one but not the other. I have only tried 2 way mirrors so far, so I might not know much about this specific issue, but what comes to mind is what I would call the 'standard zfs boot fix', which I first found here: http://freebsd.1045724.n5.nabble.com/Difficulties-to-use-ZFS-root-ROOT-MOUNT-ERROR-td4771828.html It basically goes like this: Boot off of something with zfs support (eg. a DVD). Then run these commands (assuming here your root is named "zroot"). zpool import -o altroot=/z -o cachefile=/tmp/zpool.cache zroot zfs set mountpoint=/ zroot cp /tmp/zpool.cache /z/boot/zfs/zpool.cache shutdown -r now The "mountpoint=/" part is required. And then optionally, you would set it back to "legacy" before the reboot if that is the way you do things. I do not prefer "mountpoint=legacy", which most people seem to have and seems to be in all the howtos, because then if something goes wrong, altroot will work without unmounting /usr, /var, etc. first and remounting it all after / is mounted. (which affects things like chroot, but not simply editing conf if it is in the same dataset). And do not export the pool, or forget/skip the cache file part, or you get the same error that you started with. And if you messed up your config somehow (maybe with mergemaster), you should edit it before the reboot... better double check. /etc/rc.conf: =========== zfs_enable="YES" /boot/loader.conf =========== zfs_load="YES" vfs.root.mountfrom="zfs:zroot" #depending on your install and hardware, maybe you want to load mps (8.2-RELEASE). With 8-STABLE you probably don't need this. I wouldn't just assume the new GENERIC kernel of one version loads the same drivers as your old GENERIC kernel. mps_load="YES" On 02/03/2012 03:16 AM, Peter Jeremy wrote: > I recently ran into the dreaded "all blocks unavailable" error whilst > upgrading to a recent 8-stable with a 3-way mirrored ZFS root. > Installing the latest gptzfsboot helped a bit but still reported > errors and the boot failed. I was under the impression that the > latest boot code had resolved all the problems but it seems there are > still some cases it can't cope with. Comparing the code I built with > the latest head shows no relevant differences (disabling SSE3 & FP and > changing a constant used for RAIDZ parity calculations). > > Are there any known cases that the boot code still doesn't handle? > > The failures led me to investigate zfsboottest & zfsboottest.sh. > Unfortunately, these tools still have some problems: > 1) zfsboottest is still built as native dynamic executable. I'm not > sure if being dynamic presents a problem (I would hope it didn't) > but it should be an i386 executable on amd64. The attached patch > changes it to be a static i386 executable. > 2) vfs.root.mountfrom is documented (in sys/kern/vfs_mountroot.c in > 9.x and later or sys/kern/vfs_mount.c in 8.x and earlier) to take a > space-separated list of :[]. zfsboottest.sh expects > it to be a bare zpool name. The attached patch adds the "zfs:" > prefix but still limits it to a single item. > 3) The "you may not be able to boot" message will never appear because > it's testing the result of the preceeding "rm -f", rather than the > diff (as wanted). The attached patch fixes this. > > I'm still not confident that the flags used to build zfsboottest are > equivalent to those used to build gptzfsboot but will leave that for > later investigation. > > The attached patches are relative to 8-stable CVS but there are no > differences to head. > -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Sat Feb 4 03:50:10 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73C791065678 for ; Sat, 4 Feb 2012 03:50:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3CA4C8FC0C for ; Sat, 4 Feb 2012 03:50:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q143oA6Z086986 for ; Sat, 4 Feb 2012 03:50:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q143oAw4086985; Sat, 4 Feb 2012 03:50:10 GMT (envelope-from gnats) Date: Sat, 4 Feb 2012 03:50:10 GMT Message-Id: <201202040350.q143oAw4086985@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Yar Tikhiy Cc: Subject: Re: bin/145309: bsdlabel: Editing disk label invalidates the whole device X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yar Tikhiy List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 03:50:10 -0000 The following reply was made to PR bin/145309; it has been noted by GNATS. From: Yar Tikhiy To: bug-followup@freebsd.org Cc: Subject: Re: bin/145309: bsdlabel: Editing disk label invalidates the whole device Date: Sat, 4 Feb 2012 14:17:15 +1100 Hi there, Sorry but FreeBSD 9.0-RELEASE still appears to have this issue. When installed using BSD label partitioning scheme, a modification to ada0's label seems to nuke the kernel's view of the disk -- I can't think of a better way to explain it. The disk itself is OK and the change makes it OK to the disk but the kernel can no more use the root partition until rebooted, returning weird errnos such as EIO or EXIO. No idea here if the bug is limited to BSD label scheme. Cheers, Yar