From owner-freebsd-fs@freebsd.org Sun Jul 8 00:53:20 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 799481043622 for ; Sun, 8 Jul 2018 00:53:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 356337601A for ; Sun, 8 Jul 2018 00:53:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id EDE4A1043619; Sun, 8 Jul 2018 00:53:19 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9F8B1043618 for ; Sun, 8 Jul 2018 00:53:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 984AA76016 for ; Sun, 8 Jul 2018 00:53:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id D887DF34A for ; Sun, 8 Jul 2018 00:53:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w680rIxC008633 for ; Sun, 8 Jul 2018 00:53:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w680rIrn008632 for fs@FreeBSD.org; Sun, 8 Jul 2018 00:53:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 229595] zpool upgrade should substitute disk and partition numbers in gpart instructions Date: Sun, 08 Jul 2018 00:53:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 00:53:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229595 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sun Jul 8 09:02:31 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6FB6C102AF0C for ; Sun, 8 Jul 2018 09:02:31 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0AB638A8ED for ; Sun, 8 Jul 2018 09:02:31 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1fc5aO-00084s-Rm; Sun, 08 Jul 2018 11:02:29 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-fs@freebsd.org, "Manish Jain" Subject: Re: A request for unnested UFS implementation in MBR References: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> Date: Sun, 08 Jul 2018 11:02:30 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.5 X-Spam-Status: No, score=0.5 required=5.0 tests=ALL_TRUSTED, BAYES_60 autolearn=disabled version=3.4.0 X-Scan-Signature: 4cc6a862e0a753e674eb374334b394fd X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 09:02:31 -0000 On Sat, 07 Jul 2018 07:59:55 +0200, Manish Jain wrote: > Hi all, > > I am a longtime user of FreeBSD, which now serves as my only OS. > > There is one request I wished to make for FreeBSD filesystems. While UFS > implementation under GPT is unnested just as Ext2, the MBR > implementation of UFS continues to piggyback on an unnecessary nest (in > a BSD slice). > > Can it not be considered as an alternative to provide a UFS partition > (unnested) under MBR too ? > > Existing users could continue to use the freebsd::freebsd-ufs scheme, > while fresh usage could have the alternative of UFS directly recorded in > the MBR. > > I should perhaps note that unlike most users who have shifted to GPT of > late, I much prefer MBR because 1) the scheme's design by itself keeps > the number of slices/partitions in a disk manageable; and 2) I can use > the boot0 manager, my favourite boot manager. > > Thanks for reading this. > Manish Jain Do you mean something like this? Gpart refuses to create a freebsd-ufs partition in the MBR part. # mdconfig -s 512m md0 # gpart create -s MBR md0 md0 created # gpart add -t freebsd-ufs -s 256m md0 gpart: Invalid argument # gpart add -t freebsd-swap -s 256m md0 gpart: Invalid argument But you can create and newfs other types. # gpart add -t linux-data -s 256M md0 md0s1 added # newfs /dev/md0s1 /dev/md0s1: 256.0MB (524288 sectors) block size 32768, fragment size 4096 using 4 cylinder groups of 64.03MB, 2049 blks, 8320 inodes. super-block backups (for fsck_ffs -b #) at: 192, 131328, 262464, 393600 # gpart add -t freebsd md0 md0s2 added # newfs /dev/md0s2 /dev/md0s2: 256.0MB (524272 sectors) block size 32768, fragment size 4096 using 4 cylinder groups of 64.00MB, 2048 blks, 8192 inodes. super-block backups (for fsck_ffs -b #) at: 192, 131264, 262336, 393408 Interesting. I don't why this is. Regards, Ronald. From owner-freebsd-fs@freebsd.org Sun Jul 8 11:49:11 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19390103D225 for ; Sun, 8 Jul 2018 11:49:11 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB9F870D16 for ; Sun, 8 Jul 2018 11:49:10 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fc8Bf-000FoX-P4; Sun, 08 Jul 2018 12:49:07 +0100 Date: Sun, 8 Jul 2018 12:49:07 +0100 From: Gary Palmer To: Ronald Klop Cc: freebsd-fs@freebsd.org, Manish Jain Subject: Re: A request for unnested UFS implementation in MBR Message-ID: <20180708114907.GA47960@in-addr.com> References: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 11:49:11 -0000 On Sun, Jul 08, 2018 at 11:02:30AM +0200, Ronald Klop wrote: > On Sat, 07 Jul 2018 07:59:55 +0200, Manish Jain > wrote: > > > Hi all, > > > > I am a longtime user of FreeBSD, which now serves as my only OS. > > > > There is one request I wished to make for FreeBSD filesystems. While UFS > > implementation under GPT is unnested just as Ext2, the MBR > > implementation of UFS continues to piggyback on an unnecessary nest (in > > a BSD slice). > > > > Can it not be considered as an alternative to provide a UFS partition > > (unnested) under MBR too ? > > > > Existing users could continue to use the freebsd::freebsd-ufs scheme, > > while fresh usage could have the alternative of UFS directly recorded in > > the MBR. > > > > I should perhaps note that unlike most users who have shifted to GPT of > > late, I much prefer MBR because 1) the scheme's design by itself keeps > > the number of slices/partitions in a disk manageable; and 2) I can use > > the boot0 manager, my favourite boot manager. > > > > Thanks for reading this. > > Manish Jain > > Do you mean something like this? Gpart refuses to create a freebsd-ufs > partition in the MBR part. > > # mdconfig -s 512m > md0 > # gpart create -s MBR md0 > md0 created > # gpart add -t freebsd-ufs -s 256m md0 > gpart: Invalid argument > # gpart add -t freebsd-swap -s 256m md0 > gpart: Invalid argument > > But you can create and newfs other types. > > # gpart add -t linux-data -s 256M md0 > md0s1 added > # newfs /dev/md0s1 > /dev/md0s1: 256.0MB (524288 sectors) block size 32768, fragment size 4096 > using 4 cylinder groups of 64.03MB, 2049 blks, 8320 inodes. > super-block backups (for fsck_ffs -b #) at: > 192, 131328, 262464, 393600 > > # gpart add -t freebsd md0 > md0s2 added > # newfs /dev/md0s2 > /dev/md0s2: 256.0MB (524272 sectors) block size 32768, fragment size 4096 > using 4 cylinder groups of 64.00MB, 2048 blks, 8192 inodes. > super-block backups (for fsck_ffs -b #) at: > 192, 131264, 262336, 393408 > > > Interesting. I don't why this is. freebsd-ufs, freebsd-swap, freebsd-zfs, etc, are GPT IDs. freebsd (without any suffix) is a MBR ID. This is covered in the "gpart" man page under each ID Regards, Gary From owner-freebsd-fs@freebsd.org Sun Jul 8 13:08:21 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B670C1045339 for ; Sun, 8 Jul 2018 13:08:21 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward103p.mail.yandex.net (forward103p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26CCA73CFC for ; Sun, 8 Jul 2018 13:08:20 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback4j.mail.yandex.net (mxback4j.mail.yandex.net [IPv6:2a02:6b8:0:1619::10d]) by forward103p.mail.yandex.net (Yandex) with ESMTP id E8B5021821B3 for ; Sun, 8 Jul 2018 16:08:17 +0300 (MSK) Received: from smtp1j.mail.yandex.net (smtp1j.mail.yandex.net [2a02:6b8:0:801::ab]) by mxback4j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id OzR2RpXvBE-8HsmuME1; Sun, 08 Jul 2018 16:08:17 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1531055297; bh=2nvsdrxO/ILrc93C5EK6Pq5uaZ/uz+gZlGw8zbXjoP0=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=FqHXrVvkwkn4AeONhcpzFsWYjxo1C67wv9Lg4+4RrkWuRw0NOIzVa2heCfSQ0djak yCxLg9Uu5xzh/7cKsTSdqhfqGY8rw4hoAUT5pj2uB3/m3AxMaBCmwqf68/4UPORE/2 zfY1s2fuzK6/HSYQLzpa7oM/Lkjk23NQHDF7PjCI= Received: by smtp1j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id ex9p5B9fcz-8Hq8dwIn; Sun, 08 Jul 2018 16:08:17 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1531055297; bh=2nvsdrxO/ILrc93C5EK6Pq5uaZ/uz+gZlGw8zbXjoP0=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=FqHXrVvkwkn4AeONhcpzFsWYjxo1C67wv9Lg4+4RrkWuRw0NOIzVa2heCfSQ0djak yCxLg9Uu5xzh/7cKsTSdqhfqGY8rw4hoAUT5pj2uB3/m3AxMaBCmwqf68/4UPORE/2 zfY1s2fuzK6/HSYQLzpa7oM/Lkjk23NQHDF7PjCI= Authentication-Results: smtp1j.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: A request for unnested UFS implementation in MBR To: Manish Jain , freebsd-fs@freebsd.org References: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Autocrypt: addr=bu7cher@yandex.ru; prefer-encrypt=mutual; keydata= xsBNBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAHNIkFuZHJleSBWLiBFbHN1a292IDxhZUBmcmVlYnNkLm9yZz7CwHsEEwECACUCGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheABQJMB/ruAhkBAAoJEAHF6gQQyKF6MLwH/3Ri/TZl9uo0 SepYWXOnxL6EaDVXDA+dLb1eLKC4PRBBjX29ttQ0KaWapiE6y5/AfzOPmRtHLrHYHjd/aiHX GMLHcYRXD+5GvdkK8iMALrZ28X0JXyuuZa8rAxWIWmCbYHNSBy2unqWgTI04Erodk90IALgM 9JeHN9sFqTM6zalrMnTzlcmel4kcjT3lyYw3vOKgoYLtsLhKZSbJoVVVlvRlGBpHFJI5AoYJ SyfXoN0rcX6k9X7Isp2K50YjqxV4v78xluh1puhwZyC0p8IShPrmrp9Oy9JkMX90o6UAXdGU KfdExJuGJfUZOFBTtNIMNIAKfMTjhpRhxONIr0emxxDOwE0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAcLAXwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i Message-ID: <428ce38c-4f3b-1dff-36c5-4a7509613441@yandex.ru> Date: Sun, 8 Jul 2018 16:08:04 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="URWZ9rmC3VsvqRyDFttqaR6ADl7DLOEjG" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 13:08:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --URWZ9rmC3VsvqRyDFttqaR6ADl7DLOEjG Content-Type: multipart/mixed; boundary="tmFV9ANBfumWRrFYdVk6kIVQbIndvvcsy"; protected-headers="v1" From: "Andrey V. Elsukov" To: Manish Jain , freebsd-fs@freebsd.org Message-ID: <428ce38c-4f3b-1dff-36c5-4a7509613441@yandex.ru> Subject: Re: A request for unnested UFS implementation in MBR References: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> In-Reply-To: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> --tmFV9ANBfumWRrFYdVk6kIVQbIndvvcsy Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07.07.2018 08:59, Manish Jain wrote: > I am a longtime user of FreeBSD, which now serves as my only OS. >=20 > There is one request I wished to make for FreeBSD filesystems. While UF= S > implementation under GPT is unnested just as Ext2, the MBR > implementation of UFS continues to piggyback on an unnecessary nest (in= > a BSD slice). >=20 > Can it not be considered as an alternative to provide a UFS partition > (unnested) under MBR too ? >=20 > Existing users could continue to use the freebsd::freebsd-ufs scheme, > while fresh usage could have the alternative of UFS directly recorded i= n > the MBR. >=20 > I should perhaps note that unlike most users who have shifted to GPT of= > late, I much prefer MBR because 1) the scheme's design by itself keeps > the number of slices/partitions in a disk manageable; and 2) I can use > the boot0 manager, my favourite boot manager. The main goal of using bsdlabel was the boot code, I think. MBR has less than 512 bytes to keep boot code. This is too little to be able place the code that can read UFS filesystem to read and start loader= =2E I'm not sure, but AFAIR there were some hacks in the boot code, that allowed to read from the raw partition as fallback. I.e. you can try to create MBR with "freebsd" slice, make filesystem with newfs on this slice and write boot1 bootcode to this slice at proper offset using dd(1). But as I said, I'm not sure. There were many changes in this area and I did not followed by them. --=20 WBR, Andrey V. Elsukov --tmFV9ANBfumWRrFYdVk6kIVQbIndvvcsy-- --URWZ9rmC3VsvqRyDFttqaR6ADl7DLOEjG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAltCDLQACgkQAcXqBBDI oXrxmQgAp2X7eIydmjUrohz5TqGOjNEncJTkz5Dp77VBGHeOnLoKf3DqyiA9Owh8 3nyGZmQuIJKyZVWVLUqWFooDRHCmlP86mfh6dJDcxWQ1VKwiHRHnbxaLZbuFIkaN VpCVnBxhxgzry5Gv6USx2uW3p5J8FVx5nM4MaiQzRXgCYP0fga25MplNqb2Zbxtl UOsYDzkkSixUbw29IJNHg5u50Hj0VXANTnTSfm2wAxgmxb7lZry24s29dPnldLFW awCma1+TyUBFHlAvHaMq9lvLrDeQpRPvwaAoFa3lGwKAVLGOFQMyh4PNb3sMvzkF UC72fZUS7ZmAWl99YTNgRr4tfNkfEQ== =GnE5 -----END PGP SIGNATURE----- --URWZ9rmC3VsvqRyDFttqaR6ADl7DLOEjG-- From owner-freebsd-fs@freebsd.org Sun Jul 8 21:00:57 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 879591030F63 for ; Sun, 8 Jul 2018 21:00:57 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 192838B05C for ; Sun, 8 Jul 2018 21:00:57 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id CCED81030F5F; Sun, 8 Jul 2018 21:00:56 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FE201030F5E for ; Sun, 8 Jul 2018 21:00:56 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C7658B04C for ; Sun, 8 Jul 2018 21:00:56 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 0E84919B35 for ; Sun, 8 Jul 2018 21:00:55 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w68L0suB058794 for ; Sun, 8 Jul 2018 21:00:54 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w68L0sI1058781 for fs@FreeBSD.org; Sun, 8 Jul 2018 21:00:54 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201807082100.w68L0sI1058781@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: fs@FreeBSD.org Subject: Problem reports for fs@FreeBSD.org that need special attention Date: Sun, 8 Jul 2018 21:00:54 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 21:00:57 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 203492 | mount_unionfs -o below causes panic New | 217062 | for file systems mounted with -o noexec, exec=off New | 221909 | [ZFS] Add a sysctl to toggle send_corrupt_data Open | 140068 | [smbfs] [patch] smbfs does not allow semicolon in Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f Open | 211491 | System hangs after "Uptime" on reboot with ZFS 6 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Sun Jul 8 21:37:44 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1FC9810358DD for ; Sun, 8 Jul 2018 21:37:44 +0000 (UTC) (envelope-from jude.obscure@yandex.com) Received: from forward102o.mail.yandex.net (forward102o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::602]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B595E8D378 for ; Sun, 8 Jul 2018 21:37:43 +0000 (UTC) (envelope-from jude.obscure@yandex.com) Received: from mxback9j.mail.yandex.net (mxback9j.mail.yandex.net [IPv6:2a02:6b8:0:1619::112]) by forward102o.mail.yandex.net (Yandex) with ESMTP id B36455A02F0E; Mon, 9 Jul 2018 00:37:40 +0300 (MSK) Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [2a02:6b8:0:1a2d::27]) by mxback9j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id ckj24MUSy4-beIq8HrD; Mon, 09 Jul 2018 00:37:40 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1531085860; bh=6sdOqb3K3wKbEzjk/Za5KAxItn6b5wycFmEOOYawd0k=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=dqCDNzIDVPGb7yc2P0UbIWjF9fUBgxgElTHfPPdN11rSTgi8hBrVZo1jfYZr0m8Qz oeG95Zh1idm5zmJqK4GJT744nIhSWEBzNhqwWLo9d414SFDUPVtzLb/cBBIPikNSXF EJ24xvluSifU89gn2HUxv0pSwxnD4y1GUn596FEM= Received: by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 0S8IWT29LD-bcGGixLf; Mon, 09 Jul 2018 00:37:39 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1531085859; bh=6sdOqb3K3wKbEzjk/Za5KAxItn6b5wycFmEOOYawd0k=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=xz/oetKd7pXHGwvWs+loadeDmTxSFuVCkle+SsxVO2SI9kb/QwJHqD9NIpGdJb6yV fT6Vg3FT4cQ7XuNduUXsfR6Qii+BKzrJvNAUH/83/S9YrTn+YueiASi+tUvhrxYQ6A 3y0hwMNuvN19TyH41hwRfFjx+7Mw+4zCkC57Hogs= Authentication-Results: smtp3o.mail.yandex.net; dkim=pass header.i=@yandex.com Subject: Re: A request for unnested UFS implementation in MBR To: Ronald Klop , freebsd-fs@freebsd.org References: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> From: Manish Jain Message-ID: Date: Mon, 9 Jul 2018 03:05:35 +0530 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 21:37:44 -0000 On 07/08/18 14:32, Ronald Klop wrote: > On Sat, 07 Jul 2018 07:59:55 +0200, Manish Jain > wrote: > >> Hi all, >> >> I am a longtime user of FreeBSD, which now serves as my only OS. >> >> There is one request I wished to make for FreeBSD filesystems. While >> UFS implementation under GPT is unnested just as Ext2, the MBR >> implementation of UFS continues to piggyback on an unnecessary nest >> (in a BSD slice). >> >> Can it not be considered as an alternative to provide a UFS partition >> (unnested) under MBR too ? >> >> Existing users could continue to use the freebsd::freebsd-ufs scheme, >> while fresh usage could have the alternative of UFS directly recorded >> in the MBR. >> >> I should perhaps note that unlike most users who have shifted to GPT >> of late, I much prefer MBR because 1) the scheme's design by itself >> keeps the number of slices/partitions in a disk manageable; and 2) I >> can use the boot0 manager, my favourite boot manager. >> >> Thanks for reading this. >> Manish Jain > > Do you mean something like this? Gpart refuses to create a freebsd-ufs > partition in the MBR part. > > # mdconfig -s 512m > md0 > # gpart create -s MBR md0 > md0 created > # gpart add -t freebsd-ufs -s 256m md0 > gpart: Invalid argument > # gpart add -t freebsd-swap -s 256m md0 > gpart: Invalid argument > > But you can create and newfs other types. > > # gpart add -t linux-data -s 256M md0 > md0s1 added > # newfs /dev/md0s1 > /dev/md0s1: 256.0MB (524288 sectors) block size 32768, fragment size 4096 >     using 4 cylinder groups of 64.03MB, 2049 blks, 8320 inodes. > super-block backups (for fsck_ffs -b #) at: >  192, 131328, 262464, 393600 > > # gpart add -t freebsd md0 > md0s2 added > # newfs /dev/md0s2 > /dev/md0s2: 256.0MB (524272 sectors) block size 32768, fragment size 4096 >     using 4 cylinder groups of 64.00MB, 2048 blks, 8192 inodes. > super-block backups (for fsck_ffs -b #) at: >  192, 131264, 262336, 393408 Hi all, I will reply to all the answers (which accumulated as I had a very nice long sleep, thank you) to this thread here. This is what I get currently applying gpart to my USB pen drive: /root <<: gpart create -s MBR da0 da0 created /root <<: gpart add -t linux-data -s 1G da0 da0s1 added /root <<: gpart add -t freebsd-ufs -s 1G da0 gpart: Invalid argument # WHY ? It currently is a real bother having to create UFS, with a whole lot of extra commands: /root <<: gpart add -t freebsd -s 1G da0 da0s2 added /root <<: gpart create -s BSD da0s2 da0s2 created /root <<: gpart add -t freebsd-ufs da0s2 da0s2a added The extra commands mean that when a user wants to quickly put a partition on a disk of any kind, it is much easier using Ext2. If the original command (highlighted with WHY ?) could succeed as such (or perhaps with a slight alteration: gpart add -t ufs -s 1G da0), UFS becomes as convenient as Ext2 for general purpose usage. There is another way to think about the situation. FreeBSD currently caters to only 2 types of users: 1) Dedicated disk users - use BSD schema 2) Slice users - use MBR schema + BSD schema With very little effort, we can make the OS cater to the third kind of users : partition users (use MBR + EBR - no BSD). This makes FreeBSD behaviour same as what other operating systems do - expect the user to use one of the 3 primary partitions for /, and any extra filesystems (/usr or /var or swap) optionally needed to be found in the EBR. Thanks - particularly so if you see a valid point in my request. Manish Jain From owner-freebsd-fs@freebsd.org Sun Jul 8 23:04:47 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3C171040CEB for ; Sun, 8 Jul 2018 23:04:46 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 956F6716BC for ; Sun, 8 Jul 2018 23:04:46 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fcIjT-00051R-1c; Mon, 09 Jul 2018 00:04:43 +0100 Date: Mon, 9 Jul 2018 00:04:42 +0100 From: Gary Palmer To: Manish Jain Cc: Ronald Klop , freebsd-fs@freebsd.org Subject: Re: A request for unnested UFS implementation in MBR Message-ID: <20180708230442.GB47960@in-addr.com> References: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 23:04:47 -0000 On Mon, Jul 09, 2018 at 03:05:35AM +0530, Manish Jain wrote: > On 07/08/18 14:32, Ronald Klop wrote: > > On Sat, 07 Jul 2018 07:59:55 +0200, Manish Jain > > wrote: > > > >> Hi all, > >> > >> I am a longtime user of FreeBSD, which now serves as my only OS. > >> > >> There is one request I wished to make for FreeBSD filesystems. While > >> UFS implementation under GPT is unnested just as Ext2, the MBR > >> implementation of UFS continues to piggyback on an unnecessary nest > >> (in a BSD slice). > >> > >> Can it not be considered as an alternative to provide a UFS partition > >> (unnested) under MBR too ? > >> > >> Existing users could continue to use the freebsd::freebsd-ufs scheme, > >> while fresh usage could have the alternative of UFS directly recorded > >> in the MBR. > >> > >> I should perhaps note that unlike most users who have shifted to GPT > >> of late, I much prefer MBR because 1) the scheme's design by itself > >> keeps the number of slices/partitions in a disk manageable; and 2) I > >> can use the boot0 manager, my favourite boot manager. > >> > >> Thanks for reading this. > >> Manish Jain > > > > Do you mean something like this? Gpart refuses to create a freebsd-ufs > > partition in the MBR part. > > > > # mdconfig -s 512m > > md0 > > # gpart create -s MBR md0 > > md0 created > > # gpart add -t freebsd-ufs -s 256m md0 > > gpart: Invalid argument > > # gpart add -t freebsd-swap -s 256m md0 > > gpart: Invalid argument > > > > But you can create and newfs other types. > > > > # gpart add -t linux-data -s 256M md0 > > md0s1 added > > # newfs /dev/md0s1 > > /dev/md0s1: 256.0MB (524288 sectors) block size 32768, fragment size 4096 > > ????????using 4 cylinder groups of 64.03MB, 2049 blks, 8320 inodes. > > super-block backups (for fsck_ffs -b #) at: > > ??192, 131328, 262464, 393600 > > > > # gpart add -t freebsd md0 > > md0s2 added > > # newfs /dev/md0s2 > > /dev/md0s2: 256.0MB (524272 sectors) block size 32768, fragment size 4096 > > ????????using 4 cylinder groups of 64.00MB, 2048 blks, 8192 inodes. > > super-block backups (for fsck_ffs -b #) at: > > ??192, 131264, 262336, 393408 > > Hi all, > > I will reply to all the answers (which accumulated as I had a very nice > long sleep, thank you) to this thread here. > > This is what I get currently applying gpart to my USB pen drive: > > /root <<: gpart create -s MBR da0 > da0 created > /root <<: gpart add -t linux-data -s 1G da0 > da0s1 added > /root <<: gpart add -t freebsd-ufs -s 1G da0 > gpart: Invalid argument # WHY ? Hi, As I said in my email, freebsd-ufs is a GPT ID. MBR has a very restricted set of what is considered valid - from memory it's a single byte. That means freebsd-swap, freebsd-zfs, freebsd-ufs, etc aren't valid. > It currently is a real bother having to create UFS, with a whole lot of > extra commands: > > /root <<: gpart add -t freebsd -s 1G da0 > da0s2 added > /root <<: gpart create -s BSD da0s2 > da0s2 created > /root <<: gpart add -t freebsd-ufs da0s2 > da0s2a added There is nothing forcing you to create the BSD label # mdconfig -s 512m md0 # gpart create -s MBR md0 md0 created # gpart add -t freebsd md0 md0s1 added # newfs /dev/md0s1 /dev/md0s1: 512.0MB (1048560 sectors) block size 32768, fragment size 4096 using 4 cylinder groups of 128.00MB, 4096 blks, 16384 inodes. super-block backups (for fsck_ffs -b #) at: 192, 262336, 524480, 786624 # mount /dev/md0s1 /mnt # > The extra commands mean that when a user wants to quickly put a > partition on a disk of any kind, it is much easier using Ext2. > > If the original command (highlighted with WHY ?) could succeed as such > (or perhaps with a slight alteration: gpart add -t ufs -s 1G da0), UFS > becomes as convenient as Ext2 for general purpose usage. > > There is another way to think about the situation. > > FreeBSD currently caters to only 2 types of users: > > 1) Dedicated disk users - use BSD schema > > 2) Slice users - use MBR schema + BSD schema > > With very little effort, we can make the OS cater to the third kind of > users : partition users (use MBR + EBR - no BSD). This makes FreeBSD > behaviour same as what other operating systems do - expect the user to > use one of the 3 primary partitions for /, and any extra filesystems > (/usr or /var or swap) optionally needed to be found in the EBR. I do not understand why you need to create the BSD label. Nothing in the GEOM framework is forcing you to do that Is this for a bootable disk or just storage? Regards, Gary From owner-freebsd-fs@freebsd.org Sun Jul 8 23:34:12 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 018DB104400E for ; Sun, 8 Jul 2018 23:34:12 +0000 (UTC) (envelope-from jude.obscure@yandex.com) Received: from forward100j.mail.yandex.net (forward100j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D32D73098; Sun, 8 Jul 2018 23:34:11 +0000 (UTC) (envelope-from jude.obscure@yandex.com) Received: from mxback2j.mail.yandex.net (mxback2j.mail.yandex.net [IPv6:2a02:6b8:0:1619::10b]) by forward100j.mail.yandex.net (Yandex) with ESMTP id 714445D82AB8; Mon, 9 Jul 2018 02:34:08 +0300 (MSK) Received: from smtp4o.mail.yandex.net (smtp4o.mail.yandex.net [2a02:6b8:0:1a2d::28]) by mxback2j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id pPWh9I7fcT-Y84eG1r5; Mon, 09 Jul 2018 02:34:08 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1531092848; bh=h5G3JykqdWSbO/1z7pbTLTdsGt3vD8tiPu9PGIDyBdo=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=DPPuOJVxFe/yfNy4Ei9DJw4Mdvg+P1byHrMNUvjSrvzCzUnym1pTYrSGEiK2h9C4u 7CNHtBJ2CvXWk44YIk2dnBgU06hK4lizUlQpKEhH/DmLDlWpgphIDLyL/eTpUGnCom 6RbN0M48fOnL1tJgVnJLwu7sbtv4WNBh3fuHOd2M= Received: by smtp4o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 6XYPSudFLI-Y6xmVvnT; Mon, 09 Jul 2018 02:34:07 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1531092847; bh=h5G3JykqdWSbO/1z7pbTLTdsGt3vD8tiPu9PGIDyBdo=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=AVwhdVSSXnNN6K0SGJ/R6qQnJZPzYvykmf7Pw5c3k7aqVPMJKhTRFR8iQ3Sad7HCM 6N6S15dPpfHaNGO6VMUuJHJFJjMdw3KWHolMUN4qh85qLgaURz7qhkJ8Filp+QulwN 5SOcNWw5X4r06HtW15hghsv1L+fuTT9g8X1PcYrc= Authentication-Results: smtp4o.mail.yandex.net; dkim=pass header.i=@yandex.com Subject: Re: A request for unnested UFS implementation in MBR To: Gary Palmer Cc: Ronald Klop , freebsd-fs@freebsd.org References: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> <20180708230442.GB47960@in-addr.com> From: Manish Jain Message-ID: <651087d5-00ab-7fd4-bc05-b25941c9099d@yandex.com> Date: Mon, 9 Jul 2018 05:02:03 +0530 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180708230442.GB47960@in-addr.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 23:34:12 -0000 On 07/09/18 04:34, Gary Palmer wrote: > I do not understand why you need to create the BSD label. Nothing > in the GEOM framework is forcing you to do that > > Is this for a bootable disk or just storage? Perhaps my understanding of the situation was incomplete. Following up on your reply, I see that creating UFS directly on the freebsd slice does seem to work well: /root <<: gpart destroy -F da0 da0 destroyed /root <<: ls /dev/da* /dev/da0 /root <<: gpart create -s MBR da0 da0 created /root <<: gpart add -t freebsd da0 da0s1 added /root <<: newfs /dev/da0s1 1) Is that a standard, acceptable way of working with UFS ? I have always thought the only way to use UFS under MBR was to first a BSD nest. 2) And also, I think cannot get that behaviour during FreeBSD installation with MBR + UFS, which stills leads to creation of the unnecessary 'a' device when a user installs FreeBSD on a single, primary partition. Your answer - and my interpretation thereof - means possibly things are just fine the way they are : - ) Thanks for replying. Manish Jain From owner-freebsd-fs@freebsd.org Mon Jul 9 01:30:54 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25C5C102C6A6 for ; Mon, 9 Jul 2018 01:30:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B23A077E72 for ; Mon, 9 Jul 2018 01:30:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 72E44102C6A2; Mon, 9 Jul 2018 01:30:53 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60A7B102C6A0 for ; Mon, 9 Jul 2018 01:30:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3ADF77E69 for ; Mon, 9 Jul 2018 01:30:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 44DBB1C11F for ; Mon, 9 Jul 2018 01:30:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w691UqiE037112 for ; Mon, 9 Jul 2018 01:30:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w691UqG8037111 for fs@FreeBSD.org; Mon, 9 Jul 2018 01:30:52 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 229614] ZFS lockup in zil_commit_impl Date: Mon, 09 Jul 2018 01:30:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 01:30:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229614 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Jul 9 02:44:14 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC30910337C6 for ; Mon, 9 Jul 2018 02:44:13 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 34BC57AFB2; Mon, 9 Jul 2018 02:44:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id C90C91A06DE; Mon, 9 Jul 2018 12:44:01 +1000 (AEST) Date: Mon, 9 Jul 2018 12:44:00 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Gary Palmer cc: Manish Jain , freebsd-fs@freebsd.org Subject: Re: A request for unnested UFS implementation in MBR In-Reply-To: <20180708230442.GB47960@in-addr.com> Message-ID: <20180709115446.X1055@besplex.bde.org> References: <98201d37-2d65-34c6-969e-c9649f1a3ab1@yandex.com> <20180708230442.GB47960@in-addr.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=I9sVfJog c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=i2cwMrNwGjVwdpcxgCsA:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 02:44:14 -0000 On Mon, 9 Jul 2018, Gary Palmer wrote: > On Mon, Jul 09, 2018 at 03:05:35AM +0530, Manish Jain wrote: >> ... >> I will reply to all the answers (which accumulated as I had a very nice >> long sleep, thank you) to this thread here. >> >> This is what I get currently applying gpart to my USB pen drive: >> >> /root <<: gpart create -s MBR da0 >> da0 created >> /root <<: gpart add -t linux-data -s 1G da0 >> da0s1 added >> /root <<: gpart add -t freebsd-ufs -s 1G da0 >> gpart: Invalid argument # WHY ? > > As I said in my email, freebsd-ufs is a GPT ID. MBR has a very > restricted set of what is considered valid - from memory it's a single > byte. That means freebsd-swap, freebsd-zfs, freebsd-ufs, etc aren't > valid. > >> It currently is a real bother having to create UFS, with a whole lot of >> extra commands: >> >> /root <<: gpart add -t freebsd -s 1G da0 >> da0s2 added >> /root <<: gpart create -s BSD da0s2 >> da0s2 created >> /root <<: gpart add -t freebsd-ufs da0s2 >> da0s2a added > > There is nothing forcing you to create the BSD label > > # mdconfig -s 512m > md0 > # gpart create -s MBR md0 > md0 created > # gpart add -t freebsd md0 > md0s1 added > # newfs /dev/md0s1 > /dev/md0s1: 512.0MB (1048560 sectors) block size 32768, fragment size 4096 > using 4 cylinder groups of 128.00MB, 4096 blks, 16384 inodes. > super-block backups (for fsck_ffs -b #) at: > 192, 262336, 524480, 786624 > # mount /dev/md0s1 /mnt What is all this messing around with gpart? ffs works on any seekable file, and so does newfs. A unpartitioned disk is the easiest case: Script started on Mon Jul 9 11:51:49 2018 ttyv1:root@besplex:/tmp/u5> mdconfig -a -t malloc -s 512k md0 ttyv1:root@besplex:/tmp/u5> gpart bash: gpart: command not found # gpart doesn't exist on my de-geomed systems ttyv1:root@besplex:/tmp/u5> newfs /dev/md0 /dev/md0: 0.5MB (1024 sectors) block size 16384, fragment size 2048 using 1 cylinder groups of 0.50MB, 32 blks, 64 inodes. super-block backups (for fsck -b #) at: 160 ttyv1:root@besplex:/tmp/u5> fsck_ffs /dev/md0 ** /dev/md0 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 2 files, 2 used, 189 free (21 frags, 21 blocks, 11.0% fragmentation) ttyv1:root@besplex:/tmp/u5> mdconfig -d -u 0 ttyv1:root@besplex:/tmp/u5> exit Script done on Mon Jul 9 11:52:24 2018 If the device has to be partitioned starting with an MBR, then things get complicated. I avoid using EBRs except for testing them when I implemented them for FreeBSD in ~1994. FreeBSD's fdisk can't create EBRs and is hard enough to use for MBRs. If you want simplicity, then don't partition the disk. This requires some magic for booting. fdisk generates a fake MBR the same as in ~1992 where it was used more before proper MBR partitioning was implemented. Newer BIOSes might have problems with the fake MBR. I partition all disks except floppies and cd/dvd's and virtual (md) ones. Not partitioning worked better with smaller disks. Now with multi-terabyte disks, partitions are more needed. However, with large disks there is more space to get lost in if you have a complicated partitioning scheme. >> The extra commands mean that when a user wants to quickly put a >> partition on a disk of any kind, it is much easier using Ext2. >> >> If the original command (highlighted with WHY ?) could succeed as such >> (or perhaps with a slight alteration: gpart add -t ufs -s 1G da0), UFS >> becomes as convenient as Ext2 for general purpose usage. >> >> There is another way to think about the situation. >> >> FreeBSD currently caters to only 2 types of users: >> >> 1) Dedicated disk users - use BSD schema >> >> 2) Slice users - use MBR schema + BSD schema >> >> With very little effort, we can make the OS cater to the third kind of >> users : partition users (use MBR + EBR - no BSD). This makes FreeBSD >> behaviour same as what other operating systems do - expect the user to >> use one of the 3 primary partitions for /, and any extra filesystems >> (/usr or /var or swap) optionally needed to be found in the EBR. The kernel has supported MBR + EBR since ~1994. Utility and installer support is not so good (I used DOS fdisk to created EBRs for testing in ~1994). > I do not understand why you need to create the BSD label. Nothing > in the GEOM framework is forcing you to do that > > Is this for a bootable disk or just storage? Bruce From owner-freebsd-fs@freebsd.org Mon Jul 9 07:30:47 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0C591029BE0 for ; Mon, 9 Jul 2018 07:30:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 27F68871B9 for ; Mon, 9 Jul 2018 07:30:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id D5AAF1029BDB; Mon, 9 Jul 2018 07:30:46 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C33F21029BDA for ; Mon, 9 Jul 2018 07:30:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61591871B5 for ; Mon, 9 Jul 2018 07:30:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id A60E41F479 for ; Mon, 9 Jul 2018 07:30:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w697UjGU028356 for ; Mon, 9 Jul 2018 07:30:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w697UjJl028355 for fs@FreeBSD.org; Mon, 9 Jul 2018 07:30:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 229614] ZFS lockup in zil_commit_impl Date: Mon, 09 Jul 2018 07:30:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 07:30:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229614 --- Comment #7 from Andriy Gapon --- (In reply to Michael Gmelin from comment #5) I am confident that it's the same bug. I think that it is a deadlock between a thread like the one from comment #0= and a thread like this: zfs_zget+0x1b4 zfs_get_data+0x7c zil_commit+0x926 zfs_sync+0xad sys_sync+0x= e6 amd64_syscall+0x2f6 Xfast_syscall+0xfb The first thread is waiting on zil_commit in the second thread to complete. At the same time the second thread is waiting (in zfs_zget) on the first th= read to finish reclaiming the vnode. I think I understand the problem, but I do not see an easy way to fix it. Checking the vnode state in zil_commit -> zfs_get_data -> zfs_zget is problematic as zil_commit can be called from vnode operations while an arbitrary other vnode is locked. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Jul 9 10:06:23 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88BD9103A32D for ; Mon, 9 Jul 2018 10:06:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1C9208F358 for ; Mon, 9 Jul 2018 10:06:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id D1896103A32A; Mon, 9 Jul 2018 10:06:22 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BECAA103A328 for ; Mon, 9 Jul 2018 10:06:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5ACFA8F352 for ; Mon, 9 Jul 2018 10:06:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 7F31B209B0 for ; Mon, 9 Jul 2018 10:06:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w69A6L3U050705 for ; Mon, 9 Jul 2018 10:06:21 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w69A6LC2050704 for fs@FreeBSD.org; Mon, 9 Jul 2018 10:06:21 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 229614] ZFS lockup in zil_commit_impl Date: Mon, 09 Jul 2018 10:06:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: grembo@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 10:06:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229614 --- Comment #8 from Michael Gmelin --- (In reply to Andriy Gapon from comment #7) Given this fact, do you think that there are 1. Ways to prevent such an interlocked in production (e.g. by avoiding certain operations) 2. Ways an unprivileged user could use this to break a system 3. Ways to still use 11.2 with ZFS in production 4. Reasons to add this to the release errata section Thanks, Michael --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Wed Jul 11 11:10:32 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFDC2102D87A for ; Wed, 11 Jul 2018 11:10:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 883F18B4D0 for ; Wed, 11 Jul 2018 11:10:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 488EF102D878; Wed, 11 Jul 2018 11:10:31 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36352102D876 for ; Wed, 11 Jul 2018 11:10:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7CBE8B4CE for ; Wed, 11 Jul 2018 11:10:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id F14161A5E9 for ; Wed, 11 Jul 2018 11:10:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w6BBATL4099045 for ; Wed, 11 Jul 2018 11:10:29 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w6BBATbO099044 for fs@FreeBSD.org; Wed, 11 Jul 2018 11:10:29 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 229694] [zfs] unkillable "zpool scrub" in [tx->tx_sync_done_cv] state for damaged data Date: Wed, 11 Jul 2018 11:10:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: stable@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 11:10:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229694 Bug ID: 229694 Summary: [zfs] unkillable "zpool scrub" in [tx->tx_sync_done_cv] state for damaged data Product: Base System Version: 11.2-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: stable@FreeBSD.org Reporter: eugen@freebsd.org CC: fs@FreeBSD.org Hi! "zpool scrub" may hang in an uninterruptable disk i/o state in case of dama= ged pool data for 11.2-STABLE/amd64 r335757. This is easily reproduceable using file-backed ZFS pool when files reside on another ("real") pool: cd dir # resides on ZFS size=3D100 rm -f vdev1 vdev2 truncate -s ${size}m vdev1 vdev2 zpool create ztest $(realpath vdev1) zpool add ztest $(realpath vdev2) # simulate data corruption dd if=3D/dev/urandom of=3Dvdev2 bs=3D1m count=3D${size} zpool scrub ztest The last command "zpool scrub" always hangs here: load: 0.53 cmd: zpool 2130 [tx->tx_sync_done_cv] 34.59r 0.00u 0.00s 0% 369= 2k "kill -9" cannot kill it. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Wed Jul 11 12:08:50 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFF57103467A for ; Wed, 11 Jul 2018 12:08:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 896A08E40F for ; Wed, 11 Jul 2018 12:08:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3FE5A1034671; Wed, 11 Jul 2018 12:08:49 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D97F103466F for ; Wed, 11 Jul 2018 12:08:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BDCB38E408 for ; Wed, 11 Jul 2018 12:08:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 08BF61AE42 for ; Wed, 11 Jul 2018 12:08:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w6BC8l6N063671 for ; Wed, 11 Jul 2018 12:08:47 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w6BC8lZ7063663 for fs@FreeBSD.org; Wed, 11 Jul 2018 12:08:47 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 229694] [zfs] unkillable "zpool scrub" in [tx->tx_sync_done_cv] state for damaged data Date: Wed, 11 Jul 2018 12:08:48 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: stable@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 12:08:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229694 --- Comment #1 from Andriy Gapon --- I am not too surprised. The pool configuration is not redundant and the wh= ole top level vdev is corrupted. I suspect that the scrub command needs to wri= te something to the pool to record the initial scrub state. And it's quite li= kely that it needs to perform Read-Modify-Write. And the read fails and the pool gets suspended. zpool scrub command is stuck waiting for confirmation that= the scrub is actually started. procstat -kk -a would paint a fuller picture. Maybe there is something reported in dmesg too, but not sure. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Wed Jul 11 12:41:25 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4CB141039BC9 for ; Wed, 11 Jul 2018 12:41:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 05EE48F9D0 for ; Wed, 11 Jul 2018 12:41:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id BAC5F1039BC5; Wed, 11 Jul 2018 12:41:24 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A91B71039BC1 for ; Wed, 11 Jul 2018 12:41:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10EE28F9C3 for ; Wed, 11 Jul 2018 12:41:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 5D2361B2AD for ; Wed, 11 Jul 2018 12:41:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w6BCfNti036200 for ; Wed, 11 Jul 2018 12:41:23 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w6BCfNLX036197 for fs@FreeBSD.org; Wed, 11 Jul 2018 12:41:23 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 229694] [zfs] unkillable "zpool scrub" in [tx->tx_sync_done_cv] state for damaged data Date: Wed, 11 Jul 2018 12:41:22 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 12:41:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229694 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|stable@FreeBSD.org |fs@FreeBSD.org CC|fs@FreeBSD.org | --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Wed Jul 11 13:58:24 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D5D81040120 for ; Wed, 11 Jul 2018 13:58:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EE41A72CD3 for ; Wed, 11 Jul 2018 13:58:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id AED5D104011A; Wed, 11 Jul 2018 13:58:23 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C8AC1040119 for ; Wed, 11 Jul 2018 13:58:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39A4772CCE for ; Wed, 11 Jul 2018 13:58:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 641D11BD9E for ; Wed, 11 Jul 2018 13:58:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w6BDwMCs060761 for ; Wed, 11 Jul 2018 13:58:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w6BDwM4c060760 for fs@FreeBSD.org; Wed, 11 Jul 2018 13:58:22 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 229694] [zfs] unkillable "zpool scrub" in [tx->tx_sync_done_cv] state for damaged data Date: Wed, 11 Jul 2018 13:58:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 13:58:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229694 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stable@FreeBSD.org --- Comment #2 from Eugene Grosbein --- (In reply to Andriy Gapon from comment #1) Nothing in the dmesg output. Procstat output is huge, so I compressed it, s= ee attachment. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Wed Jul 11 13:58:58 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05E1C104026A for ; Wed, 11 Jul 2018 13:58:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 93EF772DC4 for ; Wed, 11 Jul 2018 13:58:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 581191040267; Wed, 11 Jul 2018 13:58:57 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4439C1040266 for ; Wed, 11 Jul 2018 13:58:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0FA472DBF for ; Wed, 11 Jul 2018 13:58:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 295AE1BDA2 for ; Wed, 11 Jul 2018 13:58:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w6BDwuuF061391 for ; Wed, 11 Jul 2018 13:58:56 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w6BDwuhI061388 for fs@FreeBSD.org; Wed, 11 Jul 2018 13:58:56 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 229694] [zfs] unkillable "zpool scrub" in [tx->tx_sync_done_cv] state for damaged data Date: Wed, 11 Jul 2018 13:58:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 13:58:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229694 --- Comment #3 from Eugene Grosbein --- Created attachment 195052 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D195052&action= =3Dedit procstat -kk -a output --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Jul 12 06:25:04 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C09E10343C7 for ; Thu, 12 Jul 2018 06:25:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C098D7F270 for ; Thu, 12 Jul 2018 06:25:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7C39110343C6; Thu, 12 Jul 2018 06:25:03 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A99A10343C5 for ; Thu, 12 Jul 2018 06:25:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 018DE7F26F for ; Thu, 12 Jul 2018 06:25:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 2C3C824787 for ; Thu, 12 Jul 2018 06:25:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w6C6P2v0068769 for ; Thu, 12 Jul 2018 06:25:02 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w6C6P23B068768 for fs@FreeBSD.org; Thu, 12 Jul 2018 06:25:02 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 196799] Lock order reversal after shutting down ZFS root system. Date: Thu, 12 Jul 2018 06:25:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: yasu@utahime.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 06:25:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D196799 Yasuhiro KIMURA changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |Not A Bug --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Jul 12 19:28:16 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CC86103AAB4 for ; Thu, 12 Jul 2018 19:28:16 +0000 (UTC) (envelope-from thomas@bsdunix.ch) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 07BCD7B5EE for ; Thu, 12 Jul 2018 19:28:16 +0000 (UTC) (envelope-from thomas@bsdunix.ch) Received: by mailman.ysv.freebsd.org (Postfix) id BA6D1103AAAB; Thu, 12 Jul 2018 19:28:15 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 784E2103AA96 for ; Thu, 12 Jul 2018 19:28:15 +0000 (UTC) (envelope-from thomas@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 090277B5EB for ; Thu, 12 Jul 2018 19:28:14 +0000 (UTC) (envelope-from thomas@bsdunix.ch) Received: from [172.15.10.102] (dynamic-82-220-88-115.ftth.solnet.ch [82.220.88.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.bsdunix.ch (Postfix) with ESMTPSA id 18FF324791 for ; Thu, 12 Jul 2018 19:28:05 +0000 (UTC) From: freebsdlists@bsdunix.ch To: fs@FreeBSD.org Subject: zpool import failes with internal error: Unknown Error 122 Message-ID: <955e2c37-d3c8-3e76-67bc-1ff8c61a653a@bsdunix.ch> Date: Thu, 12 Jul 2018 21:28:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_50, RDNS_NONE, TW_TX, TW_ZD autolearn=no autolearn_force=no X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on conversation.bsdunix.ch X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 19:28:16 -0000 Hi, I can't import an exported raidz1 pool based on 4 disk. An zpool export was done with Freebsd 11.2 and an import too. One disk (ada3 aka /dev/diskid/DISK-ZA18YNHS) was marked as unavailable before the export was done. This particular disk was offlined before the export and a zpool labelclear ada3 was done too before the export. I'm unable to import the pool again. 3 of 4 disk are available in raidz1 "zool import storage" command: pool: storage id: 9514877379131531055 state: FAULTED status: One or more devices are missing from the system. action: The pool cannot be imported. Attach the missing devices and try again. see: http://illumos.org/msg/ZFS-8000-3C config: storage FAULTED corrupted data raidz1-0 FAULTED corrupted data 1800501377521064476 UNAVAIL cannot open diskid/DISK-ZA16XZW9 ONLINE diskid/DISK-ZA18JE4E ONLINE diskid/DISK-ZA18Z0L1 ONLINE Disk 1800501377521064476 is ada3 aka /dev/diskid/DISK-ZA18YNH. I tried to import the pool with -F, -fF, -FfX ... zool import -f storage fails too. internal error: Unknown Error 122 Abort (core dumped) Zdb showes: zdb -Fe storage gives: Configuration for import: vdev_children: 1 version: 5000 pool_guid: 9514877379131531055 name: 'storage' state: 1 hostid: 2232729950 hostname: 'my.machine.com' vdev_tree: type: 'root' id: 0 guid: 9514877379131531055 children[0]: type: 'raidz' id: 0 guid: 12743926568081883225 nparity: 1 metaslab_array: 40 metaslab_shift: 38 ashift: 12 asize: 32006233653248 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 1800501377521064476 path: '/dev/diskid/DISK-ZA18YNHS' whole_disk: 1 DTL: 58 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 3017550635642283205 whole_disk: 1 DTL: 57 create_txg: 4 path: '/dev/diskid/DISK-ZA16XZW9' children[2]: type: 'disk' id: 2 guid: 1070420248480515562 whole_disk: 1 DTL: 56 create_txg: 4 path: '/dev/diskid/DISK-ZA18JE4E' children[3]: type: 'disk' id: 3 guid: 1151953985479393249 whole_disk: 1 DTL: 55 create_txg: 4 path: '/dev/diskid/DISK-ZA18Z0L1' ZFS_DBGMSG(zdb): spa_import: importing storage, max_txg=-1 (RECOVERY MODE) spa_load(storage, config trusted): LOADING disk vdev '/dev/diskid/DISK-ZA18YNHS': vdev_validate: failed reading config disk vdev '/dev/diskid/DISK-ZA16XZW9': best uberblock found for spa storage. txg 3652256 spa_load(storage, config untrusted): using uberblock with txg=3652256 vdev_copy_path: vdev 3017550635642283205: path changed from '/dev/ada2' to '/dev/diskid/DISK-ZA16XZW9' vdev_copy_path: vdev 1070420248480515562: path changed from '/dev/ada3' to '/dev/diskid/DISK-ZA18JE4E' disk vdev '/dev/diskid/DISK-ZA18YNHS': vdev_validate: failed reading config raidz-0 vdev (guid 12743926568081883225): metaslab_init failed [error=122] raidz-0 vdev (guid 12743926568081883225): vdev_load: metaslab_init failed [error=122] spa_load(storage, config trusted): FAILED: vdev_load failed [error=122] spa_load(storage, config trusted): UNLOADING spa_load(storage, config trusted): spa_load_retry: rewind, max txg: 3652255 spa_load(storage, config trusted): LOADING disk vdev '/dev/diskid/DISK-ZA18YNHS': vdev_validate: failed reading config disk vdev '/dev/diskid/DISK-ZA16XZW9': best uberblock found for spa storage. txg 3652253 disk vdev '/dev/diskid/DISK-ZA16XZW9': failed to read label config spa_load(storage, config untrusted): using uberblock with txg=3652253 spa_load(storage, config untrusted): FAILED: label config unavailable spa_load(storage, config untrusted): UNLOADING Any idea if this can be fixed and how? 3 out of 4 disk the raidz1 are fine. Regards, Tom From owner-freebsd-fs@freebsd.org Fri Jul 13 11:38:08 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55B701035954 for ; Fri, 13 Jul 2018 11:38:08 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:375::1:5]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C106081B04 for ; Fri, 13 Jul 2018 11:38:07 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Fri, 13 Jul 2018 13:12:27 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1531481886; bh=PDC/E9nG1xjNLOIU0N4XvqUHl8PNzCUCRpP2BtpkSv8=; h=Date:From:To:Subject; b=vCMR6YZhiz0OoUAa7eA9ttlZfofkKNwIIIjv3Y3V7gNuFyFFtZ7/EwTUDknLMqJfe e0DMen2os2bcNG8aZ+lqbyNh3anj2+n+2/u5Odg1BGHuVEGQz/25lzquuj2k+gyvdV ZMo0MOKQ5DS2ND0ZvIqkbzC/lglFN0vXFLuxazcYT1bySdHAKWpjW7llX20E2F89j7 2j/v6SHrG3WgZRpEga1Mw+vcQJLZhW2NzQHvBIc7K7TXSQ5/snonVp6hD7nHPiLhLu 3xwAbSZC30beHukr5gc1bX+crTIzWPpCJDGgzEPBiril0BC6uEvRulCuMdzJe3K3nx dkr13h60jck1g== Message-ID: <20180713131227.Horde.S0gjPFGdZFb-68KklzQBXig@webmail.leidinger.net> From: Alexander Leidinger To: freebsd-fs@freebsd.org Subject: solaris assert triggered after panic in ZFS at mount time User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_rELKE2e2SIl2I_KIBI1orEV"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 11:38:08 -0000 This message is in MIME format and has been PGP signed. --=_rELKE2e2SIl2I_KIBI1orEV Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, This is with r336194. I have a dataset which panics the machine at mount time (during reboot=20= =20 after=20a panic): ---snip--- panic: solaris assert: dmu_object_claim(zfsvfs->z_os, obj,=20=20 DMU_OT_PLAIN_FILE_CONTENTS,=200, obj_type, bonuslen, tx) =3D=3D 0 (0x11 =3D= =3D=20=20 0x0),=20file:=20=20 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c,=20=20 line:=20819 cpuid =3D 2 time =3D 1531477050 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe009ab62= a00 vpanic() at vpanic+0x1a3/frame 0xfffffe009ab62a60 panic() at panic+0x43/frame 0xfffffe009ab62ac0 assfail3() at assfail3+0x2c/frame 0xfffffe009ab62ae0 zfs_mknode() at zfs_mknode+0x1a1/frame 0xfffffe009ab62f30 zfs_freebsd_create() at zfs_freebsd_create+0x56f/frame 0xfffffe009ab63000 VOP_CREATE_APV() at VOP_CREATE_APV+0xd3/frame 0xfffffe009ab63030 zfs_replay_create() at zfs_replay_create+0x60b/frame 0xfffffe009ab63250 zil_replay_log_record() at zil_replay_log_record+0x215/frame=20=20 0xfffffe009ab633a0 zil_parse()=20at zil_parse+0x2b5/frame 0xfffffe009ab635a0 zil_replay() at zil_replay+0xec/frame 0xfffffe009ab63600 zfsvfs_setup() at zfsvfs_setup+0xb5/frame 0xfffffe009ab63630 zfs_mount() at zfs_mount+0x72f/frame 0xfffffe009ab637c0 vfs_domount() at vfs_domount+0x734/frame 0xfffffe009ab639e0 vfs_donmount() at vfs_donmount+0x807/frame 0xfffffe009ab63a90 sys_nmount() at sys_nmount+0x50/frame 0xfffffe009ab63ac0 amd64_syscall() at amd64_syscall+0x263/frame 0xfffffe009ab63bf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe009ab63bf0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip =3D 0x800369b3a, rsp =3D= =20=20 0x7fffffffca98,=20rbp =3D 0x7fffffffcb10 --- 230 __asm("movq %%gs:%1,%0" : "=3Dr" (td) (kgdb) #0 __curthread () at ./machine/pcpu.h:230 #1 doadump (textdump=3D1) at /usr/src/sys/kern/kern_shutdown.c:366 #2 0xffffffff80485e11 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:446 #3 0xffffffff804863f3 in vpanic (fmt=3D, ap=3D0xfffffe009ab= 62aa0) at /usr/src/sys/kern/kern_shutdown.c:863 #4 0xffffffff80486443 in panic (fmt=3D) at /usr/src/sys/kern/kern_shutdown.c:790 #5 0xffffffff817c524c in assfail3 (a=3D, lv=3D, op=3D, rv=3D, f=3D, l=3D) at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:91 #6 0xffffffff81445641 in zfs_mknode (dzp=3D0xfffff8007644fc60, vap=3D0xfffffe009ab630f8, tx=3D0xfffff8019fcbbb00, cr=3D0xfffff8000206= 8000, flag=3D0, zpp=3D0xfffffe009ab62fb8, acl_ids=3D0xfffffe009ab62f58) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c= :817 #7 0xffffffff81485b1f in zfs_create ( excl=3D, mode=3D, dvp=3D, name=3D, vap=3D, vpp=3D, cr=3D, td=3D) at=20=20 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1883 #8=20 zfs_freebsd_create (ap=3D) at=20=20 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4995 #9=20 0xffffffff807c16f3 in VOP_CREATE_APV (vop=3D, a=3D0xfffffe009ab63098) at vnode_if.c:263 #10 0xffffffff8147c4bb in VOP_CREATE (dvp=3D, vpp=3D0x0, cnp=3D0xffffffff8082c59a, vap=3D0x1a400000001) at ./vnode_if.h:109 #11 zfs_replay_create (arg1=3D, arg2=3D, byteswap=3D) at=20=20 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_replay.c:505 #12=200xffffffff8144e9d5 in zil_replay_log_record (zilog=3D0xfffff80048f54c= 00, lr=3D0xfffffe00c7880000, zra=3D, claim_txg=3D) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c:3243 #13 0xffffffff81449d65 in zil_parse (zilog=3D0xfffff80048f54c00, parse_blk_func=3D0xffffffff8144e7b0 , parse_lr_func=3D0xffffffff8144e7c0 , arg=3D0xfffffe009ab635c0, txg=3D11396685) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c:383 #14 0xffffffff8144e76c in zil_replay (os=3D, arg=3D0xfffffe00ab6be000, replay_func=3D0xffffffff8154b9b0=20=20 ) =20 at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c:329= 7 #15 0xffffffff81482515 in zfsvfs_setup (zfsvfs=3D0xfffffe00ab6be000, mounti= ng=3D1) at=20=20 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1278 #16=200xffffffff8147fb9f in zfs_domount (vfsp=3D, osname=3D) at=20=20 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1433 #17=20zfs_mount (vfsp=3D0xfffff80076958000) at=20=20 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1915 #18=200xffffffff8054e714 in vfs_domount_first (td=3D, fspath=3D, vp=3D, optlist=3D0xfffffe009a= b63a28, vfsp=3D, fsflags=3D) at /usr/src/sys/kern/vfs_mount.c:892 #19 vfs_domount (td=3D0xfffff8004ebcb000, fstype=3D, fspath=3D, fsflags=3D, (kgdb) up 6 #6 0xffffffff81445641 in zfs_mknode (dzp=3D0xfffff8007644fc60,=20=20 vap=3D0xfffffe009ab630f8, tx=3D0xfffff8019fcbbb00, cr=3D0xfffff80002068000, flag=3D0, zpp=3D0xfffffe009ab62fb8,=20=20 acl_ids=3D0xfffffe009ab62f58) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c= :817 817 VERIFY0(dmu_object_claim(zfsvfs->z_os, obj, (kgdb) list 812 zfsvfs->z_norm, DMU_OT_DIRECTORY_CONTEN= TS, 813 obj_type, bonuslen, tx); 814 } 815 } else { 816 if (zfsvfs->z_replay) { 817 VERIFY0(dmu_object_claim(zfsvfs->z_os, obj, 818 DMU_OT_PLAIN_FILE_CONTENTS, 0, 819 obj_type, bonuslen, tx)); 820 } else { 821 obj =3D dmu_object_alloc(zfsvfs->z_os, (kgdb) print obj $2 =3D 16393 (kgdb) print zfsvfs $3 =3D (zfsvfs_t *) 0xfffffe00ab6be000 (kgdb) print obj_type $4 =3D DMU_OT_SA (kgdb) print bonuslen $5 =3D (kgdb) print tx $6 =3D (dmu_tx_t *) 0xfffff8019fcbbb00 ---snip--- Which options do I have to fix this (instead of destroying it)? I tried already this: zdb -AAFdd mpool/iocage/jails/www-f/root/usr but this leads to immediate panic. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_rELKE2e2SIl2I_KIBI1orEV Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJbSIkbAAoJEKrxQhqFIICEsiUP/2uoa6tF6Ted01elCGDahWx9 anMYj1hHOTaku5gpDXYKFZ07qJuXSMPzVm0Usv2EjGTc/sDzDsutJG5yMNUqfSME lGowux4GIgRA4JA81WIgKkir4rrEjQMQzHbTuWJkiSzy7O43a6Wqj0rSYBzZDdTy m4jra1jGP6m5Dt1etvDcVjqeSGG5dBP+ui8WmkhxTCcWS3+/+FVer8gOHFd/Y8oS lijl9w4pgrcw8ddsJILtC2ToIwdkFipdAzjFD+8h6/oodpf45e20ou/IdOytA0KX Dik2DOZnm32lW0xeLOHXtEVALrxla8Vz+qEUi06PRahzE6+xMazt45nd+VyJIEFh 3/uihQjyQujRCp5YZD9IruwWDzWO0JndMmBVUlo/egir0ZO2nQBCpoTWQ37hRA1l JSJixBhOeedgXh08v26zsLPmRWXd0tW/EtK2OEdz3PuyOV6eH90qOvhVC2TlysWk Cv2AfbXvau7vKXgQfhURv0Lj/fHcVD4SuRFs/9QB1SZtFha95I+BS0G1VdcSICzf c0LvwWxW6ZgBjClUsSKCqwh2BGLVwmWIkb/vFjdjM+URSwgyygNCxlYCBHDXskL0 IZJ27LiAS46v298/7DU9r+fdHa9yOuvxxO0JD4c8I93OowyUOvLekxvNvaKoGVz2 m20ISjxYANHrAv9RvnpG =pHeH -----END PGP SIGNATURE----- --=_rELKE2e2SIl2I_KIBI1orEV-- From owner-freebsd-fs@freebsd.org Fri Jul 13 11:52:48 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A01BD10381B7 for ; Fri, 13 Jul 2018 11:52:48 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E171823E6 for ; Fri, 13 Jul 2018 11:52:47 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f176.google.com with SMTP id t21-v6so24312625lji.0 for ; Fri, 13 Jul 2018 04:52:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=MTJNmqfk2gNE/pmiv21utnvgA80blZwMB0g+R7N/Gb8=; b=qq/c/ULjDl3koScXK0zkO4mwzoOpwE4nas8XZWWwxzKh2E4rEubUK//E6mHEKXPqpG 9aQxeuvaEXlG1djrluhpe+cA9WcDWKRdqKld736O34g7FewdSgzsxwIFwA7syemU+6i0 +3P04ghnYQ1HtEh1UjQ1J4u/ZBw7Rgew3ACC7+84ZpKl90efsnmR10Mwq4G92W2wn/PR zDUUxF+ctiUDmCEI1h5tV5dbzy3ela8Njcd/2nMX1xq2IWGMrtG+EiNOnfYGLpQTgmF8 FXkXgGlathKabe5DE2bRiqcjmwU7UvC2pHQUYZ6M0P2Bo69Bz9BqpMt4+w6nLjmuyegE DngA== X-Gm-Message-State: AOUpUlG6xDIc+jmzYV5ZffSo+o2192aTDvwq9Dl4X5Wyj1gvSGvVXajK oesz/skg8i+9fdzJCTvPUkYluFkg X-Google-Smtp-Source: AAOMgpf3X8faqEgFX46PKazcvUxUSDpX45jX9mbsaLjepI/tKAqixVJlpHbwu5GWWlby6mfGBPAGOw== X-Received: by 2002:a2e:2114:: with SMTP id h20-v6mr3006143ljh.135.1531482422503; Fri, 13 Jul 2018 04:47:02 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id k201-v6sm422247lfe.3.2018.07.13.04.47.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jul 2018 04:47:01 -0700 (PDT) Subject: Re: solaris assert triggered after panic in ZFS at mount time To: Alexander Leidinger , freebsd-fs@freebsd.org References: <20180713131227.Horde.S0gjPFGdZFb-68KklzQBXig@webmail.leidinger.net> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: Date: Fri, 13 Jul 2018 14:47:01 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180713131227.Horde.S0gjPFGdZFb-68KklzQBXig@webmail.leidinger.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 11:52:49 -0000 On 13/07/2018 14:12, Alexander Leidinger wrote: > Hi, > > This is with r336194. > > I have a dataset which panics the machine at mount time (during reboot after a > panic): > ---snip--- > panic: solaris assert: dmu_object_claim(zfsvfs->z_os, obj, > DMU_OT_PLAIN_FILE_CONTENTS, 0, obj_type, bonuslen, tx) == 0 (0x11 == 0x0), file: > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c, line: 819 Hmm, 0x11 == 17 == EEXIST. So, this looks like a possible race in ZIL code. The intent log contains a record to create a file with certain ID, but that file already exists on disk. I don't know what to recommend. Maybe try to import discarding one transaction group... If you can afford losing data from that TXG. > cpuid = 2 > time = 1531477050 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe009ab62a00 > vpanic() at vpanic+0x1a3/frame 0xfffffe009ab62a60 > panic() at panic+0x43/frame 0xfffffe009ab62ac0 > assfail3() at assfail3+0x2c/frame 0xfffffe009ab62ae0 > zfs_mknode() at zfs_mknode+0x1a1/frame 0xfffffe009ab62f30 > zfs_freebsd_create() at zfs_freebsd_create+0x56f/frame 0xfffffe009ab63000 > VOP_CREATE_APV() at VOP_CREATE_APV+0xd3/frame 0xfffffe009ab63030 > zfs_replay_create() at zfs_replay_create+0x60b/frame 0xfffffe009ab63250 > zil_replay_log_record() at zil_replay_log_record+0x215/frame 0xfffffe009ab633a0 > zil_parse() at zil_parse+0x2b5/frame 0xfffffe009ab635a0 > zil_replay() at zil_replay+0xec/frame 0xfffffe009ab63600 > zfsvfs_setup() at zfsvfs_setup+0xb5/frame 0xfffffe009ab63630 > zfs_mount() at zfs_mount+0x72f/frame 0xfffffe009ab637c0 > vfs_domount() at vfs_domount+0x734/frame 0xfffffe009ab639e0 > vfs_donmount() at vfs_donmount+0x807/frame 0xfffffe009ab63a90 > sys_nmount() at sys_nmount+0x50/frame 0xfffffe009ab63ac0 > amd64_syscall() at amd64_syscall+0x263/frame 0xfffffe009ab63bf0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe009ab63bf0 > --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800369b3a, rsp = > 0x7fffffffca98, rbp = 0x7fffffffcb10 --- -- Andriy Gapon From owner-freebsd-fs@freebsd.org Fri Jul 13 12:25:27 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D7CA103A5CA for ; Fri, 13 Jul 2018 12:25:27 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 246F783783; Fri, 13 Jul 2018 12:25:26 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Fri, 13 Jul 2018 14:25:01 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1531484718; bh=h1iDNSkIIaakdjOTqZwncqhom2g2K9lHmeLUH8gsddc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=dvZGFY2rk6TdEcokz3h6w4KpYK4V3rswGJXPq4uyklrb5Z1x4DOURrDDEmyDDNYIy 6y/WXSydetHStGIp2bzhUkSXYtYVBgSO7X6tnm2T+cZ60KZ4vGl/yTRoWkIoqk6g5v /n7d+8aenkwNoFn7MFw0vvdHyGgVzCc07cTq8hX9jrK4MQMi4prf/S5BTkU65bmT+9 bErcCKBh+lBZDfvEeuDNFfD/npRb/M6k0unzjK9w16lcGy468TIqqrx5fFXKYWinNq 1xNe58cT94nLB4bO6xfVgYS5RY+0jEvlcKXQ7VjibbR+biICZ5BD1Z0MAGcVehKcWu ibEw5Gyswllow== Message-ID: <20180713142501.Horde.wIa6K9TandOzeMp5wYrvZjE@webmail.leidinger.net> From: Alexander Leidinger To: Andriy Gapon Cc: freebsd-fs@freebsd.org Subject: Re: solaris assert triggered after panic in ZFS at mount time References: <20180713131227.Horde.S0gjPFGdZFb-68KklzQBXig@webmail.leidinger.net> In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_8bxwBC2XGoRk64zBzT069Nw"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 12:25:27 -0000 This message is in MIME format and has been PGP signed. --=_8bxwBC2XGoRk64zBzT069Nw Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Andriy Gapon (from Fri, 13 Jul 2018 14:47:01 +030= 0): > On 13/07/2018 14:12, Alexander Leidinger wrote: >> Hi, >> >> This is with r336194. >> >> I have a dataset which panics the machine at mount time (during=20=20 >>=20reboot after a >> panic): >> ---snip--- >> panic: solaris assert: dmu_object_claim(zfsvfs->z_os, obj, >> DMU_OT_PLAIN_FILE_CONTENTS, 0, obj_type, bonuslen, tx) =3D=3D 0 (0x11=20= =20 >>=20=3D=3D 0x0), file: >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c, lin= e:=20=20 >>=20819 > > Hmm, 0x11 =3D=3D 17 =3D=3D EEXIST. > So, this looks like a possible race in ZIL code. The intent log contains= a > record to create a file with certain ID, but that file already=20=20 >=20exists on disk. > I don't know what to recommend. Maybe try to import discarding one=20=20 >=20transaction > group... If you can afford losing data from that TXG. Yes, I can afford losing data, it's mainly usr/local of a jail and=20=20 usr/local/etc=20I have in a backup. I'm rebuilding it and I would like=20= =20 to=20compare that I didn't miss something. This is a root pool of a server without local access, how do I get rid=20= =20 of=20TXG of a dataset of an already imported pool (no possibility to=20=20 have=20this pool accessed in an exported state)? Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_8bxwBC2XGoRk64zBzT069Nw Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJbSJodAAoJEKrxQhqFIICE7zUP/0TFWrrx0uS8MezE0V9oVZEO 4bAnc1lP7s0unzPUwzShgNFAW/7qzpejWXVrcMGYBSbaeZ97G3WhzPEl9IdCK4xb P0IfcaEzeYDeit6YVLF04F2qr1XoQkb7d4NCi6gbECDFHnK7cExPde6vwAJMa7cB TwHOPicxq7GTJEvUdJVeVZJnZr4lvZrlhYu/Mg2jrDj25kFMdT33ybxAuRcc8BFE +xmU791W1/QP3FQUw0M3y6JOhyLfTWLHzyl2W3mLe8gYqXEJhKH22WIllujV3KK8 9WvXVWVAXv5S3iw6tmmKgfFkd1OhuVsAWaszgF4jgR0jX34+ONlpApE/FHhqq/jn fX63IvCxaWIlejVj6YI2N/g/XqMwGhku3dMIvPvtDJDFzvGoTFQbA1FkqUF3LHyc KlnGhFZ5cScnQNrteoCuAebVagyhQ79yTxDftsroLIApRYxn3d+aOLTxQvySKutw xcbsrkr6G3xNFJrwFKNGX1qXDE1YiTSW/KTxlb9R5wRxKozymXrzlJFPdtT1hXPk 7xfOZyZJQwvhO9ZMBRd/zAF61wYT8bViT1ayuFIydl7Vo6bN20fxUnW0H/QkB39k PLxbBRm6pJlytXBEa1wpGWjyGl5WeKZ3DrglfjOnb72LySt8LWDiiZnnBHQeqBke SJP4nrpo52drkjEnj2t4 =nN0E -----END PGP SIGNATURE----- --=_8bxwBC2XGoRk64zBzT069Nw-- From owner-freebsd-fs@freebsd.org Sat Jul 14 00:43:02 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C5A9102D698 for ; Sat, 14 Jul 2018 00:43:02 +0000 (UTC) (envelope-from jack@chillysky.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE0F77FD2C for ; Sat, 14 Jul 2018 00:43:01 +0000 (UTC) (envelope-from jack@chillysky.com) Received: by mail-wm0-x231.google.com with SMTP id s14-v6so10846754wmc.1 for ; Fri, 13 Jul 2018 17:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chillysky-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=3BEUZKg2niGJfVwMrhIzIaMfPn2PhaHZoGARmi0oP7Q=; b=loMB6oxuHKw75Hnkx8y5IVFNAi7Ine6Y5w2ef6SvrYnfl7vZvxWRVgkr3fmeST4kvo rLRdQUXJCKSRhkIj7FKvaYwdLyvf/zVHs5wLvN8lUhE5UAlBTppQAlbxHj1dVmKU+abX s0aHBryTLl4YiBfNzJLui4kIRvMvN10a0UjtpHtk4mCHaBJlh8VfLJ0nliv0CltDhuw6 wzRav6Ss9WtkqSmN8IH/64Ao5hG9bOu4XzGIIKMKiPUwA08Epdc66c4Z4ZkNnpPBfYOJ pR9KCQ7tn4T7aS2hM7hVg4nFTIdk+/HLM7ayrZwo4DEnX9mAbixf5xVPUjJBuX3d4Tlg DgOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3BEUZKg2niGJfVwMrhIzIaMfPn2PhaHZoGARmi0oP7Q=; b=s/naVvCOeuFhD9HZrh+a5nkm/m4Z5+viD+A8wGkinD/INi2dNIv6f9hhQ45DsTKMIJ y9wXkVqTp0KwHMC+Q/2+quVafVYLYGR7qN7E+cIilgAqAsuYb/8jWRsQRI8W22hqWvzq 6G80DyJEROi5QNyeJLl3QkSqixozZo0yiglrVtwWMkxRWtbPYpqToz8P2MwnYqg9prpN h7DJ7t0pZIfBGLhUOW21g9EhF60zWD0B7XCMuiXKYjOq4CNf2qWYqmLfLhjg234P+kRf ARfMyqw13WsdXckALuAaVA1D8cQra365oJXdHI8m0BnnSGWW5+W/6EEbJc+Rah/8Nqt7 44+Q== X-Gm-Message-State: AOUpUlHcOkN8sd4YQaarn2jYs5ICcADjLfVJxowZPTPnUyfJAH9eesih coP3ZydtfiIS74pKJWYn6TsjmU2b+PrQ8XkOxeD4hOFjFv4= X-Google-Smtp-Source: AAOMgpf7FqA8qJQIAEkEcWXm6Rgbzv0YcKSnCUuNFXgSLtL3iEIX/VOE6d6YSnMRdO5jTV0WT31UF1ylX0FtHT2kzuM= X-Received: by 2002:a1c:4143:: with SMTP id o64-v6mr5351156wma.123.1531528979902; Fri, 13 Jul 2018 17:42:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:3b09:0:0:0:0:0 with HTTP; Fri, 13 Jul 2018 17:42:59 -0700 (PDT) From: Jack Humphries Date: Fri, 13 Jul 2018 17:42:59 -0700 Message-ID: Subject: tmpfs questions To: freebsd-fs@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 00:43:02 -0000 Hi everyone, I'm trying to study the FreeBSD tmpfs implementation as a personal project, and I had a couple questions. I've been looking through the code for a week and modifying various parts. I appreciate any help! 1. It seems that vnodes are locked before being passed to the various VOP functions in tmpfs (because there is a call to MPASS(VOP_ISLOCKED(vp)) near the beginning of each function). Therefore, is the implicit assumption that a thread that holds the vnode lock has exclusive access to the corresponding tmpfs_node struct? In other words, is this why there are accesses to the tmpfs node variables even though the tmpfs node is not locked? Note: I see tn_interlock, but based on a comment above it in the source, it only protects tn_vpstate and tn_status. 2. What is the duplicate node list for (tn_dupindex)? If I had to guess, it seems to have something to do with the case where one thread calls readdir on a directory while another is modifying the directory, but I'm not sure. Can someone explain this deeper? Thanks. Jack Humphries From owner-freebsd-fs@freebsd.org Sat Jul 14 07:48:43 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69A551044559 for ; Sat, 14 Jul 2018 07:48:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BFA6C8F0F8 for ; Sat, 14 Jul 2018 07:48:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w6E7mT6r029521 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 14 Jul 2018 10:48:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w6E7mT6r029521 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w6E7mTDa029520; Sat, 14 Jul 2018 10:48:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 14 Jul 2018 10:48:29 +0300 From: Konstantin Belousov To: Jack Humphries Cc: freebsd-fs@freebsd.org Subject: Re: tmpfs questions Message-ID: <20180714074829.GR5562@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 07:48:43 -0000 On Fri, Jul 13, 2018 at 05:42:59PM -0700, Jack Humphries wrote: > Hi everyone, > > I'm trying to study the FreeBSD tmpfs implementation as a personal > project, and I had a couple questions. I've been looking through the > code for a week and modifying various parts. I appreciate any help! > > 1. It seems that vnodes are locked before being passed to the various > VOP functions in tmpfs (because there is a call to > MPASS(VOP_ISLOCKED(vp)) near the beginning of each function). > Therefore, is the implicit assumption that a thread that holds the > vnode lock has exclusive access to the corresponding tmpfs_node > struct? In other words, is this why there are accesses to the tmpfs > node variables even though the tmpfs node is not locked? Note: I see > tn_interlock, but based on a comment above it in the source, it only > protects tn_vpstate and tn_status. tmpfs nodes are protected by the vnode locks. Note that vnode lock can be held exclusive or shared. Typically, only exclusive lock allows the code to modify the node, owning shared vnode lock only means that the node can be read safely. Interlock exists because node state must be examined sometimes without owning the vnode lock, in non-sleepable context. > > 2. What is the duplicate node list for (tn_dupindex)? If I had to > guess, it seems to have something to do with the case where one thread > calls readdir on a directory while another is modifying the directory, > but I'm not sure. Can someone explain this deeper? As an optimization, children of the directory node are organized into red/black tree, which cannot hold two entries with the same key value. If a second entry with the existing key is attempted to be created in the directory, it is added to the dup list instead.