From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 01:13: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 1D117106564A; Sun, 15 Apr 2012 01:13:37 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id D455F8FC08; Sun, 15 Apr 2012 01:13:36 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id q3F11L4K005374; Sat, 14 Apr 2012 20:01:21 -0500 (CDT) Date: Sat, 14 Apr 2012 20:01:20 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Andriy Gapon In-Reply-To: <4F89B567.6090008@FreeBSD.org> Message-ID: References: <4F8999D2.1080902@FreeBSD.org> <4F89B567.6090008@FreeBSD.org> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Sat, 14 Apr 2012 20:01:21 -0500 (CDT) Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 01:13:37 -0000 It would be nice if the updated FreeBSD bootloader could have the ability to boot both Solaris and FreeBSD root filesystems in the same pool so that one could switch between several zfs-based operating systems without needing to use a different partition for each one. Is this within the bounds of possibility or a totally irrational thought? Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 02:30:45 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 DFECC106566C; Sun, 15 Apr 2012 02:30:45 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 844C38FC12; Sun, 15 Apr 2012 02:30:45 +0000 (UTC) Received: by obqv19 with SMTP id v19so4687044obq.13 for ; Sat, 14 Apr 2012 19:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Iy+G+ukDFLj2TWtAHDVFNQCw3/WAA7ILCbHzudkXajM=; b=uC9+iNah8xhUuBO+Kex6SLx7YOGnKiTntAF+kHYnuC5WXc8XdB1uu2Y7BORGebukXY VyE5rdeV8nVDsDKrDGSUyOwjIEPvNWzojhsoG9PU3SYpAFuxQV1jh1I9EyXYMaqwd6TG ldmgFs4TAD53ROBsaTP+zgv6+vX0EuNpIammdT6NkLdOLnM8D8iV616Mhe1QCbKCzoh4 YTSPk3+N2g2Qy/ORDI/2UVnJu4wbztvWVodOAk2AKSp+F3hfgIYm7t1EZ9vPG6rLCx+Z HlJc1mb0PYs+/EJZ8/l7uAnPfSm2GgCaXcZH5RzyTUUiLo40Mmho09SLlYUsaC/WxU0Q a11A== Received: by 10.60.28.137 with SMTP id b9mr9422981oeh.57.1334457044996; Sat, 14 Apr 2012 19:30:44 -0700 (PDT) Received: from [192.168.2.5] (dpc691939029.direcpc.com. [69.19.39.29]) by mx.google.com with ESMTPS id w4sm12227222oeg.12.2012.04.14.19.30.33 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Apr 2012 19:30:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: Date: Sat, 14 Apr 2012 19:30:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F8999D2.1080902@FreeBSD.org> <4F89B567.6090008@FreeBSD.org> To: Bob Friesenhahn X-Mailer: Apple Mail (2.1257) Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Andriy Gapon Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 02:30:46 -0000 On Apr 14, 2012, at 6:01 PM, Bob Friesenhahn wrote: > It would be nice if the updated FreeBSD bootloader could have the = ability to boot both Solaris and FreeBSD root filesystems in the same = pool so that one could switch between several zfs-based operating = systems without needing to use a different partition for each one. Is = this within the bounds of possibility or a totally irrational thought? This sort of depends on whether or not the device is hardcoded = in the zpool, right? Thanks! -Garrett= From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 07:36:03 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7B5B106564A for ; Sun, 15 Apr 2012 07:36:03 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7FEF28FC0C for ; Sun, 15 Apr 2012 07:36:03 +0000 (UTC) Received: by vcmm1 with SMTP id m1so3949243vcm.13 for ; Sun, 15 Apr 2012 00:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mRh4M/YUoNzhGWFIGly5q2VRlTiHeJ8tVMF8d6NAj5k=; b=sX95k2DaOSUevXCuXxPgePMjdBRe7Ft8pEIXnTum/EdGtLXB7UbGkQWljM2gg2+arc M9Pjgxyj+Ae/zoYNJ7wtwV1abElTgVc8C3gd5QYpY64/CUgMisoYUorLQT+ttxrqhEmT vzv07prNYUh/hD1uQUmaV0XkJozMqzQqdrnjWYvCwkvXyJpWudo95eqtKJmi1SXhvJZW pDuxq/4/Wis5HkNr4D7w8HIVQlUEfJ3FwKiRSOW9KTX5jHA3nPNaTba0BAUQvncg0LXt YwOiOhSmyA04Zj1VlCpq7LE3LPdOhmM5iVI3Frs/JW7kjC5sD5H4ZR1ol/2JNCwgZAFk QYuw== MIME-Version: 1.0 Received: by 10.52.65.170 with SMTP id y10mr3090041vds.48.1334475357375; Sun, 15 Apr 2012 00:35:57 -0700 (PDT) Received: by 10.52.95.2 with HTTP; Sun, 15 Apr 2012 00:35:57 -0700 (PDT) Date: Sun, 15 Apr 2012 15:35:57 +0800 Message-ID: From: dave jones To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: A question about msdosfs code 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, 15 Apr 2012 07:36:03 -0000 Hello, I have a question about the MSDOSFSROOT_OFS definition in denode.h: /* * Internal pseudo-offset for (nonexistent) directory entry for the root * dir in the root dir */ #define MSDOSFSROOT_OFS 0x1fffffff I'm wondering why setting the root directory offset is 0x1fffffff? Is there any formula to calculate root dir offset instead? Thank you. Regards, Dave. From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 09:23: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 43130106564A; Sun, 15 Apr 2012 09:23:28 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id F15198FC08; Sun, 15 Apr 2012 09:23:27 +0000 (UTC) From: vermaden To: freebsd-questions@freebsd.org, freebsd-fs@freebsd.org X-Mailer: interia.pl/pf09 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1334481800; bh=0KJ0MMFUYJKL4UFksA7EgZy/p2kNRowFKpEMFOX6org=; h=From:Subject:To:X-Mailer:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=oqtTzEK5v3YD+awm/dsDbTBB4+ezkmwTBIjX6wxsckaRbq5hdQcgc+nu1HKsmetUS szwX6F2ywVTd7tYIfxwChpCyfh0GUZU59vytUB51M1bwG+NB+K+Zay92c3syN/p8jk xQUaqcn8vEXxu1rDrpoSshymtezFQ5C8ZCffL+nk= Date: Sun, 15 Apr 2012 09:23:28 +0000 (UTC) Cc: Subject: Mounting from zfs:system/ROOT/nch failed with error 2 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, 15 Apr 2012 09:23:28 -0000 Hi, I have a system that successfully booted from system/ROOT/default, but now failed with system/ROOT/nch (other ROOT installation), it ends with ERROR 2, what does ERROR 2 means? Its 9.0-RELEASE. Reagads and thanks in advance, vermaden ... From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 09:30:55 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0BC1F106564A; Sun, 15 Apr 2012 09:30:55 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id B8C808FC22; Sun, 15 Apr 2012 09:30:54 +0000 (UTC) From: vermaden To: freebsd-questions@freebsd.org, freebsd-fs@freebsd.org X-Mailer: interia.pl/pf09 In-Reply-To: References: Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1334482253; bh=txoLZq5VcDyRpjbqFpaJyXNi09IKnhqp5gzJRkZzV00=; h=From:Subject:To:X-Mailer:In-Reply-To:References:Message-Id: MIME-Version:Content-Type:Content-Transfer-Encoding; b=S41gcS4y5WyrkjWZXSQKCPK5zAol6NFTt22kU7tuYJ/8qOmJkkL92J+H0hW+4JKwJ CWWu2IxqFGhGHLiJf7xridu0miqXVVm30VvT3PbbQZpM5fBSCQge5K2KJIMXlZnswf /RpmlHzA2gmio3MV2gyy6I34YNfW1hD0nOmAitqE= Date: Sun, 15 Apr 2012 09:30:55 +0000 (UTC) Cc: Subject: Re: Mounting from zfs:system/ROOT/nch failed with error 2 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, 15 Apr 2012 09:30:55 -0000 I forgot to attach the screenshot from KVM ... http://ompldr.org/vZGRxeg Regards, vermaden "vermaden" pisze: > Hi, >=20 > I have a system that successfully booted from system/ROOT/default, > but now failed with system/ROOT/nch (other ROOT installation), > it ends with ERROR 2, what does ERROR 2 means? >=20 > Its 9.0-RELEASE. >=20 > Reagads and thanks in advance, > vermaden ... From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 09:47:26 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 967C8106564A; Sun, 15 Apr 2012 09:47:26 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 0228A8FC12; Sun, 15 Apr 2012 09:47:25 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q3F9lDN0094566 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 15 Apr 2012 10:47:14 +0100 (BST) (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.5.1 smtp.infracaninophile.co.uk q3F9lDN0094566 Authentication-Results: smtp.infracaninophile.co.uk/q3F9lDN0094566; dkim=none (no signature); dkim-adsp=none Message-ID: <4F8A9918.3080607@FreeBSD.org> Date: Sun, 15 Apr 2012 10:47:04 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: vermaden References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig393D1E3D078FD7A5220F1A69" X-Virus-Scanned: clamav-milter 0.97.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-fs@FreeBSD.org, freebsd-questions@FreeBSD.org Subject: Re: Mounting from zfs:system/ROOT/nch failed with error 2 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, 15 Apr 2012 09:47:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig393D1E3D078FD7A5220F1A69 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15/04/2012 10:23, vermaden wrote: > I have a system that successfully booted from system/ROOT/default, > but now failed with system/ROOT/nch (other ROOT installation), > it ends with ERROR 2, what does ERROR 2 means? Setting up for use with boot environments? Can you describe how you did this, or at least point us towards a recipe you followed? > Its 9.0-RELEASE. Good. However, not particularly pertinent to the problem at hand. If we are to help you work out what went wrong, we will need a tad more information than you have supplied. Primarily at what point in the boot sequence did it go wrong? Before the BSD Logo menu screen? During the kernel initialization (ie. while it was printing bright white text) or after (grey coloured text)? Were there any other error messages printed on the console? Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enig393D1E3D078FD7A5220F1A69 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+KmSEACgkQ8Mjk52CukIx5bgCgjabY7dg2gl0hN2x/+HaBH4Z7 TRMAn2k86GnIkLzVLksuJW9Nq1lfIAyX =1VfG -----END PGP SIGNATURE----- --------------enig393D1E3D078FD7A5220F1A69-- From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 11:08:08 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 04F8C106566C; Sun, 15 Apr 2012 11:08:08 +0000 (UTC) Date: Sun, 15 Apr 2012 11:08:08 +0000 From: Alexander Best To: freebsd-fs@freebsd.org Message-ID: <20120415110807.GA75306@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline Subject: fixing a hackish comment in ata-raid.c 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, 15 Apr 2012 11:08:08 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi there, clang complains about this rather ugly way of putting a comment into normal code: if ((vdcr == NULL) /* && (sa == NULL) * Spares not supported yet */) { could somebody please commit the following (or a similar) patch? thanks in advance. alex --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ata-raid.c.patch" diff --git a/sys/dev/ata/ata-raid.c b/sys/dev/ata/ata-raid.c index c96e252..f7215d3 100644 --- a/sys/dev/ata/ata-raid.c +++ b/sys/dev/ata/ata-raid.c @@ -1892,7 +1892,12 @@ ata_raid_ddf_read_meta(device_t dev, struct ar_softc **raidp) } } cr_found: - if ((vdcr == NULL) /* && (sa == NULL) * Spares not supported yet */) { + /* Spares are not supported yet. + * Once support is implemented the condition below should be: + * + * if ((vdcr == NULL) && (sa == NULL)) { + */ + if (vdcr == NULL) { device_printf(parent, "No usable configuration record found\n"); goto ddf_out; } --Dxnq1zWXvFF0Q93v-- From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 11:14:30 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 A625F1065672 for ; Sun, 15 Apr 2012 11:14:30 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 2C7568FC0C for ; Sun, 15 Apr 2012 11:14:30 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SJNPX-0007SG-Q6 for freebsd-fs@freebsd.org; Sun, 15 Apr 2012 13:14:28 +0200 Received: from dhcp-077-251-052-224.chello.nl ([77.251.52.224] helo=pinky) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SJNPY-0007t6-5b for freebsd-fs@freebsd.org; Sun, 15 Apr 2012 13:14:28 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org References: <4F8825E5.3040809@gmail.com> <1334323707.4f8829fbe801e@www.hyperdesktop.nl> Date: Sun, 15 Apr 2012 13:14:25 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.62 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.0 X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=disabled version=3.2.5 X-Scan-Signature: e462de357cb394d64966911c06262bc8 Subject: Re: ZFS and disk usage 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, 15 Apr 2012 11:14:30 -0000 On Fri, 13 Apr 2012 17:27:10 +0200, Johannes Totz wrote: > On 13/04/2012 14:28, Mark Schouten wrote: >> Hi, >> >> Op Vrijdag, 13-04-2012 om 15:11 schreef Volodymyr Kostyrko: >>>> These are fiesystems that are created with the following >>>> command. zfs create -V ${size}GB ${ZFS_ROOT}/${diskname} >>> >>> `zfs create -V` withous `-s` creates reserved volume that eats all >>> needed space immediately. Technically zfs pool is filled only for >>> 23%, but logically you have only 138G left unassigned. >> >> I understand. However, the created volumes should use a total of >> 1211GB. That's not 1.6TB like zfs list says. But 1211 + 431 >> (referred) does come close to 1.6TB.n And 1.6 TB still isn't the >> 1.77TB that's in the zpool. >> >> I have this feeling that zfs has reserved the space for each volume, >> but counts data written to the volumes in usage of the main >> filesystem. Mainly because zfs list shows me that the volumes have >> only 16KB referenced, where /storage has 431GB referenced. > > Without checking the numbers myself... > Note that zpool and zfs do not agree on (free) space accounting: zpool > shows "raw" space, whereas zfs includes metadata overhead for itself. > > Small rant: I dont understand why zpool and zfs show different things. > If you have an integrated storage stack then why not show consistent > numbers? Is there any use for this extra (mis-)information that > zpool-vs-zfs provides? > It isn't integrated that far as you might think. That is why you have zpool and zfs tools. These are 2 separate things. You can also put a zvol + ufs or zvol + iscsi on the zpool and not use zfs. How would zpool know about ufs or iscsi usage? Or how would ufs know about the underlying zpool+zvol? Ronald. From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 12:23:18 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 9D583106564A for ; Sun, 15 Apr 2012 12:23:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 58D298FC08 for ; Sun, 15 Apr 2012 12:23:18 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EADm9ik+DaFvO/2dsb2JhbABChXKwLIIJAQEBAwEBAQEgKyALBRYYAgINGQIpAQkmBggHBAEcBIdoBQuqfol5gS+KCIR6gRgEk0GCLIERjySDA4FA X-IronPort-AV: E=Sophos;i="4.75,425,1330923600"; d="scan'208";a="168059275" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 15 Apr 2012 08:23:12 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 27E4BB404E; Sun, 15 Apr 2012 08:23:12 -0400 (EDT) Date: Sun, 15 Apr 2012 08:23:12 -0400 (EDT) From: Rick Macklem To: dave jones Message-ID: <820343268.2824968.1334492592121.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: 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: A question about msdosfs code 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, 15 Apr 2012 12:23:18 -0000 Dave Jones wrote: > Hello, > > I have a question about the MSDOSFSROOT_OFS definition in denode.h: > > /* > * Internal pseudo-offset for (nonexistent) directory entry for the > root > * dir in the root dir > */ > #define MSDOSFSROOT_OFS 0x1fffffff > > I'm wondering why setting the root directory offset is 0x1fffffff? > Is there any formula to calculate root dir offset instead? Thank you. > The root dir of FAT file systems don't have entries for "." or ".." in them. I haven't looked at the code, but I suspect this value is just used to tell readdir code to fake them. rick > Regards, > Dave. > _______________________________________________ > 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 Sun Apr 15 12:58: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 CB81F106567D; Sun, 15 Apr 2012 12:58:52 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 835308FC08; Sun, 15 Apr 2012 12:58:52 +0000 (UTC) From: vermaden To: Matthew Seaman X-Mailer: interia.pl/pf09 In-Reply-To: <4F8A9918.3080607@FreeBSD.org> References: <4F8A9918.3080607@FreeBSD.org> Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1334494731; bh=Dzo8RFwkyivGBMcqtIyduiRSnOt9vZSIJeY5MP94ypA=; h=From:Subject:To:Cc:X-Mailer:In-Reply-To:References:Message-Id: MIME-Version:Content-Type:Content-Transfer-Encoding; b=mqNhAQCeQVocYBWDbhnVweV/tMdFLqpNjCui7/6d/nVBFB3m4z+mkP1gf/lx9+63z gqxIHSYxg4u1EOMleCeHg5vIswIUIKWERNx4LevJTARNKQSCoay3gG2kEC1Bmmv3Ht Ca+k05I641/iuMbEKE65+qBjmTp5YLupJqnqCJek= Date: Sun, 15 Apr 2012 12:58:52 +0000 (UTC) Cc: freebsd-fs@FreeBSD.org, freebsd-questions@FreeBSD.org Subject: Re: Mounting from zfs:system/ROOT/nch failed with error 2 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, 15 Apr 2012 12:58:52 -0000 Hi, thanks for fast response, here is the recipe I used ... "Matthew Seaman" pisze: > On 15/04/2012 10:23, vermaden wrote: > > I have a system that successfully booted from system/ROOT/default, > > but now failed with system/ROOT/nch (other ROOT installation), > > it ends with ERROR 2, what does ERROR 2 means? >=20 > Setting up for use with boot environments? Can you describe how you did > this, or at least point us towards a recipe you followed? # gpart destroy -F ada0 # gpart create -s GPT ada0 # gpart add -t freebsd-boot -l bootcode -s 128k ada0 # gpart add -t freebsd-zfs -l system ada0 # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 # zpool create -f -o cachefile=3D/tmp/zpool.cache system gpt/system # zfs create system/ROOT # zfs create system/ROOT/default # zfs set mountpoint=3Dnone system # zfs set mountpoint=3Dnone system/ROOT # zfs set mountpoint=3D/mnt system/ROOT/default # zpool set bootfs=3Dsystem/ROOT/default system # cd /usr/freebsd-dist/ # sh sh# for I in base* kernel*; do tar --unlink -xvpJf $I -C /mnt; done sh# CTRL-D # cp /tmp/zpool.cache /mnt/boot/zfs/ # cat > /mnt/boot/loader.conf << EOF # zfs_load=3DYES # vfs.root.mountfrom=3D"zfs:sys/ROOT/default" # EOF # cat > /mnt/etc/rc.conf << EOF # zfs_enable=3DYES # EOF # :> /mnt/etc/fstab # zfs umount -a # zfs set mountpoint=3Dlegacy sys/ROOT/default Then, from the OTHER system installed with this same instructions I moved this OTHER system 'nch' bootable environment with zfs send | ssh zfs recv to this server and set in /boot/loader.conf 'nch' mount vfs.root.mountfrom=3D"zfs:sys/ROOT/nch" and also zpool set bootfs=3Dzfs:sys/ROOT/nch" then reboot and got this error. > > Its 9.0-RELEASE. >=20 > Good. However, not particularly pertinent to the problem at hand. >=20 > If we are to help you work out what went wrong, we will need a tad more > information than you have supplied. Primarily at what point in the boot > sequence did it go wrong? Before the BSD Logo menu screen? During the > kernel initialization (ie. while it was printing bright white text) or > after (grey coloured text)? Were there any other error messages printed > on the console? Loader starts, modules are shown, menu is shown, the boot after timeout starts normal boot, hardware is detected (disks/nics/...), and when it comes to trying to mount root from I get this error. > Cheers, >=20 > Matthew >=20 > --=20 > Dr Matthew J Seaman MA, D.Phil. > PGP: http://www.infracaninophile.co.uk/pgpkey Also, I have restored that system with booting form FreeBSD 9.0 ISO and specyfyjng: # zpool import system # zfs set mountpoint=3D/ system/ROOT/nch now it works, but it should also work with LEGACY set as mountpoint ... Is it a bug or maybe I have done wrong something? Regards, vermaden ... From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 14:10:13 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3464D106566C for ; Sun, 15 Apr 2012 14:10: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 1FF868FC12 for ; Sun, 15 Apr 2012 14:10: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 q3FEAD5x006330 for ; Sun, 15 Apr 2012 14:10:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3FEACm1006329; Sun, 15 Apr 2012 14:10:12 GMT (envelope-from gnats) Date: Sun, 15 Apr 2012 14:10:12 GMT Message-Id: <201204151410.q3FEACm1006329@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/166477: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 14:10:13 -0000 The following reply was made to PR kern/166477; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/166477: commit references a PR Date: Sun, 15 Apr 2012 14:06:45 +0000 (UTC) crees 2012-04-15 14:06:32 UTC FreeBSD ports repository Modified files: databases/ludia Makefile distinfo Added files: databases/ludia/files patch-pgsenna2.c Log: - Update to 1.5.2 - Use USE_PGSQL for server dependency - Fix build with postgresql-8.3 and change dependency Obtained from: http://decide.cocolog-nifty.com/blog/2009/03/postgresql-836-.html PR: ports/166477 Submitted by: crees Revision Changes Path 1.8 +8 -13 ports/databases/ludia/Makefile 1.4 +2 -2 ports/databases/ludia/distinfo 1.1 +17 -0 ports/databases/ludia/files/patch-pgsenna2.c (new) _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 14:39:58 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 7F0101065670; Sun, 15 Apr 2012 14:39:58 +0000 (UTC) (envelope-from crees@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 533228FC18; Sun, 15 Apr 2012 14:39:58 +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 q3FEdwX7035538; Sun, 15 Apr 2012 14:39:58 GMT (envelope-from crees@freefall.freebsd.org) Received: (from crees@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3FEdwsl035534; Sun, 15 Apr 2012 14:39:58 GMT (envelope-from crees) Date: Sun, 15 Apr 2012 14:39:58 GMT Message-Id: <201204151439.q3FEdwsl035534@freefall.freebsd.org> To: pfmeec@rit.edu, crees@FreeBSD.org, freebsd-fs@FreeBSD.org From: crees@FreeBSD.org Cc: Subject: Re: kern/166477: [nfs] NFS data corruption. 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, 15 Apr 2012 14:39:58 -0000 Synopsis: [nfs] NFS data corruption. State-Changed-From-To: open->closed State-Changed-By: crees State-Changed-When: Sun Apr 15 14:39:57 UTC 2012 State-Changed-Why: Committed. http://www.freebsd.org/cgi/query-pr.cgi?pr=166477 From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 14:41:15 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1FEA51065672; Sun, 15 Apr 2012 14:41:15 +0000 (UTC) (envelope-from crees@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E7A3C8FC08; Sun, 15 Apr 2012 14:41:14 +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 q3FEfELI042759; Sun, 15 Apr 2012 14:41:14 GMT (envelope-from crees@freefall.freebsd.org) Received: (from crees@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3FEfEvL042750; Sun, 15 Apr 2012 14:41:14 GMT (envelope-from crees) Date: Sun, 15 Apr 2012 14:41:14 GMT Message-Id: <201204151441.q3FEfEvL042750@freefall.freebsd.org> To: pfmeec@rit.edu, crees@FreeBSD.org, freebsd-fs@FreeBSD.org From: crees@FreeBSD.org Cc: Subject: Re: kern/166477: [nfs] NFS data corruption. 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, 15 Apr 2012 14:41:15 -0000 Synopsis: [nfs] NFS data corruption. State-Changed-From-To: closed->open State-Changed-By: crees State-Changed-When: Sun Apr 15 14:41:14 UTC 2012 State-Changed-Why: Wow, typed the PR number in twice wrongly, sorry. http://www.freebsd.org/cgi/query-pr.cgi?pr=166477 From owner-freebsd-fs@FreeBSD.ORG Sun Apr 15 21:19: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 84E16106566C for ; Sun, 15 Apr 2012 21:19:58 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 04AC38FC08 for ; Sun, 15 Apr 2012 21:19:58 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id A2B91125422 for ; Mon, 16 Apr 2012 06:19:50 +0900 (JST) Date: Mon, 16 Apr 2012 06:19:43 +0900 From: Daichi GOTO To: freebsd-fs@freebsd.org Message-Id: <20120416061943.7c66e4c5.daichi@freebsd.org> Organization: FreeBSD Project X-Mailer: Sylpheed 3.1.3 (GTK+ 2.24.6; amd64-portbld-freebsd9.9) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Mon__16_Apr_2012_06_19_43_+0900_c/aaVCKsfmz6CdvK" Subject: Fw: Re: (unionfs) panic: excl->share with r230341 and above 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, 15 Apr 2012 21:19:58 -0000 This is a multi-part message in MIME format. --Multipart=_Mon__16_Apr_2012_06_19_43_+0900_c/aaVCKsfmz6CdvK Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi unionfs guys, The latest patch I included looks working well. Check it out please. If it has no problem, I am going to merge to the 10-current at the end of this month ;) Thanks. Begin forwarded message: Date: Tue, 10 Apr 2012 11:28:34 +0900 From: Daichi GOTO To: kwhite@site.uottawa.ca Cc: freebsd-current@freebsd.org Subject: Re: (unionfs) panic: excl->share with r230341 and above Thanks kwhite, I found an another lock issue. Please try a patch included. On Mon, 9 Apr 2012 10:31:39 -0400 (EDT) kwhite@site.uottawa.ca wrote: > > Hi > > > > Please try an attached patch that improves handlings of fs locks. > > I think that this patch can resolve this issue. If that works well, > > I'm going to refine and commit it to head. > > > > Thanks! > > I tried your patch but get the same panic: > > FreeBSD 10.0-CURRENT #6 r233856M: Mon Apr 9 09:47:42 EDT 2012 > ... > exclusive lock of (lockmgr) ufs @ > /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1897 > while share locked from /usr/src/sys/modules/unionfs/../../fs/unionfs/ > union_vnops.c:1897 > panic: excl->share > cpuid = 0 > KDB: enter: panic > [ thread pid 38 tid 100050 ] > Stopped at kdb_enter+0x3b: movl $0,kdb_why > db> show all locks > Process 38 (ls) thread 0xc56dd2e0 (100050) > exclusive sleep mutex vnode interlock (vnode interlock) r = 0 > (0xc5797d38) locked @ > /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1889 > shared lockmgr ufs (ufs) r = 0 (0xc5797d18) locked @ > /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1897 > db> > > > On Fri, 6 Apr 2012 21:36:29 -0400 (EDT) > > kwhite@site.uottawa.ca wrote: > >> Starting with r230341, I get the following panic when trying to run > >> an executable on a unionfs filesystem: > >> > >> exclusive lock of (lockmgr) ufs @ > >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 > >> while share locked from > >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 > >> panic: excl->share > >> cpuid = 0 > >> KDB: enter: panic > >> > >> Narrowing down with a binary search: r230340 (no panic), r230341 > >> (panic). > >> > >> How to repeat: > >> # uuname -a > >> FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #5 r233946M: Fri Apr > >> 6 > >> 21:09:32 EDT 2012 kwhite@demo:/usr/src/obj/usr/src/sys/GENERIC > >> i386 > >> > >> # mkdir /tmp/local > >> # mount -t unionfs -o noatime /tmp/local /usr/local > >> # cp /bin/ls /usr/local/bin/ls > >> # /usr/local/bin/ls > >> .... > >> exclusive lock of (lockmgr) ufs @ > >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 > >> while share locked from > >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 > >> panic: excl->share > >> cpuid = 0 > >> KDB: enter: panic > >> [ thread pid 68 tid 100054 ] > >> Stopped at kdb_enter+0x3b: movl $0,kdb_why > >> db> show all locks > >> Process 68 (ls) thread 0xc5780000 (100054) > >> exclusive sleep mutex vnode interlock (vnode interlock) r = 0 > >> (0xc57cec28) locked @ > >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1835 > >> shared lockmgr ufs (ufs) r = 0 (0xc57cec08) locked @ > >> /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1843 > >> db> > >> > >> Workaround? > >> After reverting the change from LK_EXCLUSIVE to LK_SHARED > >> in sys/kern/kern_exec.c, executables on union filesystems no > >> longer cause a panic. > >> > >> ...keith > >> > >> > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to > >> "freebsd-current-unsubscribe@freebsd.org" > > > > > > -- > > Daichi GOTO (daichi) > > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Daichi GOTO (daichi) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve --Multipart=_Mon__16_Apr_2012_06_19_43_+0900_c/aaVCKsfmz6CdvK Content-Type: text/x-diff; name="unionfs_20120410.diff" Content-Disposition: attachment; filename="unionfs_20120410.diff" Content-Transfer-Encoding: 7bit diff -urBN /usr/src.orig/sys/fs/unionfs/union_subr.c /usr/src/sys/fs/unionfs/union_subr.c --- /usr/src.orig/sys/fs/unionfs/union_subr.c 2012-04-08 14:01:23.000000000 +0900 +++ /usr/src/sys/fs/unionfs/union_subr.c 2012-04-10 02:22:38.000000000 +0900 @@ -350,19 +350,22 @@ uvp = unp->un_uppervp; dvp = unp->un_dvp; unp->un_lowervp = unp->un_uppervp = NULLVP; - vp->v_vnlock = &(vp->v_lock); vp->v_data = NULL; - lockmgr(vp->v_vnlock, LK_EXCLUSIVE | LK_INTERLOCK, VI_MTX(vp)); + vp->v_object = NULL; + VI_UNLOCK(vp); + if (lvp != NULLVP) - VOP_UNLOCK(lvp, 0); + VOP_UNLOCK(lvp, LK_RELEASE); if (uvp != NULLVP) - VOP_UNLOCK(uvp, 0); - vp->v_object = NULL; + VOP_UNLOCK(uvp, LK_RELEASE); if (dvp != NULLVP && unp->un_hash.le_prev != NULL) unionfs_rem_cached_vnode(unp, dvp); + if (lockmgr(vp->v_vnlock, LK_EXCLUSIVE, VI_MTX(vp)) != 0) + panic("the lock for deletion is unacquirable."); + if (lvp != NULLVP) { vfslocked = VFS_LOCK_GIANT(lvp->v_mount); vrele(lvp); @@ -550,7 +553,7 @@ cn->cn_flags |= (cnp->cn_flags & SAVESTART); vref(dvp); - VOP_UNLOCK(dvp, 0); + VOP_UNLOCK(dvp, LK_RELEASE); if ((error = relookup(dvp, vpp, cn))) { uma_zfree(namei_zone, cn->cn_pnbuf); @@ -957,7 +960,7 @@ *vpp = vp; unionfs_vn_create_on_upper_free_out1: - VOP_UNLOCK(udvp, 0); + VOP_UNLOCK(udvp, LK_RELEASE); unionfs_vn_create_on_upper_free_out2: if (cn.cn_flags & HASBUF) { diff -urBN /usr/src.orig/sys/fs/unionfs/union_vfsops.c /usr/src/sys/fs/unionfs/union_vfsops.c --- /usr/src.orig/sys/fs/unionfs/union_vfsops.c 2012-04-08 14:01:23.000000000 +0900 +++ /usr/src/sys/fs/unionfs/union_vfsops.c 2012-04-10 02:22:38.000000000 +0900 @@ -165,7 +165,7 @@ uid = va.va_uid; gid = va.va_gid; } - VOP_UNLOCK(mp->mnt_vnodecovered, 0); + VOP_UNLOCK(mp->mnt_vnodecovered, LK_RELEASE); if (error) return (error); @@ -250,7 +250,7 @@ * Save reference */ if (below) { - VOP_UNLOCK(upperrootvp, 0); + VOP_UNLOCK(upperrootvp, LK_RELEASE); vn_lock(lowerrootvp, LK_EXCLUSIVE | LK_RETRY); ump->um_lowervp = upperrootvp; ump->um_uppervp = lowerrootvp; @@ -281,7 +281,7 @@ /* * Unlock the node */ - VOP_UNLOCK(ump->um_uppervp, 0); + VOP_UNLOCK(ump->um_uppervp, LK_RELEASE); /* * Get the unionfs root vnode. diff -urBN /usr/src.orig/sys/fs/unionfs/union_vnops.c /usr/src/sys/fs/unionfs/union_vnops.c --- /usr/src.orig/sys/fs/unionfs/union_vnops.c 2012-04-08 14:01:23.000000000 +0900 +++ /usr/src/sys/fs/unionfs/union_vnops.c 2012-04-10 02:22:38.000000000 +0900 @@ -75,21 +75,6 @@ KASSERT(((vp)->v_op == &unionfs_vnodeops), \ ("unionfs: it is not unionfs-vnode")) -/* lockmgr lock <-> reverse table */ -struct lk_lr_table { - int lock; - int revlock; -}; - -static struct lk_lr_table un_llt[] = { - {LK_SHARED, LK_RELEASE}, - {LK_EXCLUSIVE, LK_RELEASE}, - {LK_UPGRADE, LK_DOWNGRADE}, - {LK_DOWNGRADE, LK_UPGRADE}, - {0, 0} -}; - - static int unionfs_lookup(struct vop_cachedlookup_args *ap) { @@ -141,7 +126,7 @@ if (udvp != NULLVP) { dtmpvp = udvp; if (ldvp != NULLVP) - VOP_UNLOCK(ldvp, 0); + VOP_UNLOCK(ldvp, LK_RELEASE); } else dtmpvp = ldvp; @@ -149,7 +134,7 @@ error = VOP_LOOKUP(dtmpvp, &vp, cnp); if (dtmpvp == udvp && ldvp != NULLVP) { - VOP_UNLOCK(udvp, 0); + VOP_UNLOCK(udvp, LK_RELEASE); vn_lock(dvp, LK_EXCLUSIVE | LK_RETRY); } @@ -161,10 +146,10 @@ */ if (nameiop == DELETE || nameiop == RENAME || (cnp->cn_lkflags & LK_TYPE_MASK)) - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); vrele(vp); - VOP_UNLOCK(dvp, 0); + VOP_UNLOCK(dvp, LK_RELEASE); *(ap->a_vpp) = dunp->un_dvp; vref(dunp->un_dvp); @@ -202,7 +187,7 @@ } if (nameiop == DELETE || nameiop == RENAME || (cnp->cn_lkflags & LK_TYPE_MASK)) - VOP_UNLOCK(uvp, 0); + VOP_UNLOCK(uvp, LK_RELEASE); } /* check whiteout */ @@ -246,7 +231,7 @@ return (lerror); } if (cnp->cn_lkflags & LK_TYPE_MASK) - VOP_UNLOCK(lvp, 0); + VOP_UNLOCK(lvp, LK_RELEASE); } } @@ -281,7 +266,7 @@ goto unionfs_lookup_out; if (LK_SHARED == (cnp->cn_lkflags & LK_TYPE_MASK)) - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); if (LK_EXCLUSIVE != VOP_ISLOCKED(vp)) { vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); lockflag = 1; @@ -289,7 +274,7 @@ error = unionfs_mkshadowdir(MOUNTTOUNIONFSMOUNT(dvp->v_mount), udvp, VTOUNIONFS(vp), cnp, td); if (lockflag != 0) - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); if (error != 0) { UNIONFSDEBUG("unionfs_lookup: Unable to create shadow dir."); if ((cnp->cn_lkflags & LK_TYPE_MASK) == LK_EXCLUSIVE) @@ -386,7 +371,7 @@ if (vp->v_type == VSOCK) *(ap->a_vpp) = vp; else { - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); error = unionfs_nodeget(ap->a_dvp->v_mount, vp, NULLVP, ap->a_dvp, ap->a_vpp, cnp, curthread); vrele(vp); @@ -460,7 +445,7 @@ if (vp->v_type == VSOCK) *(ap->a_vpp) = vp; else { - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); error = unionfs_nodeget(ap->a_dvp->v_mount, vp, NULLVP, ap->a_dvp, ap->a_vpp, cnp, curthread); vrele(vp); @@ -564,6 +549,7 @@ struct unionfs_node_status *unsp; struct ucred *cred; struct thread *td; + struct vnode *vp; struct vnode *ovp; UNIONFS_INTERNAL_DEBUG("unionfs_close: enter\n"); @@ -571,12 +557,14 @@ KASSERT_UNIONFS_VNODE(ap->a_vp); locked = 0; - unp = VTOUNIONFS(ap->a_vp); + vp = ap->a_vp; + unp = VTOUNIONFS(vp); cred = ap->a_cred; td = ap->a_td; - if (VOP_ISLOCKED(ap->a_vp) != LK_EXCLUSIVE) { - vn_lock(ap->a_vp, LK_EXCLUSIVE | LK_RETRY); + if (VOP_ISLOCKED(vp) != LK_EXCLUSIVE) { + if (vn_lock(vp, LK_UPGRADE) != 0) + vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); locked = 1; } unionfs_get_node_status(unp, td, &unsp); @@ -599,7 +587,7 @@ if (error != 0) goto unionfs_close_abort; - ap->a_vp->v_object = ovp->v_object; + vp->v_object = ovp->v_object; if (ovp == unp->un_uppervp) { unsp->uns_upper_opencnt--; @@ -610,7 +598,7 @@ unsp->uns_lower_opencnt--; } if (unsp->uns_lower_opencnt > 0) - ap->a_vp->v_object = unp->un_lowervp->v_object; + vp->v_object = unp->un_lowervp->v_object; } } else unsp->uns_lower_opencnt--; @@ -619,7 +607,7 @@ unionfs_tryrem_node_status(unp, unsp); if (locked != 0) - VOP_UNLOCK(ap->a_vp, 0); + vn_lock(vp, LK_DOWNGRADE | LK_RETRY); UNIONFS_INTERNAL_DEBUG("unionfs_close: leave (%d)\n", error); @@ -914,7 +902,7 @@ unionfs_get_node_status(unp, ap->a_td, &unsp); ovp = (unsp->uns_upper_opencnt ? unp->un_uppervp : unp->un_lowervp); unionfs_tryrem_node_status(unp, unsp); - VOP_UNLOCK(ap->a_vp, 0); + VOP_UNLOCK(ap->a_vp, LK_RELEASE); if (ovp == NULLVP) return (EBADF); @@ -941,7 +929,7 @@ unionfs_get_node_status(unp, ap->a_td, &unsp); ovp = (unsp->uns_upper_opencnt ? unp->un_uppervp : unp->un_lowervp); unionfs_tryrem_node_status(unp, unsp); - VOP_UNLOCK(ap->a_vp, 0); + VOP_UNLOCK(ap->a_vp, LK_RELEASE); if (ovp == NULLVP) return (EBADF); @@ -1001,7 +989,7 @@ ump = NULL; vp = uvp = lvp = NULLVP; /* search vnode */ - VOP_UNLOCK(ap->a_vp, 0); + VOP_UNLOCK(ap->a_vp, LK_RELEASE); error = unionfs_relookup(udvp, &vp, cnp, &cn, td, cnp->cn_nameptr, strlen(cnp->cn_nameptr), DELETE); if (error != 0 && error != ENOENT) { @@ -1204,7 +1192,7 @@ if ((error = vn_lock(fvp, LK_EXCLUSIVE)) != 0) goto unionfs_rename_abort; error = unionfs_copyfile(unp, 1, fcnp->cn_cred, td); - VOP_UNLOCK(fvp, 0); + VOP_UNLOCK(fvp, LK_RELEASE); if (error != 0) goto unionfs_rename_abort; break; @@ -1212,7 +1200,7 @@ if ((error = vn_lock(fvp, LK_EXCLUSIVE)) != 0) goto unionfs_rename_abort; error = unionfs_mkshadowdir(ump, rfdvp, unp, fcnp, td); - VOP_UNLOCK(fvp, 0); + VOP_UNLOCK(fvp, LK_RELEASE); if (error != 0) goto unionfs_rename_abort; break; @@ -1269,13 +1257,13 @@ if ((error = vn_lock(fdvp, LK_EXCLUSIVE)) != 0) goto unionfs_rename_abort; error = unionfs_relookup_for_delete(fdvp, fcnp, td); - VOP_UNLOCK(fdvp, 0); + VOP_UNLOCK(fdvp, LK_RELEASE); if (error != 0) goto unionfs_rename_abort; /* Locke of tvp is canceled in order to avoid recursive lock. */ if (tvp != NULLVP && tvp != tdvp) - VOP_UNLOCK(tvp, 0); + VOP_UNLOCK(tvp, LK_RELEASE); error = unionfs_relookup_for_rename(tdvp, tcnp, td); if (tvp != NULLVP && tvp != tdvp) vn_lock(tvp, LK_EXCLUSIVE | LK_RETRY); @@ -1293,11 +1281,11 @@ } if (ltdvp != NULLVP) - VOP_UNLOCK(ltdvp, 0); + VOP_UNLOCK(ltdvp, LK_RELEASE); if (tdvp != rtdvp) vrele(tdvp); if (ltvp != NULLVP) - VOP_UNLOCK(ltvp, 0); + VOP_UNLOCK(ltvp, LK_RELEASE); if (tvp != rtvp && tvp != NULLVP) { if (rtvp == NULLVP) vput(tvp); @@ -1371,7 +1359,7 @@ } if ((error = VOP_MKDIR(udvp, &uvp, cnp, ap->a_vap)) == 0) { - VOP_UNLOCK(uvp, 0); + VOP_UNLOCK(uvp, LK_RELEASE); cnp->cn_lkflags = LK_EXCLUSIVE; error = unionfs_nodeget(ap->a_dvp->v_mount, uvp, NULLVP, ap->a_dvp, ap->a_vpp, cnp, td); @@ -1467,7 +1455,7 @@ if (udvp != NULLVP) { error = VOP_SYMLINK(udvp, &uvp, cnp, ap->a_vap, ap->a_target); if (error == 0) { - VOP_UNLOCK(uvp, 0); + VOP_UNLOCK(uvp, LK_RELEASE); cnp->cn_lkflags = LK_EXCLUSIVE; error = unionfs_nodeget(ap->a_dvp->v_mount, uvp, NULLVP, ap->a_dvp, ap->a_vpp, cnp, td); @@ -1490,6 +1478,7 @@ struct unionfs_node *unp; struct unionfs_node_status *unsp; struct uio *uio; + struct vnode *vp; struct vnode *uvp; struct vnode *lvp; struct thread *td; @@ -1505,41 +1494,49 @@ error = 0; eofflag = 0; locked = 0; - unp = VTOUNIONFS(ap->a_vp); uio = ap->a_uio; - uvp = unp->un_uppervp; - lvp = unp->un_lowervp; + uvp = NULLVP; + lvp = NULLVP; td = uio->uio_td; ncookies_bk = 0; cookies_bk = NULL; - if (ap->a_vp->v_type != VDIR) + vp = ap->a_vp; + if (vp->v_type != VDIR) return (ENOTDIR); - /* check opaque */ - if (uvp != NULLVP && lvp != NULLVP) { - if ((error = VOP_GETATTR(uvp, &va, ap->a_cred)) != 0) - goto unionfs_readdir_exit; - if (va.va_flags & OPAQUE) - lvp = NULLVP; - } - /* check the open count. unionfs needs to open before readdir. */ - if (VOP_ISLOCKED(ap->a_vp) != LK_EXCLUSIVE) { - vn_lock(ap->a_vp, LK_UPGRADE | LK_RETRY); + if (VOP_ISLOCKED(vp) != LK_EXCLUSIVE) { + if (vn_lock(vp, LK_UPGRADE) != 0) + vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); locked = 1; } - unionfs_get_node_status(unp, td, &unsp); - if ((uvp != NULLVP && unsp->uns_upper_opencnt <= 0) || - (lvp != NULLVP && unsp->uns_lower_opencnt <= 0)) { - unionfs_tryrem_node_status(unp, unsp); + unp = VTOUNIONFS(vp); + if (unp == NULL) error = EBADF; + else { + uvp = unp->un_uppervp; + lvp = unp->un_lowervp; + unionfs_get_node_status(unp, td, &unsp); + if ((uvp != NULLVP && unsp->uns_upper_opencnt <= 0) || + (lvp != NULLVP && unsp->uns_lower_opencnt <= 0)) { + unionfs_tryrem_node_status(unp, unsp); + error = EBADF; + } } - if (locked == 1) - vn_lock(ap->a_vp, LK_DOWNGRADE | LK_RETRY); + if (locked) + vn_lock(vp, LK_DOWNGRADE | LK_RETRY); if (error != 0) goto unionfs_readdir_exit; + /* check opaque */ + if (uvp != NULLVP && lvp != NULLVP) { + if ((error = VOP_GETATTR(uvp, &va, ap->a_cred)) != 0) + goto unionfs_readdir_exit; + if (va.va_flags & OPAQUE) + lvp = NULLVP; + } + /* upper only */ if (uvp != NULLVP && lvp == NULLVP) { error = VOP_READDIR(uvp, uio, ap->a_cred, ap->a_eofflag, @@ -1743,18 +1740,66 @@ } static int -unionfs_get_llt_revlock(int flags) +unionfs_islocked(struct vop_islocked_args *ap) { - int count; + struct unionfs_node *unp; - flags &= LK_TYPE_MASK; - for (count = 0; un_llt[count].lock != 0; count++) { - if (flags == un_llt[count].lock) { - return un_llt[count].revlock; - } + KASSERT_UNIONFS_VNODE(ap->a_vp); + + unp = VTOUNIONFS(ap->a_vp); + if (unp == NULL) + return (vop_stdislocked(ap)); + + if (unp->un_uppervp != NULLVP) + return (VOP_ISLOCKED(unp->un_uppervp)); + if (unp->un_lowervp != NULLVP) + return (VOP_ISLOCKED(unp->un_lowervp)); + return (vop_stdislocked(ap)); +} + +static int +unionfs_get_llt_revlock(struct vnode *vp, int flags) +{ + int revlock; + + revlock = 0; + + switch (flags & LK_TYPE_MASK) { + case LK_SHARED: + if (VOP_ISLOCKED(vp) == LK_EXCLUSIVE) + revlock = LK_UPGRADE; + else + revlock = LK_RELEASE; + break; + case LK_EXCLUSIVE: + case LK_UPGRADE: + revlock = LK_RELEASE; + break; + case LK_DOWNGRADE: + revlock = LK_UPGRADE; + break; + default: + break; } - return 0; + return (revlock); +} + +/* + * The state of an acquired lock is adjusted similarly to + * the time of error generating. + * flags: LK_RELEASE or LK_UPGRADE + */ +static void +unionfs_revlock(struct vnode *vp, int flags) +{ + if (flags & LK_RELEASE) + VOP_UNLOCK(vp, flags); + else { + /* UPGRADE */ + if (vn_lock(vp, flags) != 0) + vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); + } } static int @@ -1763,6 +1808,7 @@ int error; int flags; int revlock; + int interlock; int uhold; struct mount *mp; struct unionfs_mount *ump; @@ -1774,15 +1820,13 @@ KASSERT_UNIONFS_VNODE(ap->a_vp); error = 0; + interlock = 1; uhold = 0; flags = ap->a_flags; vp = ap->a_vp; if (LK_RELEASE == (flags & LK_TYPE_MASK) || !(flags & LK_TYPE_MASK)) - return (VOP_UNLOCK(vp, flags)); - - if ((revlock = unionfs_get_llt_revlock(flags)) == 0) - panic("unknown lock type: 0x%x", flags & LK_TYPE_MASK); + return (VOP_UNLOCK(vp, flags | LK_RELEASE)); if ((flags & LK_INTERLOCK) == 0) VI_LOCK(vp); @@ -1798,6 +1842,9 @@ lvp = unp->un_lowervp; uvp = unp->un_uppervp; + if ((revlock = unionfs_get_llt_revlock(vp, flags)) == 0) + panic("unknown lock type: 0x%x", flags & LK_TYPE_MASK); + if ((mp->mnt_kern_flag & MNTK_MPSAFE) != 0 && (vp->v_iflag & VI_OWEINACT) != 0) flags |= LK_NOWAIT; @@ -1811,6 +1858,23 @@ flags |= LK_CANRECURSE; if (lvp != NULLVP) { + if (uvp != NULLVP && flags & LK_UPGRADE) { + /* Share Lock is once released and a deadlock is avoided. */ + VI_LOCK_FLAGS(uvp, MTX_DUPOK); + vholdl(uvp); + uhold = 1; + VI_UNLOCK(vp); + VOP_UNLOCK(uvp, LK_RELEASE | LK_INTERLOCK); + VI_LOCK(vp); + unp = VTOUNIONFS(vp); + if (unp == NULL) { + /* vnode is released. */ + VI_UNLOCK(vp); + VOP_UNLOCK(lvp, LK_RELEASE); + vdrop(uvp); + return (EBUSY); + } + } VI_LOCK_FLAGS(lvp, MTX_DUPOK); flags |= LK_INTERLOCK; vholdl(lvp); @@ -1823,19 +1887,28 @@ VI_LOCK(vp); unp = VTOUNIONFS(vp); if (unp == NULL) { + /* vnode is released. */ VI_UNLOCK(vp); if (error == 0) - VOP_UNLOCK(lvp, 0); + VOP_UNLOCK(lvp, LK_RELEASE); vdrop(lvp); + if (uhold != 0) + vdrop(uvp); return (vop_stdlock(ap)); } } if (error == 0 && uvp != NULLVP) { + if (uhold && flags & LK_UPGRADE) { + flags &= ~LK_TYPE_MASK; + flags |= LK_EXCLUSIVE; + } VI_LOCK_FLAGS(uvp, MTX_DUPOK); flags |= LK_INTERLOCK; - vholdl(uvp); - uhold = 1; + if (uhold == 0) { + vholdl(uvp); + uhold = 1; + } VI_UNLOCK(vp); ap->a_flags &= ~LK_INTERLOCK; @@ -1845,30 +1918,27 @@ VI_LOCK(vp); unp = VTOUNIONFS(vp); if (unp == NULL) { + /* vnode is released. */ VI_UNLOCK(vp); - if (error == 0) { - VOP_UNLOCK(uvp, 0); - if (lvp != NULLVP) - VOP_UNLOCK(lvp, 0); - } - if (lvp != NULLVP) - vdrop(lvp); + if (error == 0) + VOP_UNLOCK(uvp, LK_RELEASE); vdrop(uvp); + if (lvp != NULLVP) { + VOP_UNLOCK(lvp, LK_RELEASE); + vdrop(lvp); + } return (vop_stdlock(ap)); } - if (error != 0 && lvp != NULLVP) { + /* rollback */ VI_UNLOCK(vp); - if ((revlock & LK_TYPE_MASK) == LK_RELEASE) - VOP_UNLOCK(lvp, revlock); - else - vn_lock(lvp, revlock | LK_RETRY); - goto unionfs_lock_abort; + unionfs_revlock(lvp, revlock); + interlock = 0; } } - VI_UNLOCK(vp); -unionfs_lock_abort: + if (interlock) + VI_UNLOCK(vp); if (lvp != NULLVP) vdrop(lvp); if (uhold != 0) @@ -2013,7 +2083,7 @@ unionfs_tryrem_node_status(unp, unsp); } - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); error = VOP_ADVLOCK(uvp, ap->a_id, ap->a_op, ap->a_fl, ap->a_flags); @@ -2022,7 +2092,7 @@ return error; unionfs_advlock_abort: - VOP_UNLOCK(vp, 0); + VOP_UNLOCK(vp, LK_RELEASE); UNIONFS_INTERNAL_DEBUG("unionfs_advlock: leave (%d)\n", error); @@ -2150,7 +2220,8 @@ error = VOP_OPENEXTATTR(tvp, ap->a_cred, ap->a_td); if (error == 0) { - vn_lock(vp, LK_UPGRADE | LK_RETRY); + if (vn_lock(vp, LK_UPGRADE) != 0) + vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); if (tvp == unp->un_uppervp) unp->un_flag |= UNIONFS_OPENEXTU; else @@ -2186,7 +2257,8 @@ error = VOP_CLOSEEXTATTR(tvp, ap->a_commit, ap->a_cred, ap->a_td); if (error == 0) { - vn_lock(vp, LK_UPGRADE | LK_RETRY); + if (vn_lock(vp, LK_UPGRADE) != 0) + vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); if (tvp == unp->un_uppervp) unp->un_flag &= ~UNIONFS_OPENEXTU; else @@ -2435,6 +2507,7 @@ .vop_getextattr = unionfs_getextattr, .vop_getwritemount = unionfs_getwritemount, .vop_inactive = unionfs_inactive, + .vop_islocked = unionfs_islocked, .vop_ioctl = unionfs_ioctl, .vop_link = unionfs_link, .vop_listextattr = unionfs_listextattr, --Multipart=_Mon__16_Apr_2012_06_19_43_+0900_c/aaVCKsfmz6CdvK-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 16 01:01:48 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0996D106564A for ; Mon, 16 Apr 2012 01:01:48 +0000 (UTC) (envelope-from claudius_herder@ambtec.de) Received: from server.ambtec.de (server.ambtec.de [IPv6:2a01:4f8:151:7182::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7C04E8FC0A for ; Mon, 16 Apr 2012 01:01:47 +0000 (UTC) Received: from server.ambtec.de (localhost [127.0.0.1]) by server.ambtec.de (Postfix) with ESMTP id 89229E400 for ; Mon, 16 Apr 2012 03:01:46 +0200 (CEST) X-Virus-Scanned: by amavisd-new using ClamAV at ambtec.de Received: from server.ambtec.de ([127.0.0.1]) by server.ambtec.de (server.ambtec.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xyqYvvZ0IekV for ; Mon, 16 Apr 2012 03:01:39 +0200 (CEST) Received: from [192.168.0.101] (e176005166.adsl.alicedsl.de [85.176.5.166]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.ambtec.de (Postfix) with ESMTPSA id 05ACEE3F0 for ; Mon, 16 Apr 2012 03:01:38 +0200 (CEST) Message-ID: <4F8B6F75.1050702@ambtec.de> Date: Mon, 16 Apr 2012 03:01:41 +0200 From: Claudius Herder User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120330 Thunderbird/11.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig14AB2B542627BB5580C3287A" Subject: zfs diff caused kernel panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 01:01:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig14AB2B542627BB5580C3287A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, i received a kernel panic after running zfs diff on system/rootfs, other filesystems work without problems. Apr 15 21:11:17 server kernel: Fatal trap 9: general protection fault while in kernel mode Apr 15 21:11:17 server kernel: cpuid =3D 3; apic id =3D 03 Apr 15 21:11:17 server kernel: instruction pointer =3D 0x20:0xffffffff80b0ff91 Apr 15 21:11:17 server kernel: stack pointer =3D 0x28:0xffffff845fa1b430 Apr 15 21:11:17 server kernel: frame pointer =3D 0x28:0xffffff845fa1b470 Apr 15 21:11:17 server kernel: code segment =3D base 0x0, limit 0xfffff, type 0x1b Apr 15 21:11:17 server kernel: =3D DPL 0, pres 1, long 1, def32 0, gran 1= Apr 15 21:11:17 server kernel: processor eflags =3D interrupt enabled, resume, IOPL =3D 0 Apr 15 21:11:17 server kernel: current process =3D 1797 (zfs) Apr 15 21:11:17 server kernel: trap number =3D 9 Apr 15 21:11:17 server kernel: panic: general protection fault Apr 15 21:11:17 server kernel: cpuid =3D 3 Apr 15 21:11:17 server kernel: KDB: stack backtrace: Apr 15 21:11:17 server kernel: #0 0xffffffff803fcb5e at kdb_backtrace+0x5= e Apr 15 21:11:17 server kernel: #1 0xffffffff803c9ce3 at panic+0x183 Apr 15 21:11:17 server kernel: #2 0xffffffff805c49a0 at trap_fatal+0x290 Apr 15 21:11:17 server kernel: #3 0xffffffff805c4eda at trap+0x10a Apr 15 21:11:17 server kernel: #4 0xffffffff805af7ef at calltrap+0x8 Apr 15 21:11:17 server kernel: #5 0xffffffff80b0f0e0 at fzap_cursor_retrieve+0x110 Apr 15 21:11:17 server kernel: #6 0xffffffff80b13bc5 at zap_cursor_retrieve+0x155 Apr 15 21:11:17 server kernel: #7 0xffffffff80b0e12f at zap_value_search+0x7f Apr 15 21:11:17 server kernel: #8 0xffffffff80b18912 at zfs_obj_to_path_impl+0x292 Apr 15 21:11:17 server kernel: #9 0xffffffff80b18b45 at zfs_obj_to_stats+0x175 Apr 15 21:11:17 server kernel: #10 0xffffffff80b3075e at zfs_ioc_obj_to_stats+0x7e Apr 15 21:11:17 server kernel: #11 0xffffffff80b33a46 at zfsdev_ioctl+0xe= 6 Apr 15 21:11:17 server kernel: #12 0xffffffff8034e4db at devfs_ioctl_f+0x= 7b Apr 15 21:11:17 server kernel: #13 0xffffffff8040e185 at kern_ioctl+0x115= Apr 15 21:11:17 server kernel: #14 0xffffffff8040e3b0 at sys_ioctl+0xf0 Apr 15 21:11:17 server kernel: #15 0xffffffff805c4290 at amd64_syscall+0x= 450 Apr 15 21:11:17 server kernel: #16 0xffffffff805afad7 at Xfast_syscall+0x= f7 I tried different snapshots on rootfs to narrow down then problem, but after a few forced reboots and zpool scrub after each crash zfs diff hangs only. procstat -k -k 8428 PID TID COMM TDNAME KSTACK 8428 100719 zfs - mi_switch+0x174 sleepq_catch_signals+0x2f4 sleepq_wait_sig+0xc _sleep+0x279 pipe_write+0x125e write_record+0x79 report_free_dnode_range+0x2c diff_cb+0x1bf traverse_visitbp+0x21c traverse_visitbp+0x309 traverse_visitbp+0x309 traverse_visitbp+0x309 traverse_visitbp+0x309 traverse_visitbp+0x309 traverse_visitbp+0x309 traverse_dnode+0x7c traverse_visitbp+0x47f traverse_impl+0x188 8428 101237 zfs - mi_switch+0x174 sleepq_wait+0x42 _sx_slock_hard+0x1f2 _sx_slock+0x45 zap_get_leaf_byblk+0xbd zap_deref_leaf+0x68 fzap_cursor_retrieve+0xe7 zap_cursor_retrieve+0x155 zap_value_search+0x7f zfs_obj_to_path_impl+0x292 zfs_obj_to_stats+0x175 zfs_ioc_obj_to_stats+0x7e zfsdev_ioctl+0xe6 devfs_ioctl_f+0x7b kern_ioctl+0x115 sys_ioctl+0xf0 amd64_syscall+0x450 Xfast_syscall+0xf7 Any hints how to debug this further? -- Regards and thanks in advance Claudius --------------enig14AB2B542627BB5580C3287A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Lb3UACgkQum7BwTrPFfG92ACfUSV9p89pa/GURjz6fM2vV7vN pkAAoKbdW/rVmgL4fPAtCe0Tsmr75woL =Afah -----END PGP SIGNATURE----- --------------enig14AB2B542627BB5580C3287A-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 16 03:58:59 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88C7D106566B; Mon, 16 Apr 2012 03:58:59 +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 59EB08FC0C; Mon, 16 Apr 2012 03:58:59 +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 q3G3wxJ6086480; Mon, 16 Apr 2012 03:58:59 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3G3wx8e086476; Mon, 16 Apr 2012 03:58:59 GMT (envelope-from linimon) Date: Mon, 16 Apr 2012 03:58:59 GMT Message-Id: <201204160358.q3G3wx8e086476@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/166851: [zfs] [hang] Copying directory from the mounted UFS disk image hangs in DL+ vnread state (source and destination both on the same ZFS) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 03:58:59 -0000 Old Synopsis: Copying directory from the mounted UFS disk image hangs in DL+ vnread state (source and destination both on the same ZFS) New Synopsis: [zfs] [hang] Copying directory from the mounted UFS disk image hangs in DL+ vnread state (source and destination both on the same ZFS) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 16 03:58:43 UTC 2012 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=166851 From owner-freebsd-fs@FreeBSD.ORG Mon Apr 16 08:35:15 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D82C106566B for ; Mon, 16 Apr 2012 08:35:15 +0000 (UTC) (envelope-from mark@tuxis.nl) Received: from smtp.tuxis.nl (smtp.tuxis.nl [IPv6:2a03:7900:2:0:31:3:104:34]) by mx1.freebsd.org (Postfix) with ESMTP id E77AA8FC0A for ; Mon, 16 Apr 2012 08:35:14 +0000 (UTC) Received: from [2a03:7900:2:0:31:3:104:46] (port=43096 helo=go.tuxis.net) by smtp.tuxis.nl with esmtp (Exim 4.71) (envelope-from ) id 1SJhOz-0001IB-Rl for freebsd-fs@freebsd.org; Mon, 16 Apr 2012 10:35:13 +0200 Received: from localhost (localhost [127.0.0.1]) by go.tuxis.net (Postfix) with ESMTP id C49A220C96 for ; Mon, 16 Apr 2012 10:35:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at www.hyperdesktop.nl Received: from go.tuxis.net ([127.0.0.1]) by localhost (go.tuxis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4FuoZnKrbkI for ; Mon, 16 Apr 2012 10:35:39 +0200 (CEST) Received: from www.hyperdesktop.nl (unknown [IPv6:::1]) by go.tuxis.net (Postfix) with ESMTP id 330BA20C94 for ; Mon, 16 Apr 2012 10:35:39 +0200 (CEST) Message-ID: <1334565339.4f8bd9db1134e@www.hyperdesktop.nl> Date: Mon, 16 Apr 2012 10:35:39 +0200 From: Mark Schouten To: Volodymyr Kostyrko MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced by Group-Office 3.7.42 In-Reply-To: <4F88553B.5030005@gmail.com> References: <4F88553B.5030005@gmail.com> X-Mailer: Group-Office 3.7.42 X-Priority: 3 (Normal) Cc: "freebsd-fs@freebsd.org" Subject: Re: ZFS and disk usage 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, 16 Apr 2012 08:35:15 -0000 Hi, Op Vrijdag, 13-04-2012 om 18:32 schreef Volodymyr Kostyrk= o: > After reinventing calculator I'm just puzzled and shamed. This = looks=20 > strange. >=20 > Indeed not just a single byte from th= is files should count directly for=20 > the main filesystem. > = > Just curious, what `ls -la /storage/' and `ls -la /storage/.zfs/s= *` show? [root@storage ~]# zfs list -o name,used,referenced,use= dbychildren,usedbydataset,usedbysnapshots,available,mountpoint,quota,res= erv,refquota,refreserv "$@" | sed -r "s/none/ -/g" NAME = USED REFER USEDCHILD USEDDS USEDSNAP AVAIL= MOUNTPOINT QUOTA RESERV REFQUOTA REFRESERV storage = 1.60T 431G 1.18T 431G 0 138G /s= torage - - - - storage/av.https-ict.nl= .OS 20G 16K 0 16K 0 158G - = - - - 20G storage/bestandonline.https= -ict.nl.OS 20G 16K 0 16K 0 158G - = - - - 20G storage/crm.fastbenelux.DATA = 100G 16K 0 16K 0 238G - = - - - 100G storage/crm.fastbenelux.OS = 20G 16K 0 16K 0 158G - - = - - 20G storage/default.do.not.remove = 1G 16K 0 16K 0 139G - - = - - 1G storage/mail.https-ict.nl.DATA 400= G 16K 0 16K 0 538G - - - = - 400G storage/mail.https-ict.nl.OS 20G = 16K 0 16K 0 158G - - - = - 20G storage/webserver.https-ict.nl.DATA 400G 16K= 0 16K 0 538G - - - = - 400G storage/webserver.https-ict.nl.OS 20G 16K = 0 16K 0 158G - - - - = 20G storage/webserver2.https-ict.nl.DATA 20G 16K = 0 16K 0 158G - - - - = 20G storage/webserver2.https-ict.nl.OS 20G 16K 0 = 16K 0 158G - - - - 20G= storage/xlmail.xladsl.nl.DATA 150G 16K 0 = 16K 0 288G - - - - 150G= storage/xlmail.xladsl.nl.os 20G 16K 0 = 16K 0 158G - - - - 20G= [root@storage /storage]# ls -al=20 total 452101743 d= rwxr-xr-x 2 root wheel 18 Mar 24 17:42 . drwxr-xr-x 2= 0 root wheel 512 May 10 2011 .. -rw-r--r-- 1 root whee= l 21474836480 Apr 16 12:40 av.https-ict.nl.OS -rw-r--r-- 1 root = wheel 155692564480 Mar 24 17:42 bestandonline.https-ict.nl.DATA -rw= -r--r-- 1 root wheel 21474836480 Apr 5 12:19 bestandonline.https-i= ct.nl.OS -rw-r--r-- 1 root wheel 107374182400 Apr 16 12:40 crm.f= astbenelux.DATA -rw-r--r-- 1 root wheel 21474836480 Apr 16 12:39= crm.fastbenelux.OS -rw-r--r-- 1 root wheel 1073741824 Apr 5 1= 2:19 default.do.not.remove -rw-r--r-- 1 root wheel 10737418240 = May 12 2011 documentatievm.https-ict.nl -rw-r--r-- 1 root wheel = 429496729600 Apr 15 02:07 mail.https-ict.nl.DATA -rw-r--r-- 1 roo= t wheel 21474836480 Apr 16 12:40 mail.https-ict.nl.OS -rw-r--r-- = 1 root wheel 16106127360 May 16 2011 testvm1.https-ict.nl -rw-r= --r-- 1 root wheel 429496729600 Apr 16 12:40 webserver.https-ict.nl.= DATA -rw-r--r-- 1 root wheel 21474836480 Apr 16 12:40 webserver= .https-ict.nl.OS -rw-r--r-- 1 root wheel 21474836480 Apr 5 12:= 19 webserver2.https-ict.nl.DATA -rw-r--r-- 1 root wheel 21474836= 480 Apr 16 12:40 webserver2.https-ict.nl.OS -rw-r--r-- 1 root whee= l 161061273600 Apr 16 12:40 xlmail.xladsl.nl.DATA -rw-r--r-- 1 ro= ot wheel 21474836480 Apr 16 12:40 xlmail.xladsl.nl.os [root@= storage /storage]# ls -la /storage/.zfs/s*=20 /storage/.zfs/shares:= total 2 dr-xr-xr-x 2 root wheel 2 May 10 2011 . dr-xr-x= r-x 4 root wheel 4 May 10 2011 .. /storage/.zfs/snapsho= t: total 0 dr-xr-xr-x 2 root wheel 2 May 10 2011 . dr-xr= -xr-x 4 root wheel 4 May 10 2011 .. It definitly look= s like the reserved space for the zvols is counted in /storage, but the = written data is counted for /storage as well, instead of the zvols..= Will an upgrade fix this? --=20 Dit bericht is ve= rzonden via https://www.hyperdesktop.nl/. Alles, overal! Mark S= chouten | Tuxis Internet Engineering KvK: 09218193 | http://www.tu= xis.nl/ T: 0318 200208 | info@tuxis.nl M: 06 53463918 | mark@tuxi= s.nl From owner-freebsd-fs@FreeBSD.ORG Mon Apr 16 11:07:17 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C7E7106564A for ; Mon, 16 Apr 2012 11:07:17 +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 253298FC17 for ; Mon, 16 Apr 2012 11:07:17 +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 q3GB7HMX022377 for ; Mon, 16 Apr 2012 11:07:17 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3GB7GAj022375 for freebsd-fs@FreeBSD.org; Mon, 16 Apr 2012 11:07:16 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Apr 2012 11:07:16 GMT Message-Id: <201204161107.q3GB7GAj022375@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, 16 Apr 2012 11:07:17 -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/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166566 fs [zfs] zfs split renders 2 disk (MBR based) mirror unbo o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165923 fs [nfs] Writing to NFS-backed mmapped files fails if flu o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/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/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/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/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/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 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 kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o 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 266 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Apr 16 14:18:03 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5093A106564A; Mon, 16 Apr 2012 14:18:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1F9FC8FC17; Mon, 16 Apr 2012 14:18:03 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 89A52B93B; Mon, 16 Apr 2012 10:18:02 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 16 Apr 2012 09:56:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <4F8999D2.1080902@FreeBSD.org> <4F89B567.6090008@FreeBSD.org> In-Reply-To: <4F89B567.6090008@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204160956.21148.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 16 Apr 2012 10:18:02 -0400 (EDT) Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 14:18:03 -0000 On Saturday, April 14, 2012 1:35:35 pm Andriy Gapon wrote: > on 14/04/2012 18:37 Andriy Gapon said the following: > > > > I would like to ask for a review and/or testing of the following three patches: > > http://people.freebsd.org/~avg/zfsboot.patches.diff > > > > These patches add support for booting from an arbitrary filesystem of any > > detected ZFS pool. A filesystem could be selected in zfsboot and thus will > > affectfrom where zfsloader would be loaded. zfsboot passes information about > > the boot pool and filesystem to zfsloader, which uses those for loaddev and > > default value of currdev. A different pool+filesystem could be selected in > > zfsloader for booting kernel. Also if vfs.root.mountfrom is not explicitly set > > and is not derived from fstab, then it gets set to the selected boot filesystem. > > A note for prospective testers: the patched loader expect to be started by the > patched zfs boot as it passes an additional parameter for a filesystem guid. > I should probably add some way to distinguish between the older and newer zfs > boot blocks. Maybe an extra bit in bootflags? What do you think? An extra bit (similar to existing flags for detecting PXE and CD booting) sounds fine to me. (Note, I'm only replying to the question, have not looked at patches yet). -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Apr 16 18:43:52 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07D30106564A for ; Mon, 16 Apr 2012 18:43:52 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8DF4C8FC08 for ; Mon, 16 Apr 2012 18:43:51 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so5446933wgb.31 for ; Mon, 16 Apr 2012 11:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EnziAQZCoAIkgcR8oL/aZmIp7el6coBQ1UZSPqYjiCU=; b=X5i1qUtgVgwvFFTkYZDVviBC18qdg7MQ5WhFAH+cnoeqRiCJAo0utgf53EHLVqDslk AbSwbFeNbT2CgeCAZFa2I88xpqVvna/J+dSZdsJj3i3rUpYJvLwEw1UYYLsVxuYvGeI2 Z88laVRsngfAkq1Z9J1horgD08+cmsBRhUpxNq5J3Fmc9cJN+0SftNTy0q6xhsXFmF0d PhSqxJSzBcyb5NYlGH2w5lC5yKV+ccEh5OBhljAeN2S7bNPM3/Iwb6XUo+r0kh/3aWJU nssjdzHBtTscROWcoP5F0QQCw/XS7O6A6/ordcP46VKNd7tyVblPiUk2Z5r3FymC2PwJ U/EA== MIME-Version: 1.0 Received: by 10.180.104.137 with SMTP id ge9mr21078425wib.20.1334601830765; Mon, 16 Apr 2012 11:43:50 -0700 (PDT) Received: by 10.180.85.71 with HTTP; Mon, 16 Apr 2012 11:43:50 -0700 (PDT) Date: Mon, 16 Apr 2012 14:43:50 -0400 Message-ID: From: Ryan Stone To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: SU: Could an unclean shutdown cause a file with outstanding writes to become sparse after fsck? 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, 16 Apr 2012 18:43:52 -0000 Today I encountered a system running a very old version of FreeBSD (6.1-ish) that was stuck in a reboot loop. I was eventually able to discover that the system was running into a long-since fixed bug where the system would panic if you tried to execute a sparse file. From what I've been able to get from the owner of this system, it sounds like the machine reset during a system upgrade. I suspect that the initial reset was unrelated (a different long-since fixed panic or a power loss, maybe), and that some executables that had outstanding writes before the reset ended up becoming sparse when fsck was run. Is this possible? The filesystem was running soft-updates, and I'm really not familiar enough with either soft-updates or even the UFS on-disk metadata to say whether this is reasonable. From owner-freebsd-fs@FreeBSD.ORG Mon Apr 16 21:40:11 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B47A31065670 for ; Mon, 16 Apr 2012 21:40:11 +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 746278FC20 for ; Mon, 16 Apr 2012 21:40:11 +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 q3GLUYMG013359; Mon, 16 Apr 2012 14:30:38 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201204162130.q3GLUYMG013359@gw.catspoiler.org> Date: Mon, 16 Apr 2012 14:30:33 -0700 (PDT) From: Don Lewis To: rysto32@gmail.com In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-fs@FreeBSD.org Subject: Re: SU: Could an unclean shutdown cause a file with outstanding writes to become sparse after fsck? 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, 16 Apr 2012 21:40:11 -0000 On 16 Apr, Ryan Stone wrote: > Today I encountered a system running a very old version of FreeBSD > (6.1-ish) that was stuck in a reboot loop. I was eventually able to > discover that the system was running into a long-since fixed bug where > the system would panic if you tried to execute a sparse file. From > what I've been able to get from the owner of this system, it sounds > like the machine reset during a system upgrade. I suspect that the > initial reset was unrelated (a different long-since fixed panic or a > power loss, maybe), and that some executables that had outstanding > writes before the reset ended up becoming sparse when fsck was run. > Is this possible? The filesystem was running soft-updates, and I'm > really not familiar enough with either soft-updates or even the UFS > on-disk metadata to say whether this is reasonable. Yes an unclean shutdown can cause a new file that is being written to become sparse, especially if you are using tagged commands on SCSI or NCQ with SATA and write caching disabled. I've seen it happen. Even if the file is being written sequentially, there is no guarantee that the drive will actually write the data and report the write completions in a sequential manner. With SU, the block pointers for the file won't get written until the drive reports the writes are complete, so if there is an unclean shutdown, some of the block pointers may still be zero, creating a sparse file. At least all of the block pointers that are present will point to valid data. This particular problem would probably not occur if write caching was enabled and the unclean shutdown was caused by a system panic because all of the data would probably be in the drive's write cache and would eventually get written even after the crash. If write caching is enabled, then all bets are off if there is a power failure because the unwritten contents of the drive's write cache would be lost. Some of the file's block pointers could be pointing to random garbage, and there could be unconsistencies that fsck can't automatically fix. This would require a manual fsck and can cause data loss. When install is invoked with the -S flag, it should probably call fsync() on the destination file after it is done writing and before it used rename() to replace the target file. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 02:08:13 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8555106564A; Tue, 17 Apr 2012 02:08:13 +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 BC6E88FC0A; Tue, 17 Apr 2012 02:08: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 q3H28D8C087762; Tue, 17 Apr 2012 02:08:13 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3H28DR7087758; Tue, 17 Apr 2012 02:08:13 GMT (envelope-from linimon) Date: Tue, 17 Apr 2012 02:08:13 GMT Message-Id: <201204170208.q3H28DR7087758@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/166912: [ufs] [panic] Panic after converting Softupdates to journaled softupdates 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, 17 Apr 2012 02:08:14 -0000 Old Synopsis: Panic after converting Softupdates to journaled softupdates New Synopsis: [ufs] [panic] Panic after converting Softupdates to journaled softupdates Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Apr 17 02:07:11 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166912 From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 05:34:34 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 8C2F5106564A; Tue, 17 Apr 2012 05:34:34 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 491898FC14; Tue, 17 Apr 2012 05:34:34 +0000 (UTC) From: vermaden To: avg@FreeBSD.org X-Mailer: interia.pl/pf09 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1334640867; bh=ED4b4S/kxxp/t6m9tNGINRR02Re5Oj4ooRQQOuJv5fI=; h=From:Subject:To:Cc:X-Mailer:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=SmIDbSluF7qxGJWudmmPChoRHqX4BzNOILK0u3SepFUL0zgJHTQcG+l1lehRJdEIx +cA7cKBGFHjYAgv1FZGxths04tj0T6+xXo9U0asqNN3ChztiYwCGnO/hMbCeCKDQ2c v4iU6IyvT2xdI5v/JEDW/GFwSXQ7+Rp5m/CiKMic= Date: Tue, 17 Apr 2012 05:34:34 +0000 (UTC) Cc: freebsd-fs@FreeBSD.org Subject: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 05:34:34 -0000 Hi, You should thought about making it the 'FreeBSD Foundation Project': http://freebsdfoundation.blogspot.co.uk/2012/04/accepting-project-proposals= .html I haven't got time to check this patch, but I would like to suggest these f= eatures: 1. Similar to NEXTBOOT command provide an option to boot some environment O= NE TIME only, if it will hung at any place, upon next reboot it will not be= booted, like ZFSNEXTBOOT for example. 2. Add possibility to move (by zfs send | zfs recv) 'boot environment' from= other server without need to 'rebuild' the zpool.cache. Regards and good luck, vermaden --=20 ... From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 06:32:40 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D9941065672 for ; Tue, 17 Apr 2012 06:32:40 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 15ADB8FC12 for ; Tue, 17 Apr 2012 06:32:39 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so320496wgb.1 for ; Mon, 16 Apr 2012 23:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=eemJHcMwq1i+SpT2qdMNWPEgAgd67KAxxHIF4XL1unM=; b=CYdAmcm3eNUl+mWtblbZIq5V8WVrfsoyZtf565oISi1ttOI+A0SjGcCk5TbWGo3rku Ydl1umXHQyGxWzxv7V+iuawd3+GRGSPsdwSB+JCyrWdPkSVkT3iSjlSwvA2eAeqr0gPG AfLf3lEEOhJ5vxF4BdbiZYrU21PO5OITbxqvwKfPCt/2yHZP3i4JZ9foaslB3Lh9+ycT uajayL6/xGQxn92NKqJsiTvkZ5EPIo7qKMaKb7se1+DKRg0avp24xkuwtbbXnJ9J4CPh 5tzv+mqWH7nPpkNa+Wip4tjPbjlbKfLsuHVsxST9zRAdeGaUHn/fITROrolN9vpT6+jz bwzA== Received: by 10.216.214.84 with SMTP id b62mr8156460wep.20.1334644357769; Mon, 16 Apr 2012 23:32:37 -0700 (PDT) Received: from green.tandem.local (185-104-201-46.pool.ukrtel.net. [46.201.104.185]) by mx.google.com with ESMTPS id ea6sm24748268wib.5.2012.04.16.23.32.34 (version=SSLv3 cipher=OTHER); Mon, 16 Apr 2012 23:32:35 -0700 (PDT) Message-ID: <4F8D0E81.5050703@gmail.com> Date: Tue, 17 Apr 2012 09:32:33 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:11.0) Gecko/20120315 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: Mark Schouten References: <4F88553B.5030005@gmail.com> <1334565339.4f8bd9db1134e@www.hyperdesktop.nl> In-Reply-To: <1334565339.4f8bd9db1134e@www.hyperdesktop.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" Subject: Re: ZFS and disk usage 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, 17 Apr 2012 06:32:40 -0000 Mark Schouten wrote: >> Just curious, what `ls -la /storage/' and `ls -la /storage/.zfs/s*` show? It's plain weird. > > [root@storage ~]# zfs list -o name,used,referenced,usedbychildren,usedbydataset,usedbysnapshots,available,mountpoint,quota,reserv,refquota,refreserv "$@" | sed -r "s/none/ -/g" > NAME USED REFER USEDCHILD USEDDS USEDSNAP AVAIL MOUNTPOINT QUOTA RESERV REFQUOTA REFRESERV > storage 1.60T 431G 1.18T 431G 0 138G /storage - - - - > storage/av.https-ict.nl..OS 20G 16K 0 16K 0 158G - - - - 20G > storage/bestandonline.https-ict.nl.OS 20G 16K 0 16K 0 158G - - - - 20G Let's take this one for example. It's not mounted! It shouldn't be listed in next command output. > storage/crm.fastbenelux.DATA 100G 16K 0 16K 0 238G - - - - 100G > storage/crm.fastbenelux.OS 20G 16K 0 16K 0 158G - - - - 20G > storage/default.do.not.remove 1G 16K 0 16K 0 139G - - - - 1G > storage/mail.https-ict.nl.DATA 400G 16K 0 16K 0 538G - - - - 400G > storage/mail.https-ict.nl.OS 20G 16K 0 16K 0 158G - - - - 20G > storage/webserver.https-ict.nl.DATA 400G 16K 0 16K 0 538G - - - - 400G > storage/webserver.https-ict.nl.OS 20G 16K 0 16K 0 158G - - - - 20G > storage/webserver2.https-ict.nl.DATA 20G 16K 0 16K 0 158G - - - - 20G > storage/webserver2.https-ict.nl.OS 20G 16K 0 16K 0 158G - - - - 20G > storage/xlmail.xladsl.nl.DATA 150G 16K 0 16K 0 288G - - - - 150G > storage/xlmail.xladsl.nl.os 20G 16K 0 16K 0 158G - - - - 20G > > [root@storage /storage]# ls -al > total 452101743 > drwxr-xr-x 2 root wheel 18 Mar 24 17:42 . > drwxr-xr-x 20 root wheel 512 May 10 2011 .. > -rw-r--r-- 1 root wheel 21474836480 Apr 16 12:40 av.https-ict.nl.OS > -rw-r--r-- 1 root wheel 155692564480 Mar 24 17:42 bestandonline.https-ict.nl.DATA > -rw-r--r-- 1 root wheel 21474836480 Apr 5 12:19 bestandonline.https-ict.nl.OS This is not a zfs dataset. This is a file. It has no relevance to named dataset. And it drains space from /storage. > -rw-r--r-- 1 root wheel 107374182400 Apr 16 12:40 crm.fastbenelux.DATA > -rw-r--r-- 1 root wheel 21474836480 Apr 16 12:39 crm.fastbenelux.OS > -rw-r--r-- 1 root wheel 1073741824 Apr 5 12:19 default.do.not.remove > -rw-r--r-- 1 root wheel 10737418240 May 12 2011 documentatievm.https-ict.nl > -rw-r--r-- 1 root wheel 429496729600 Apr 15 02:07 mail.https-ict.nl.DATA > -rw-r--r-- 1 root wheel 21474836480 Apr 16 12:40 mail.https-ict.nl.OS > -rw-r--r-- 1 root wheel 16106127360 May 16 2011 testvm1.https-ict.nl > -rw-r--r-- 1 root wheel 429496729600 Apr 16 12:40 webserver.https-ict.nl.DATA > -rw-r--r-- 1 root wheel 21474836480 Apr 16 12:40 webserver..https-ict.nl.OS > -rw-r--r-- 1 root wheel 21474836480 Apr 5 12:19 webserver2.https-ict.nl.DATA > -rw-r--r-- 1 root wheel 21474836480 Apr 16 12:40 webserver2.https-ict.nl.OS > -rw-r--r-- 1 root wheel 161061273600 Apr 16 12:40 xlmail.xladsl.nl.DATA > -rw-r--r-- 1 root wheel 21474836480 Apr 16 12:40 xlmail.xladsl.nl.os > > [root@storage /storage]# ls -la /storage/.zfs/s* > /storage/.zfs/shares: > total 2 > dr-xr-xr-x 2 root wheel 2 May 10 2011 . > dr-xr-xr-x 4 root wheel 4 May 10 2011 .. > > /storage/.zfs/snapshot: > total 0 > dr-xr-xr-x 2 root wheel 2 May 10 2011 . > dr-xr-xr-x 4 root wheel 4 May 10 2011 .. There's also another discrepancies in your output like: * "av.https-ict.nl..OS" != "av.https-ict.nl.OS", seems like copy-and-paste error(?); * "bestandonline.https-ict.nl.DATA" and "documentatievm.https-ict.nl" doesn't exist in datasets, it looks like correspondent datasets were already removed, but not files. > It definitly looks like the reserved space for the zvols is counted in /storage, but the written data is counted for /storage as well, instead of the zvols.. > > Will an upgrade fix this? > -- Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 08:37:06 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8ABB106566C for ; Tue, 17 Apr 2012 08:37:06 +0000 (UTC) (envelope-from mark@tuxis.nl) Received: from smtp.tuxis.nl (smtp.tuxis.nl [IPv6:2a03:7900:2:0:31:3:104:34]) by mx1.freebsd.org (Postfix) with ESMTP id 4DEBF8FC18 for ; Tue, 17 Apr 2012 08:37:06 +0000 (UTC) Received: from [2a03:7900:2:0:31:3:104:46] (port=45404 helo=go.tuxis.net) by smtp.tuxis.nl with esmtp (Exim 4.71) (envelope-from ) id 1SK3uL-0006Bc-CX for freebsd-fs@freebsd.org; Tue, 17 Apr 2012 10:37:05 +0200 Received: from localhost (localhost [127.0.0.1]) by go.tuxis.net (Postfix) with ESMTP id 14C9220B5A for ; Tue, 17 Apr 2012 10:37:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at www.hyperdesktop.nl Received: from go.tuxis.net ([127.0.0.1]) by localhost (go.tuxis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRnnGXId3wrq for ; Tue, 17 Apr 2012 10:37:28 +0200 (CEST) Received: from www.hyperdesktop.nl (unknown [IPv6:::1]) by go.tuxis.net (Postfix) with ESMTP id B40F320B5D for ; Tue, 17 Apr 2012 10:37:28 +0200 (CEST) Message-ID: <1334651848.4f8d2bc88c939@www.hyperdesktop.nl> Date: Tue, 17 Apr 2012 10:37:28 +0200 From: Mark Schouten To: Volodymyr Kostyrko MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced by Group-Office 3.7.42 In-Reply-To: <4F8D0E81.5050703@gmail.com> References: <4F8D0E81.5050703@gmail.com> X-Mailer: Group-Office 3.7.42 X-Priority: 3 (Normal) Cc: "freebsd-fs@freebsd.org" Subject: Re: ZFS and disk usage 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, 17 Apr 2012 08:37:06 -0000 Hi, Op Dinsdag, 17-04-2012 om 8:32 schreef Volodymyr Kostyrko= : > > [root@storage ~]# zfs list -o name,used,referenced,usedbychild= ren,usedbydataset,usedbysnapshots,available,mountpoint,quota,reserv,refq= uota,refreserv "$@" | sed -r "s/none/ -/g" > > NAME = USED REFER USEDCHILD USEDDS USEDSNAP AVAIL MO= UNTPOINT QUOTA RESERV REFQUOTA REFRESERV > > storage = 1.60T 431G 1.18T 431G 0 138G /s= torage - - - - > > storage/av.https-ic= t.nl..OS 20G 16K 0 16K 0 158G -= - - - 20G > > storage/bestandonl= ine.https-ict.nl.OS 20G 16K 0 16K 0 158G -= - - - 20G >=20 > Let's take th= is one for example. It's not mounted! It shouldn't be=20 > listed in n= ext command output. They are zvols, they shouldn't be mounted= . They're exported by iscsitgt as devices. > This is not a zfs d= ataset. This is a file. It has no relevance to named=20 > dataset. And= it drains space from /storage. That's absolutely true. There= are indeed three files that could be removed. bestandonline.https-i= ct.nl.DATA documentatievm.https-ict.nl testvm1.https-ict= .nl But still, there is only 16K referenced by the zvols.= .. --=20 Dit bericht is verzonden via https://www.hyperdes= ktop.nl/. Alles, overal! Mark Schouten | Tuxis Internet Engine= ering KvK: 09218193 | http://www.tuxis.nl/ T: 0318 200208 | info= @tuxis.nl M: 06 53463918 | mark@tuxis.nl From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 09:46:58 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 122C0106566B; Tue, 17 Apr 2012 09:46:58 +0000 (UTC) (envelope-from kevlo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D95B68FC08; Tue, 17 Apr 2012 09:46:57 +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 q3H9kvaX049095; Tue, 17 Apr 2012 09:46:57 GMT (envelope-from kevlo@freefall.freebsd.org) Received: (from kevlo@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3H9kveD049090; Tue, 17 Apr 2012 09:46:57 GMT (envelope-from kevlo) Date: Tue, 17 Apr 2012 09:46:57 GMT Message-Id: <201204170946.q3H9kveD049090@freefall.freebsd.org> To: ggg_mail@inbox.ru, kevlo@FreeBSD.org, freebsd-fs@FreeBSD.org From: kevlo@FreeBSD.org Cc: Subject: Re: kern/109024: [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operation not permitted 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, 17 Apr 2012 09:46:58 -0000 Synopsis: [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operation not permitted State-Changed-From-To: open->closed State-Changed-By: kevlo State-Changed-When: Tue Apr 17 09:45:06 UTC 2012 State-Changed-Why: I believe that with recent HEAD and releases of 8 and 9 that this is no longer true. http://www.freebsd.org/cgi/query-pr.cgi?pr=109024 From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 09:55:13 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31C531065672 for ; Tue, 17 Apr 2012 09:55:13 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AE6788FC12 for ; Tue, 17 Apr 2012 09:55:12 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so6050602bkc.13 for ; Tue, 17 Apr 2012 02:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rEyOJm8KB4issMrMxtfGjEonTIByIFM+Pdi+B93s+5M=; b=HEaklc40/PZClnNxe7IZ+HaxC1j/QNAu1cfFxZww03YsTey7+UK1CqmGXpT2+uK4iC NpQkJUQN2bEvvGKuDCbtqtJ1FXEKYq1TY0L53tINixIJyyXpbX3kOTJtj0NK4CWntKTD oHEv2ZYf63lFRnE2wxCPYFIKDRGUdQBZuUrmiLF86dG6xuQdTM+3FKZ/x2RjpOqWJyzn iqmJA1BSajPGQi1lJb7gAb/uH7WaU0J0ppjPQJDn8DvIIVTvJ2UGqDV1ggebarEnOyfU X6G0MNpDnbB/kzY7fO18/orpmLBBji9b9JCiJ/d2SNWKkbMLiGjavudr0RW96l/Qg4PF dIPQ== Received: by 10.205.130.133 with SMTP id hm5mr4354920bkc.115.1334656511488; Tue, 17 Apr 2012 02:55:11 -0700 (PDT) Received: from green.tandem.local (102-204-132-95.pool.ukrtel.net. [95.132.204.102]) by mx.google.com with ESMTPS id iv11sm36663005bkc.16.2012.04.17.02.55.09 (version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 02:55:10 -0700 (PDT) Message-ID: <4F8D3DFB.4050304@gmail.com> Date: Tue, 17 Apr 2012 12:55:07 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:11.0) Gecko/20120315 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: Mark Schouten References: <4F8D0E81.5050703@gmail.com> <1334651848.4f8d2bc88c939@www.hyperdesktop.nl> In-Reply-To: <1334651848.4f8d2bc88c939@www.hyperdesktop.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" Subject: Re: ZFS and disk usage 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, 17 Apr 2012 09:55:13 -0000 Mark Schouten wrote: >>> [root@storage ~]# zfs list -o name,used,referenced,usedbychildren,usedbydataset,usedbysnapshots,available,mountpoint,quota,reserv,refquota,refreserv "$@" | sed -r "s/none/ -/g" >>> NAME USED REFER USEDCHILD USEDDS USEDSNAP AVAIL MOUNTPOINT QUOTA RESERV REFQUOTA REFRESERV >>> storage 1.60T 431G 1.18T 431G 0 138G /storage - - - - >>> storage/av.https-ict.nl..OS 20G 16K 0 16K 0 158G - - - - 20G >>> storage/bestandonline.https-ict.nl.OS 20G 16K 0 16K 0 158G - - - - 20G >> >> Let's take this one for example. It's not mounted! It shouldn't be >> listed in next command output. > > They are zvols, they shouldn't be mounted. They're exported by iscsitgt as devices. As they are zvols they do exists at /dev/zvol/storage/ and not /storage/. Where did all that files came from? Can you post your iscsitgt setup? > >> This is not a zfs dataset. This is a file. It has no relevance to named >> dataset. And it drains space from /storage. > > That's absolutely true. There are indeed three files that could be removed. > bestandonline.https-ict.nl.DATA > documentatievm.https-ict.nl > testvm1.https-ict.nl > > But still, there is only 16K referenced by the zvols... > -- Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 09:59:39 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6B191065670; Tue, 17 Apr 2012 09:59:39 +0000 (UTC) (envelope-from kevlo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9A6368FC12; Tue, 17 Apr 2012 09:59:39 +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 q3H9xdV5057841; Tue, 17 Apr 2012 09:59:39 GMT (envelope-from kevlo@freefall.freebsd.org) Received: (from kevlo@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3H9xcLA057837; Tue, 17 Apr 2012 09:59:38 GMT (envelope-from kevlo) Date: Tue, 17 Apr 2012 09:59:38 GMT Message-Id: <201204170959.q3H9xcLA057837@freefall.freebsd.org> To: 0034058@fudan.edu.cn, kevlo@FreeBSD.org, freebsd-fs@FreeBSD.org From: kevlo@FreeBSD.org Cc: Subject: Re: kern/109010: [msdosfs] can't mv directory within fat32 file system X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 09:59:39 -0000 Synopsis: [msdosfs] can't mv directory within fat32 file system State-Changed-From-To: open->closed State-Changed-By: kevlo State-Changed-When: Tue Apr 17 09:59:03 UTC 2012 State-Changed-Why: I cannot reproduce this issue on FreeBSD 7/8/9. http://www.freebsd.org/cgi/query-pr.cgi?pr=109010 From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 10:02:10 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10AB9106566B for ; Tue, 17 Apr 2012 10:02:10 +0000 (UTC) (envelope-from mark@tuxis.nl) Received: from smtp.tuxis.nl (smtp.tuxis.nl [IPv6:2a03:7900:2:0:31:3:104:34]) by mx1.freebsd.org (Postfix) with ESMTP id 99DB18FC0C for ; Tue, 17 Apr 2012 10:02:09 +0000 (UTC) Received: from [2a03:7900:2:0:31:3:104:46] (port=45609 helo=go.tuxis.net) by smtp.tuxis.nl with esmtp (Exim 4.71) (envelope-from ) id 1SK5Ef-0006Uh-1Y for freebsd-fs@freebsd.org; Tue, 17 Apr 2012 12:02:09 +0200 Received: from localhost (localhost [127.0.0.1]) by go.tuxis.net (Postfix) with ESMTP id 82C0720BF0 for ; Tue, 17 Apr 2012 12:02:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at www.hyperdesktop.nl Received: from go.tuxis.net ([127.0.0.1]) by localhost (go.tuxis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mShaoU8RwfHT for ; Tue, 17 Apr 2012 12:02:28 +0200 (CEST) Received: from www.hyperdesktop.nl (unknown [IPv6:::1]) by go.tuxis.net (Postfix) with ESMTP id 2EC1D20BEF for ; Tue, 17 Apr 2012 12:02:28 +0200 (CEST) Message-ID: <1334656948.4f8d3fb411797@www.hyperdesktop.nl> Date: Tue, 17 Apr 2012 12:02:28 +0200 From: Mark Schouten To: Volodymyr Kostyrko MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced by Group-Office 3.7.42 In-Reply-To: <4F8D3DFB.4050304@gmail.com> References: <4F8D3DFB.4050304@gmail.com> X-Mailer: Group-Office 3.7.42 X-Priority: 3 (Normal) Cc: "freebsd-fs@freebsd.org" Subject: Re: ZFS and disk usage 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, 17 Apr 2012 10:02:10 -0000 Hi, Op Dinsdag, 17-04-2012 om 11:55 schreef Volodymyr Kostyrk= o: > As they are zvols they do exists at /dev/zvol/storage/ and not = > /storage/. Where did all that files came from? >=20 > Can y= ou post your iscsitgt setup? Ok, so now I feel like an ass. :) = I followed this [1] link to setup this box. But I understand that I'm do= ing that all wrong? istgt.conf has the lun's defined like thi= s: LUN0 Storage /storage/default.do.not.remove 1GB LUN1 Stor= age /storage/mail.https-ict.nl.OS 20GB LUN2 Storage /storage/mail.= https-ict.nl.DATA 400GB That should point to the /dev/zvol/st= orage/ devices? [1]: http://www.techjolts.com/2011/01/14/iscs= i-target-with-zfs-freebsd/ --=20 Dit bericht is verzonden = via https://www.hyperdesktop.nl/. Alles, overal! Mark Schouten = | Tuxis Internet Engineering KvK: 09218193 | http://www.tuxis.= nl/ T: 0318 200208 | info@tuxis.nl M: 06 53463918 | mark@tuxis.nl From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 10:11:31 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 770EF1065670 for ; Tue, 17 Apr 2012 10:11:31 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id F27008FC14 for ; Tue, 17 Apr 2012 10:11:30 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so6067492bkc.13 for ; Tue, 17 Apr 2012 03:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6LY/Lipz0vgAtz2tBQ4tX3EpfBTVm0/AnIuod69VHxc=; b=jF7jfgyg/7Gd0mutmvjZ7bm+Zrb/yge61uiD2X6yBxm74ZYnyL0FPUWoe7MUsWC3QD U0KMCPRUm33gU+BPj+/VTxakOwA7UzIFiIQnXa/D7rrnmwIKzQmzysnoW9nXKwPzTs6V cPRmRX87BZhqdNTlecKFswTECfkeR3Qq6RMZVr5I+d4RsefjBOn3/UivOCTpv7HlVAxQ ExWlXbrLLe7SVMr3jz08TVQUeMcVb7/IiN1oRxq1xXb3W1eZ0+RqXLzQf3tZqcC6PgBs ACioRAjT9HzKJwMICifIf6N+H9RhcMnno6RYoUt78EfmJmvbsk8IJP36hZTXdi1iG3+/ //NQ== Received: by 10.205.117.15 with SMTP id fk15mr4457979bkc.133.1334657490040; Tue, 17 Apr 2012 03:11:30 -0700 (PDT) Received: from green.tandem.local (102-204-132-95.pool.ukrtel.net. [95.132.204.102]) by mx.google.com with ESMTPS id z17sm36776929bkw.12.2012.04.17.03.11.25 (version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 03:11:28 -0700 (PDT) Message-ID: <4F8D41CA.8020506@gmail.com> Date: Tue, 17 Apr 2012 13:11:22 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:11.0) Gecko/20120315 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: Mark Schouten References: <4F8D3DFB.4050304@gmail.com> <1334656948.4f8d3fb411797@www.hyperdesktop.nl> In-Reply-To: <1334656948.4f8d3fb411797@www.hyperdesktop.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" Subject: Re: ZFS and disk usage 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, 17 Apr 2012 10:11:31 -0000 Mark Schouten wrote: > Hi, > > Op Dinsdag, 17-04-2012 om 11:55 schreef Volodymyr Kostyrko: >> As they are zvols they do exists at /dev/zvol/storage/ and not >> /storage/. Where did all that files came from? >> >> Can you post your iscsitgt setup? > > Ok, so now I feel like an ass. :) I followed this [1] link to setup this box. But I understand that I'm doing that all wrong? > > istgt.conf has the lun's defined like this: > LUN0 Storage /storage/default.do.not.remove 1GB > LUN1 Storage /storage/mail.https-ict.nl.OS 20GB > LUN2 Storage /storage/mail.https-ict.nl.DATA 400GB > > That should point to the /dev/zvol/storage/ devices? > > [1]: http://www.techjolts.com/2011/01/14/iscsi-target-with-zfs-freebsd/ As I never worked with istgt myself I can't really say, but yes this somehow feels wrong to me. As all your data could be potentially stored in raw files let's test it another way. Could you create another zfs volume/istgt target and point it at /dev/zvol/storage/new_volume? 1. Would access to this new device work? 2. Would some new file be created? 3. Would some data be accounted to new_volume? -- Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 10:22:41 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED9F3106564A for ; Tue, 17 Apr 2012 10:22:41 +0000 (UTC) (envelope-from mark@tuxis.nl) Received: from smtp.tuxis.nl (smtp.tuxis.nl [IPv6:2a03:7900:2:0:31:3:104:34]) by mx1.freebsd.org (Postfix) with ESMTP id 819128FC0A for ; Tue, 17 Apr 2012 10:22:41 +0000 (UTC) Received: from [2a03:7900:2:0:31:3:104:46] (port=45704 helo=go.tuxis.net) by smtp.tuxis.nl with esmtp (Exim 4.71) (envelope-from ) id 1SK5YW-0006Ze-Uf for freebsd-fs@freebsd.org; Tue, 17 Apr 2012 12:22:40 +0200 Received: from localhost (localhost [127.0.0.1]) by go.tuxis.net (Postfix) with ESMTP id 7756820A81 for ; Tue, 17 Apr 2012 12:23:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at www.hyperdesktop.nl Received: from go.tuxis.net ([127.0.0.1]) by localhost (go.tuxis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz+a8tNY8lYo for ; Tue, 17 Apr 2012 12:23:04 +0200 (CEST) Received: from www.hyperdesktop.nl (unknown [IPv6:::1]) by go.tuxis.net (Postfix) with ESMTP id E5C2E20A62 for ; Tue, 17 Apr 2012 12:23:03 +0200 (CEST) Message-ID: <1334658183.4f8d4487c729f@www.hyperdesktop.nl> Date: Tue, 17 Apr 2012 12:23:03 +0200 From: Mark Schouten To: Volodymyr Kostyrko MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced by Group-Office 3.7.42 In-Reply-To: <4F8D41CA.8020506@gmail.com> References: <4F8D41CA.8020506@gmail.com> X-Mailer: Group-Office 3.7.42 X-Priority: 3 (Normal) Cc: "freebsd-fs@freebsd.org" Subject: Re: ZFS and disk usage 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, 17 Apr 2012 10:22:42 -0000 Hi, Op Dinsdag, 17-04-2012 om 12:11 schreef Volodymyr Kostyrk= o: > As I never worked with istgt myself I can't really say, but yes= this=20 > somehow feels wrong to me. Can someone confirm t= hat I'm stupid? :P > As all your data could be potentially store= d in raw files let's test it=20 > another way. Could you create anothe= r zfs volume/istgt target and point=20 > it at /dev/zvol/storage/new_v= olume? >=20 > 1. Would access to this new device work? > 2= . Would some new file be created? > 3. Would some data be accounte= d to new_volume? The box is running a production environment no= w, so I can't really fool around with it. It will be migrated soon thoug= h, which will give me some time to experiment. Thanks a bunch fo= r the help! --=20 Dit bericht is verzonden via https://www.= hyperdesktop.nl/. Alles, overal! Mark Schouten | Tuxis Interne= t Engineering KvK: 09218193 | http://www.tuxis.nl/ T: 0318 20020= 8 | info@tuxis.nl M: 06 53463918 | mark@tuxis.nl From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 13:17:39 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 8A358106566C for ; Tue, 17 Apr 2012 13:17:39 +0000 (UTC) (envelope-from zlatko.asenov@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 113268FC08 for ; Tue, 17 Apr 2012 13:17:38 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so6271205bkc.13 for ; Tue, 17 Apr 2012 06:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=nt219akUN39GT3rFKjtiFxZtOOeAdYSqbGAZCYFxLj0=; b=AVzAae9rEUOmqUmX/BfoVPQWSWKUXA6fRG3os0B9O4ovlEkgERLijndbdQuB6jDNep KuPT4TjLC9qxgiSp3HDeKnd4M7VwANCfNVayFOdIGS37Vta+NvSo5lKbbTlIJBYZETiZ lh/Cl3DgExZxCee4SHkdVBJRVvmZ0doc/Ahqf3GsjwevcvU2MX6QsLYHsAdy0lFSanpW 0EMDzcVvBn80X7daW3Bwo7c5vawciu+3eL4TnkG+38KR2sSiJ9GTq6Op4QjXgtfpNRKM AaLZLy8p/svx+oyNpaOD8mS5gXcccFiMPL/DFIsed2ekiDgtB0V+Cp3zrnA+9ToqFpmu x3vQ== Received: by 10.204.129.21 with SMTP id m21mr4817221bks.124.1334668657810; Tue, 17 Apr 2012 06:17:37 -0700 (PDT) Received: from zlatko.pc (office.spnet.net. [212.50.0.66]) by mx.google.com with ESMTPS id jr13sm37916779bkb.14.2012.04.17.06.17.35 (version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 06:17:36 -0700 (PDT) Message-ID: <4F8D6D68.50702@gmail.com> Date: Tue, 17 Apr 2012 16:17:28 +0300 From: Zlatko Asenov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120330 Thunderbird/10.0.3 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: "ZFS: zfs_alloc()/zfs_free() mismatch" Problem with 8.2 Stable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 13:17:39 -0000 Hello everyone, I had set up a raidz2 ZFS on ROOT system with 4 SATA disks. Every disk had 64k freebsd-boot, 30G freebsd-zfs and freebsd-ufs for the rest space. I did it with the gpart utility. One of the disks failed and I offlined the faulty 30G partition from the pool. The system worked with "no known data errors". After reboot I saw this message: "ZFS: zfs_alloc()/zfs_free() mismatch" and the system goes no further. I booted with FreeBSD 9.0-RELEASE usb stick, imported the pool which did scrub by himself somehow. After the scrubbing finished all seemed ok, but after reboot I see the message again. The system was FreeBSD 8.2-STABLE AMD64 with 4GB RAM. Interesting to note is that this is my second issue with a faulted disk. However if I replace healthy HDD for upgrading purposes, everything passes fluently. I pulled the data from /usr/home/ however part of it was damaged. I also posted about the issue here: http://forums.freebsd.org/showthread.php?t=31215 What can I do to prevent such a malfunction in future? Best Regards! Zlatko Asenov From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 16:32:47 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 9AE77106564A; Tue, 17 Apr 2012 16:32:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 71A8B8FC12; Tue, 17 Apr 2012 16:32:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DC217B94D; Tue, 17 Apr 2012 12:32:46 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Tue, 17 Apr 2012 11:12:17 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <20120415110807.GA75306@freebsd.org> In-Reply-To: <20120415110807.GA75306@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201204171112.17613.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 17 Apr 2012 12:32:47 -0400 (EDT) Cc: Alexander Best Subject: Re: fixing a hackish comment in ata-raid.c 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, 17 Apr 2012 16:32:47 -0000 On Sunday, April 15, 2012 7:08:08 am Alexander Best wrote: > hi there, > > clang complains about this rather ugly way of putting a comment into normal > code: > > if ((vdcr == NULL) /* && (sa == NULL) * Spares not supported yet */) { > > could somebody please commit the following (or a similar) patch? I think this is probably not worth fixing since ata-raid is due to be replaced by graid. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 20:22:30 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 575B8106566B; Tue, 17 Apr 2012 20:22:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3FA208FC1B; Tue, 17 Apr 2012 20:22:29 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA01638; Tue, 17 Apr 2012 23:22:21 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SKEur-000IdG-1A; Tue, 17 Apr 2012 23:22:21 +0300 Message-ID: <4F8DD0FB.7000907@FreeBSD.org> Date: Tue, 17 Apr 2012 23:22:19 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: John Baldwin References: <4F8999D2.1080902@FreeBSD.org> <4F89B567.6090008@FreeBSD.org> <201204160956.21148.jhb@freebsd.org> In-Reply-To: <201204160956.21148.jhb@freebsd.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 20:22:30 -0000 on 16/04/2012 16:56 John Baldwin said the following: > On Saturday, April 14, 2012 1:35:35 pm Andriy Gapon wrote: >> on 14/04/2012 18:37 Andriy Gapon said the following: >>> >>> I would like to ask for a review and/or testing of the following three patches: >>> http://people.freebsd.org/~avg/zfsboot.patches.diff >>> >>> These patches add support for booting from an arbitrary filesystem of any >>> detected ZFS pool. A filesystem could be selected in zfsboot and thus will >>> affectfrom where zfsloader would be loaded. zfsboot passes information about >>> the boot pool and filesystem to zfsloader, which uses those for loaddev and >>> default value of currdev. A different pool+filesystem could be selected in >>> zfsloader for booting kernel. Also if vfs.root.mountfrom is not explicitly set >>> and is not derived from fstab, then it gets set to the selected boot filesystem. >> >> A note for prospective testers: the patched loader expect to be started by the >> patched zfs boot as it passes an additional parameter for a filesystem guid. >> I should probably add some way to distinguish between the older and newer zfs >> boot blocks. Maybe an extra bit in bootflags? What do you think? > > An extra bit (similar to existing flags for detecting PXE and CD booting) > sounds fine to me. (Note, I'm only replying to the question, have not looked > at patches yet). I hope that you will :-) We already have a flag for ZFS (KARGS_FLAGS_ZFS, 0x4). So the new flag could be named something ZFS-specific (as silly as KARGS_FLAGS_ZFS2) or something more general such as KARGS_FLAGS_32_BYTES meaning that the total size of arguments area is 32 bytes (as opposed to 24 previously). -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Apr 17 21:28: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 764AD1065672; Tue, 17 Apr 2012 21:28:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA078FC1B; Tue, 17 Apr 2012 21:28:55 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B323AB958; Tue, 17 Apr 2012 17:28:54 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Tue, 17 Apr 2012 16:43:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4F8999D2.1080902@FreeBSD.org> <201204160956.21148.jhb@freebsd.org> <4F8DD0FB.7000907@FreeBSD.org> In-Reply-To: <4F8DD0FB.7000907@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204171643.39447.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 17 Apr 2012 17:28:54 -0400 (EDT) Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 21:28:55 -0000 On Tuesday, April 17, 2012 4:22:19 pm Andriy Gapon wrote: > on 16/04/2012 16:56 John Baldwin said the following: > > On Saturday, April 14, 2012 1:35:35 pm Andriy Gapon wrote: > >> on 14/04/2012 18:37 Andriy Gapon said the following: > >>> > >>> I would like to ask for a review and/or testing of the following three patches: > >>> http://people.freebsd.org/~avg/zfsboot.patches.diff > >>> > >>> These patches add support for booting from an arbitrary filesystem of any > >>> detected ZFS pool. A filesystem could be selected in zfsboot and thus will > >>> affectfrom where zfsloader would be loaded. zfsboot passes information about > >>> the boot pool and filesystem to zfsloader, which uses those for loaddev and > >>> default value of currdev. A different pool+filesystem could be selected in > >>> zfsloader for booting kernel. Also if vfs.root.mountfrom is not explicitly set > >>> and is not derived from fstab, then it gets set to the selected boot filesystem. > >> > >> A note for prospective testers: the patched loader expect to be started by the > >> patched zfs boot as it passes an additional parameter for a filesystem guid. > >> I should probably add some way to distinguish between the older and newer zfs > >> boot blocks. Maybe an extra bit in bootflags? What do you think? > > > > An extra bit (similar to existing flags for detecting PXE and CD booting) > > sounds fine to me. (Note, I'm only replying to the question, have not looked > > at patches yet). > > I hope that you will :-) > > We already have a flag for ZFS (KARGS_FLAGS_ZFS, 0x4). So the new flag could be > named something ZFS-specific (as silly as KARGS_FLAGS_ZFS2) or something more > general such as KARGS_FLAGS_32_BYTES meaning that the total size of arguments > area is 32 bytes (as opposed to 24 previously). Does KARGS_FLAGS_GUID work? -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 06:02:25 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3DC02106566C; Wed, 18 Apr 2012 06:02:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2038C8FC08; Wed, 18 Apr 2012 06:02:23 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA07262; Wed, 18 Apr 2012 09:02:22 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SKNyA-000Lme-Iz; Wed, 18 Apr 2012 09:02:22 +0300 Message-ID: <4F8E58EE.8080909@FreeBSD.org> Date: Wed, 18 Apr 2012 09:02:22 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: John Baldwin References: <4F8999D2.1080902@FreeBSD.org> <201204160956.21148.jhb@freebsd.org> <4F8DD0FB.7000907@FreeBSD.org> <201204171643.39447.jhb@freebsd.org> In-Reply-To: <201204171643.39447.jhb@freebsd.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 06:02:25 -0000 on 17/04/2012 23:43 John Baldwin said the following: > On Tuesday, April 17, 2012 4:22:19 pm Andriy Gapon wrote: >> We already have a flag for ZFS (KARGS_FLAGS_ZFS, 0x4). So the new flag could be >> named something ZFS-specific (as silly as KARGS_FLAGS_ZFS2) or something more >> general such as KARGS_FLAGS_32_BYTES meaning that the total size of arguments >> area is 32 bytes (as opposed to 24 previously). > > Does KARGS_FLAGS_GUID work? > I think that's too terse, we already passed a pool guid via the existing argument space. So it should be something like KARGS_FLAGS_ZFS_FS_GUID or KARGS_FLAGS_ZFS_DS_GUID (DS - dataset). -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 08:57:51 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 DDE73106566C; Wed, 18 Apr 2012 08:57:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 042928FC14; Wed, 18 Apr 2012 08:57:50 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA08986; Wed, 18 Apr 2012 11:57:49 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SKQhx-000Lz9-82; Wed, 18 Apr 2012 11:57:49 +0300 Message-ID: <4F8E820B.6080400@FreeBSD.org> Date: Wed, 18 Apr 2012 11:57:47 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, freebsd-fs@FreeBSD.org References: <4F8999D2.1080902@FreeBSD.org> In-Reply-To: <4F8999D2.1080902@FreeBSD.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 08:57:52 -0000 on 14/04/2012 18:37 Andriy Gapon said the following: > > I would like to ask for a review and/or testing of the following three patches: > http://people.freebsd.org/~avg/zfsboot.patches.diff I've put a new version of the patch here: http://people.freebsd.org/~avg/zfsboot.patches.2.diff Most prominent changes: - new zfsloader should be compatible with previous zfsboot - libi386 unconditionally includes zfs support via use of weak symbols for some functions Unfortunately, unconditional compatibility between i386_devdesc and zfs_devdesc means that i386_devdesc becomes much larger (> 512 bytes). But I think that it shouldn't cause any real problems. > These patches add support for booting from an arbitrary filesystem of any > detected ZFS pool. A filesystem could be selected in zfsboot and thus will > affectfrom where zfsloader would be loaded. zfsboot passes information about > the boot pool and filesystem to zfsloader, which uses those for loaddev and > default value of currdev. A different pool+filesystem could be selected in > zfsloader for booting kernel. Also if vfs.root.mountfrom is not explicitly set > and is not derived from fstab, then it gets set to the selected boot filesystem. > > This should could be used as a foundation for the support of Solaris-like boot > environment selection. I believe that other people have already developed > scripts utilizing ZFS capabilities to provide other aspects of management of > boot environments. > > I am particularly interested in reviews of my attempt to make ZFS boot support > arch-independent. The arches, of course, would have to add some code to make > use of that support. Currently I only enabled it for x86. > > Thank you very much! -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 09:18:57 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 82C83106564A; Wed, 18 Apr 2012 09:18:57 +0000 (UTC) (envelope-from araujo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 568B38FC15; Wed, 18 Apr 2012 09:18:57 +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 q3I9IvrJ010067; Wed, 18 Apr 2012 09:18:57 GMT (envelope-from araujo@freefall.freebsd.org) Received: (from araujo@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3I9Iv47010063; Wed, 18 Apr 2012 09:18:57 GMT (envelope-from araujo) Date: Wed, 18 Apr 2012 09:18:57 GMT Message-Id: <201204180918.q3I9Iv47010063@freefall.freebsd.org> To: araujo@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: araujo@FreeBSD.org Cc: Subject: Re: kern/167047: RELEASE-9 crash when using ZFS+NULLFS+NFS 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, 18 Apr 2012 09:18:57 -0000 Synopsis: RELEASE-9 crash when using ZFS+NULLFS+NFS Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: araujo Responsible-Changed-When: Wed Apr 18 09:18:56 UTC 2012 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=167047 From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 09:19:09 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE8561065708; Wed, 18 Apr 2012 09:19:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E58008FC16; Wed, 18 Apr 2012 09:19:08 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA09311; Wed, 18 Apr 2012 12:19:03 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SKR2U-000M11-N6; Wed, 18 Apr 2012 12:19:02 +0300 Message-ID: <4F8E8705.4080804@FreeBSD.org> Date: Wed, 18 Apr 2012 12:19:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: Bob Friesenhahn References: <4F8999D2.1080902@FreeBSD.org> <4F89B567.6090008@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 09:19:09 -0000 on 15/04/2012 04:01 Bob Friesenhahn said the following: > It would be nice if the updated FreeBSD bootloader could have the ability to > boot both Solaris and FreeBSD root filesystems in the same pool so that one > could switch between several zfs-based operating systems without needing to use > a different partition for each one. Is this within the bounds of possibility or > a totally irrational thought? I can not assess feasibility of such a project. Just want to note that ultimately it's the code that gets booted, not filesystems. I have an impression that Solaris boot archive is quite different from how FreeBSD kernel gets booted. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 09:20:34 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 5DE6B1065672; Wed, 18 Apr 2012 09:20:34 +0000 (UTC) (envelope-from araujo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 32AA08FC18; Wed, 18 Apr 2012 09:20:34 +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 q3I9KYNk011874; Wed, 18 Apr 2012 09:20:34 GMT (envelope-from araujo@freefall.freebsd.org) Received: (from araujo@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3I9KYqX011865; Wed, 18 Apr 2012 09:20:34 GMT (envelope-from araujo) Date: Wed, 18 Apr 2012 09:20:34 GMT Message-Id: <201204180920.q3I9KYqX011865@freefall.freebsd.org> To: araujo@FreeBSD.org, araujo@FreeBSD.org, freebsd-fs@FreeBSD.org From: araujo@FreeBSD.org Cc: Subject: Re: kern/167047: RELEASE-9 crash when using ZFS+NULLFS+NFS 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, 18 Apr 2012 09:20:34 -0000 Synopsis: RELEASE-9 crash when using ZFS+NULLFS+NFS State-Changed-From-To: open->closed State-Changed-By: araujo State-Changed-When: Wed Apr 18 09:20:33 UTC 2012 State-Changed-Why: I'm gonna open another one with more info. http://www.freebsd.org/cgi/query-pr.cgi?pr=167047 From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 09:43:07 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB9A0106564A; Wed, 18 Apr 2012 09:43:07 +0000 (UTC) (envelope-from araujo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9F61B8FC1A; Wed, 18 Apr 2012 09:43:07 +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 q3I9h79c037520; Wed, 18 Apr 2012 09:43:07 GMT (envelope-from araujo@freefall.freebsd.org) Received: (from araujo@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3I9h7E6037516; Wed, 18 Apr 2012 09:43:07 GMT (envelope-from araujo) Date: Wed, 18 Apr 2012 09:43:07 GMT Message-Id: <201204180943.q3I9h7E6037516@freefall.freebsd.org> To: araujo@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: araujo@FreeBSD.org Cc: Subject: Re: kern/167048: RELEASE-9 crash when using ZFS+NULLFS+NFS 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, 18 Apr 2012 09:43:07 -0000 Synopsis: RELEASE-9 crash when using ZFS+NULLFS+NFS Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: araujo Responsible-Changed-When: Wed Apr 18 09:43:07 UTC 2012 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=167048 From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 13:54: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 58476106567C; Wed, 18 Apr 2012 13:54:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2D2628FC15; Wed, 18 Apr 2012 13:54:55 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8E27FB95E; Wed, 18 Apr 2012 09:54:54 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Wed, 18 Apr 2012 09:41:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4F8999D2.1080902@FreeBSD.org> <201204171643.39447.jhb@freebsd.org> <4F8E58EE.8080909@FreeBSD.org> In-Reply-To: <4F8E58EE.8080909@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204180941.24699.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 18 Apr 2012 09:54:54 -0400 (EDT) Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 13:54:55 -0000 On Wednesday, April 18, 2012 2:02:22 am Andriy Gapon wrote: > on 17/04/2012 23:43 John Baldwin said the following: > > On Tuesday, April 17, 2012 4:22:19 pm Andriy Gapon wrote: > >> We already have a flag for ZFS (KARGS_FLAGS_ZFS, 0x4). So the new flag could be > >> named something ZFS-specific (as silly as KARGS_FLAGS_ZFS2) or something more > >> general such as KARGS_FLAGS_32_BYTES meaning that the total size of arguments > >> area is 32 bytes (as opposed to 24 previously). > > > > Does KARGS_FLAGS_GUID work? > > > > I think that's too terse, we already passed a pool guid via the existing > argument space. So it should be something like KARGS_FLAGS_ZFS_FS_GUID or > KARGS_FLAGS_ZFS_DS_GUID (DS - dataset). Ah. I do think the flag should indicate that the bootinfo structure is larger, I was assuming you were adding a new GUID field that didn't exist before. I can't think of something better than KARGS_FLAGS_32. What might be nice actually, is to add a new field to indicate the size of the argument area and to set a flag to indicate that the size field is present (KARGS_FLAGS_SIZE)? Hmm, looks like we should name this structure and move it and the relevant KARGS_FLAGS_* fields into a header while we are at it? -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 14:22:33 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7403C106566B for ; Wed, 18 Apr 2012 14:22:33 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 4F1998FC16 for ; Wed, 18 Apr 2012 14:22:33 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta04.emeryville.ca.mail.comcast.net with comcast id zSG81i00F1eYJf8A4SNTUN; Wed, 18 Apr 2012 14:22:27 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta19.emeryville.ca.mail.comcast.net with comcast id zSNR1i0124NgCEG01SNS31; Wed, 18 Apr 2012 14:22:26 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q3IEMOxp066955; Wed, 18 Apr 2012 08:22:24 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: John Baldwin In-Reply-To: <201204180941.24699.jhb@freebsd.org> References: <4F8999D2.1080902@FreeBSD.org> <201204171643.39447.jhb@freebsd.org> <4F8E58EE.8080909@FreeBSD.org> <201204180941.24699.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Apr 2012 08:22:23 -0600 Message-ID: <1334758943.1082.242.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Andriy Gapon Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:22:33 -0000 On Wed, 2012-04-18 at 09:41 -0400, John Baldwin wrote: > On Wednesday, April 18, 2012 2:02:22 am Andriy Gapon wrote: > > on 17/04/2012 23:43 John Baldwin said the following: > > > On Tuesday, April 17, 2012 4:22:19 pm Andriy Gapon wrote: > > >> We already have a flag for ZFS (KARGS_FLAGS_ZFS, 0x4). So the new flag could be > > >> named something ZFS-specific (as silly as KARGS_FLAGS_ZFS2) or something more > > >> general such as KARGS_FLAGS_32_BYTES meaning that the total size of arguments > > >> area is 32 bytes (as opposed to 24 previously). > > > > > > Does KARGS_FLAGS_GUID work? > > > > > > > I think that's too terse, we already passed a pool guid via the existing > > argument space. So it should be something like KARGS_FLAGS_ZFS_FS_GUID or > > KARGS_FLAGS_ZFS_DS_GUID (DS - dataset). > > Ah. I do think the flag should indicate that the bootinfo structure is larger, > I was assuming you were adding a new GUID field that didn't exist before. > I can't think of something better than KARGS_FLAGS_32. What might be nice > actually, is to add a new field to indicate the size of the argument area and > to set a flag to indicate that the size field is present (KARGS_FLAGS_SIZE)? YES! A size field (preferably as the first field in the struct) along with a flag to indicate that it's a new-style boot info struct that starts with a size field, will allow future changes without a lot of drama. It can allow code that has to deal with the struct without interpretting it (such as trampoline code that has to copy it to a new stack or memory area as part of loading the kernel) to be immune to future changes. This probably isn't a big deal in the x86 world, but it can be important for embedded systems where a proprietary bootloader has to pass info to a proprietary board_init() type routine in the kernel using non-proprietary loader/trampoline code that's part of the base. We have a bit of a mess in this regard in the ARM world right now, and it would be a lot lessy messy if something like this had been in place. -- Ian From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 14:37:04 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FECF1065670; Wed, 18 Apr 2012 14:37:04 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 650138FC18; Wed, 18 Apr 2012 14:37:03 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA12963; Wed, 18 Apr 2012 17:36:56 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4F8ED187.9030108@FreeBSD.org> Date: Wed, 18 Apr 2012 17:36:55 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Ian Lepore References: <4F8999D2.1080902@FreeBSD.org> <201204171643.39447.jhb@freebsd.org> <4F8E58EE.8080909@FreeBSD.org> <201204180941.24699.jhb@freebsd.org> <1334758943.1082.242.camel@revolution.hippie.lan> In-Reply-To: <1334758943.1082.242.camel@revolution.hippie.lan> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, John Baldwin Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:37:04 -0000 on 18/04/2012 17:22 Ian Lepore said the following: > YES! A size field (preferably as the first field in the struct) along > with a flag to indicate that it's a new-style boot info struct that > starts with a size field, will allow future changes without a lot of > drama. It can allow code that has to deal with the struct without > interpretting it (such as trampoline code that has to copy it to a new > stack or memory area as part of loading the kernel) to be immune to > future changes. Yeah, placing the new field at front would immediately break compatibility and even access to the flags field :-) -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 14:40:11 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1CF501065674 for ; Wed, 18 Apr 2012 14:40:11 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id EF62B8FC19 for ; Wed, 18 Apr 2012 14:40:10 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta12.emeryville.ca.mail.comcast.net with comcast id zSFB1i0051GXsucACSgABw; Wed, 18 Apr 2012 14:40:10 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta07.emeryville.ca.mail.comcast.net with comcast id zSg91i01f4NgCEG8USgA5r; Wed, 18 Apr 2012 14:40:10 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q3IEe7WJ066972; Wed, 18 Apr 2012 08:40:07 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Andriy Gapon In-Reply-To: <4F8ED187.9030108@FreeBSD.org> References: <4F8999D2.1080902@FreeBSD.org> <201204171643.39447.jhb@freebsd.org> <4F8E58EE.8080909@FreeBSD.org> <201204180941.24699.jhb@freebsd.org> <1334758943.1082.242.camel@revolution.hippie.lan> <4F8ED187.9030108@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Apr 2012 08:40:07 -0600 Message-ID: <1334760007.1082.243.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, John Baldwin Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:40:11 -0000 On Wed, 2012-04-18 at 17:36 +0300, Andriy Gapon wrote: > on 18/04/2012 17:22 Ian Lepore said the following: > > YES! A size field (preferably as the first field in the struct) along > > with a flag to indicate that it's a new-style boot info struct that > > starts with a size field, will allow future changes without a lot of > > drama. It can allow code that has to deal with the struct without > > interpretting it (such as trampoline code that has to copy it to a new > > stack or memory area as part of loading the kernel) to be immune to > > future changes. > > Yeah, placing the new field at front would immediately break compatibility and > even access to the flags field :-) > Code would only assume the new field was at the front of the struct if the new flag is set, otherwise it would use the historical struct layout. -- Ian From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 15:00:25 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 216E71065748; Wed, 18 Apr 2012 15:00:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 087F38FC16; Wed, 18 Apr 2012 15:00:23 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA13173; Wed, 18 Apr 2012 18:00:19 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4F8ED702.4020803@FreeBSD.org> Date: Wed, 18 Apr 2012 18:00:18 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Ian Lepore References: <4F8999D2.1080902@FreeBSD.org> <201204171643.39447.jhb@freebsd.org> <4F8E58EE.8080909@FreeBSD.org> <201204180941.24699.jhb@freebsd.org> <1334758943.1082.242.camel@revolution.hippie.lan> <4F8ED187.9030108@FreeBSD.org> <1334760007.1082.243.camel@revolution.hippie.lan> In-Reply-To: <1334760007.1082.243.camel@revolution.hippie.lan> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, John Baldwin Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 15:00:25 -0000 on 18/04/2012 17:40 Ian Lepore said the following: > On Wed, 2012-04-18 at 17:36 +0300, Andriy Gapon wrote: >> on 18/04/2012 17:22 Ian Lepore said the following: >>> YES! A size field (preferably as the first field in the struct) along >>> with a flag to indicate that it's a new-style boot info struct that >>> starts with a size field, will allow future changes without a lot of >>> drama. It can allow code that has to deal with the struct without >>> interpretting it (such as trampoline code that has to copy it to a new >>> stack or memory area as part of loading the kernel) to be immune to >>> future changes. >> >> Yeah, placing the new field at front would immediately break compatibility and >> even access to the flags field :-) >> > > Code would only assume the new field was at the front of the struct if > the new flag is set, otherwise it would use the historical struct > layout. Right, but where the flag would reside? And how the older code that is not aware of the new flag would cope with the new layout? -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 16:02:10 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE675106564A for ; Wed, 18 Apr 2012 16:02:10 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5DD4C8FC12 for ; Wed, 18 Apr 2012 16:02:10 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MBq6h-1SRvKY0BGR-009wfU; Wed, 18 Apr 2012 18:02:09 +0200 Message-ID: <4F8EE580.6080907@brockmann-consult.de> Date: Wed, 18 Apr 2012 18:02:08 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Jeremy Chadwick References: <4F192ADA.5020903@brockmann-consult.de> <20120120090915.GA90876@icarus.home.lan> In-Reply-To: <20120120090915.GA90876@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:X2pVQZsPw+jC91I6QUr828iGKweM+XIxgZFe3nY4pBO hkGQntFi2i9gSd7J3hSmTahfVD+FHQIHvZQeXOZoZfayNRFDKj wVNOk2o8uBPbcVf2dj4I57/tvURlRq+4jO5JP6DDcHx1dnlbKT Syfk/A9Rz4PwxeaRvsaxT60iBJJo2QyHpgsfJ69oZ0RUQ23jLT PTR9MfiRtFzVSeQq/QNfexm0upstVHAvBbmjJZGXTq/Y6mKY3e FohZlvwvekH/iludIRH0lGeOG2wkxMgU2kIk+InwQW3Y4GqORf Ip4fLLCigCko2pSc9Js2lNUiu9TOiXIZH0OfALd5qnlAJVeICY 7JBiz/6x0tdYlN9LHWOR9MG92YTMX6bjhglAqh8FA Cc: freebsd-fs@freebsd.org Subject: Re: sanity check: is 9211-8i, on 8.3, with IT firmware still "the one" 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, 18 Apr 2012 16:02:10 -0000 Some info for whoever might be interested: This web site does not have the new firmware that works on SAS expanders (instead has 0309): http://www.crucial.com/support/crucialfirmware.aspx But this one does (version 000F): > Hello Peter, > > Thanks for your email. > > We released the firmware on the 11th of this month. The version you should download is 000F. > > You will find this firmware upgrade by following the link below: > > http://www.crucial.com/uk/support/firmware.aspx On 01/20/2012 10:09 AM, Jeremy Chadwick wrote: > On Fri, Jan 20, 2012 at 09:50:34AM +0100, Peter Maloney wrote: >> John, >> >> Various people have problems with mps and ZFS. >> >> I am using 8-STABLE from October 2011, and on the 9211-8i HBA, I am >> using 9 IT firmware. In my case, it was the firmware on an SSD that >> caused problems. >> Crucial M4-CT256M4SSD2 firmware 0001 > My below comment is unrelated to mps driver bugs and so on, but: > > Owners of Crucial m4 SSDs need to be aware of this catastrophic problem > with the drives: Crucial m4 SSDs begin to fail (data loss) starting at > the 5200 power-on-hours count. Apparently the problem is triggered by > some sort of SMART-related ordeal as well (I have no details). This is > a firmware bug and has been confirmed by Crucial. > > A firmware fix just came out a few days ago for the problem. Here's the > URL where I was made aware of this problem (note the trailing hyphen > please): > > http://www.dslreports.com/forum/r26745697- > > And media confirmations: > > http://www.theverge.com/2012/1/17/2713178/crucial-m4-ssd-firmware-update-fixes-recurring-bsod > http://www.anandtech.com/show/5308/crucial-to-fix-m4-bsod-issue-in-two-weeks > http://www.anandtech.com/show/5424/crucial-provides-a-firmware-update-for-m4-to-fix-the-bsod-issue > > I've now added Crucial to my SSD brands to avoid (currently OCZ and > Crucial). Welcome to year 20xx, where nobody actually does quality > assurance properly. > -- -------------------------------------------- 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 Wed Apr 18 16:35:05 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 EB4DF10656E0; Wed, 18 Apr 2012 16:35:05 +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 BE8CA8FC14; Wed, 18 Apr 2012 16:35:05 +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 q3IGZ5Yx021460; Wed, 18 Apr 2012 16:35:05 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3IGZ5QP021456; Wed, 18 Apr 2012 16:35:05 GMT (envelope-from linimon) Date: Wed, 18 Apr 2012 16:35:05 GMT Message-Id: <201204181635.q3IGZ5QP021456@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: misc/167065: [zfs] boot fails when a spare is the boot disk 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, 18 Apr 2012 16:35:06 -0000 Synopsis: [zfs] boot fails when a spare is the boot disk Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Apr 18 16:34:51 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=167065 From owner-freebsd-fs@FreeBSD.ORG Wed Apr 18 17:48:10 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 AE54A106566C; Wed, 18 Apr 2012 17:48:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 81F8B8FC18; Wed, 18 Apr 2012 17:48:10 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D0B8BB958; Wed, 18 Apr 2012 13:48:09 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Wed, 18 Apr 2012 13:47:59 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4F8999D2.1080902@FreeBSD.org> <1334760007.1082.243.camel@revolution.hippie.lan> <4F8ED702.4020803@FreeBSD.org> In-Reply-To: <4F8ED702.4020803@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204181347.59109.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 18 Apr 2012 13:48:10 -0400 (EDT) Cc: freebsd-fs@freebsd.org, Ian Lepore , freebsd-hackers@freebsd.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 17:48:10 -0000 On Wednesday, April 18, 2012 11:00:18 am Andriy Gapon wrote: > on 18/04/2012 17:40 Ian Lepore said the following: > > On Wed, 2012-04-18 at 17:36 +0300, Andriy Gapon wrote: > >> on 18/04/2012 17:22 Ian Lepore said the following: > >>> YES! A size field (preferably as the first field in the struct) along > >>> with a flag to indicate that it's a new-style boot info struct that > >>> starts with a size field, will allow future changes without a lot of > >>> drama. It can allow code that has to deal with the struct without > >>> interpretting it (such as trampoline code that has to copy it to a new > >>> stack or memory area as part of loading the kernel) to be immune to > >>> future changes. > >> > >> Yeah, placing the new field at front would immediately break compatibility and > >> even access to the flags field :-) > >> > > > > Code would only assume the new field was at the front of the struct if > > the new flag is set, otherwise it would use the historical struct > > layout. > > Right, but where the flag would reside? > And how the older code that is not aware of the new flag would cope with the new > layout? I think the size should be appended to the end of the current structure. However, it will buy us more flexibility in the future. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Thu Apr 19 12:10:11 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 655871065670 for ; Thu, 19 Apr 2012 12:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3705C8FC15 for ; Thu, 19 Apr 2012 12:10:11 +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 q3JCAB1J047265 for ; Thu, 19 Apr 2012 12:10:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3JCABo0047264; Thu, 19 Apr 2012 12:10:11 GMT (envelope-from gnats) Date: Thu, 19 Apr 2012 12:10:11 GMT Message-Id: <201204191210.q3JCABo0047264@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Peter Maloney Cc: Subject: Re: misc/167065: [zfs] boot fails when a spare is the boot disk X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Maloney List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 12:10:11 -0000 The following reply was made to PR misc/167065; it has been noted by GNATS. From: Peter Maloney To: bug-followup@FreeBSD.org, peter.maloney@brockmann-consult.de Cc: Subject: Re: misc/167065: [zfs] boot fails when a spare is the boot disk Date: Thu, 19 Apr 2012 14:04:38 +0200 Actually, I tried booting with all disks attached, and it still failed the same way. And then tried again with the spare removed, which was the same. From owner-freebsd-fs@FreeBSD.ORG Sat Apr 21 00:39:29 2012 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A21A2106566B for ; Sat, 21 Apr 2012 00:39:29 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 543A68FC0C for ; Sat, 21 Apr 2012 00:39:29 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id A44C1ED371 for ; Sat, 21 Apr 2012 02:39:19 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id 54tQYJMNWhPf for ; Sat, 21 Apr 2012 02:39:19 +0200 (CEST) Received: from [172.17.136.194] (adsl-66-120-169-242.dsl.sntc01.pacbell.net [66.120.169.242]) by smtp.semihalf.com (Postfix) with ESMTPSA id 97EF1ED0C4 for ; Sat, 21 Apr 2012 02:39:18 +0200 (CEST) Message-ID: <4F9201BC.6080000@semihalf.com> Date: Sat, 21 Apr 2012 02:39:24 +0200 From: Grzegorz Bernacki User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: fs@FreeBSD.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Request for comments - NAND Framework & NandFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2012 00:39:29 -0000 Hi, We work on integration our work on NAND Framework into -current. Our project consist of: - NAND Framework which allows treat NAND Flash Chip as storage devices, - NANDSim which is kernel driver which emulates ONFI-compliant chip devices and userspace tool to configure/manage created devices, - NandFs which is log filesystem which is targeted for NAND chip storage devices. Currently our work is merged into "nand" branch under project directory (http://svnweb.freebsd.org/base/projects/nand/). Currently we are still working on fixing existing bugs and cleaning up the code. We are going to start merge in into HEAD on on May 7th. I would like to ask you to review the code and let us know if you have any comments or concerns. thanks, grzesiek From owner-freebsd-fs@FreeBSD.ORG Sat Apr 21 05:47:20 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C801106564A; Sat, 21 Apr 2012 05:47:20 +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 E3B908FC0C; Sat, 21 Apr 2012 05:47: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 q3L5lJh6058187; Sat, 21 Apr 2012 05:47:19 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3L5lJ6a058183; Sat, 21 Apr 2012 05:47:19 GMT (envelope-from linimon) Date: Sat, 21 Apr 2012 05:47:19 GMT Message-Id: <201204210547.q3L5lJ6a058183@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/167067: [zfs] [panic] ZFS panics the server X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2012 05:47:20 -0000 Old Synopsis: ZFS panics the server New Synopsis: [zfs] [panic] ZFS panics the server Responsible-Changed-From-To: freebsd-amd64->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sat Apr 21 05:47:02 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=167067