From owner-svn-src-all@freebsd.org Sat Dec 12 18:10:44 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDF54A14EC1; Sat, 12 Dec 2015 18:10:43 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC0BD13C8; Sat, 12 Dec 2015 18:10:43 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 8CD1318B8; Sat, 12 Dec 2015 18:10:41 +0000 (UTC) (envelope-from ae@FreeBSD.org) Subject: Re: svn commit: r292058 - head/sbin/geom/class/part To: Ian Lepore , Alexey Dokuchaev References: <201512101037.tBAAbDMq065138@repo.freebsd.org> <1449767147.1358.62.camel@freebsd.org> <5669B969.5020605@FreeBSD.org> <20151212121209.GA60800@FreeBSD.org> <1449940829.1358.154.camel@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: "Andrey V. Elsukov" X-Enigmail-Draft-Status: N1110 Message-ID: <566C6307.70200@FreeBSD.org> Date: Sat, 12 Dec 2015 21:10:15 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1449940829.1358.154.camel@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SqfIPepbUVEapbF5QW8uJT8oehujB4ubj" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2015 18:10:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SqfIPepbUVEapbF5QW8uJT8oehujB4ubj Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12.12.15 20:20, Ian Lepore wrote: > I spent much of the last week fighting with "geom destroy" and trying > to prevent the ressurection of old geoms during the creation of new > ones. It's a Big Mess and it doesn't really work well at all. I came > to the conclusion that it's not geom destroy that needs a force flag so= > much as geom create, where it would mean "it is okay to replace any > existing geom with the new one." Let's be honest. This problem is completely unrelated to what I committed= =2E > For example if you have a freebsd slice da0s1 that contains freebsd > partitions within it, and you geom destroy -F da0 then that slice and > the partitions within it disappear. Then as soon as you create a new > geom for the device and add a slice that happens to fall on the same > sector that da0s1 used to live at, suddenly that whole geom tree comes > back to life and your next command to create a new geom da0s1 fails > because it already exists. >=20 > With a task like formatting and populating an sd card with a script, > you have to deal with whatever data is on the sd card when it's first > inserted. You don't know where existing geoms might be, and it's quite= > burdensome to write script code to figure that out and do a recursive > destroy -F. (Actually, a "geom destroy -R -F" to recursively clean > everything would be quite nice.) Recursive destroying can be easily implemented in the mentioned script. But yes, this also can be done in gpart(8). > I eventually worked around the problem by using the no-commit feature > to do all the work in the sort of virtual space that creates, then > commit everything after the whole volume is laid out. That process is > another Big Mess, because it turns out you have to commit each geom > individually. >=20 > Just committing the top level doesn't recurse and that creates insanity= > because now you've got uncommitted nested geoms that are somehow locked= > such that anything you try to do results in permission errors with no > clue why root doesn't have permission to do commands that usually work > fine. (I literally had to add printfs to sys/geom code and reboot with= > that kernel to figure out what was wrong.) >=20 > Maybe it shouldn't be possible to commit an outer geom if it contains > uncommitted nested geoms. Or maybe commit should have a -R flag to > recurse automatically as well (but that would have to be implemented on= > the kernel side, unless there's some way to query from userland about > whether a geom is committed or not). You can determine what geom is uncommitted by "modified: true" attribute.= # gpart list | grep modified --=20 WBR, Andrey V. Elsukov --SqfIPepbUVEapbF5QW8uJT8oehujB4ubj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWbGMIAAoJEAHF6gQQyKF6iwwH/1yJrnlENJPUcFRiQ4sIBSq8 ckdiSpYapakG7R3j3woeclLnYsvPrJOvve0BI6kTRlFiYF4KXP8afpE8b3Ot+pY8 1a0gb1skp8ZOcCrVPtjcep8x0mrP/lI18q6PpRmjorQnlIcAzHG0Gc87HLfg9H77 tOnapcvKYLeJPvbDWitPu85D9YuuzOBZcWG0dJ+5wwg+LVYAt5Yqkt0zo2+/0Ag9 XOWJkAJvu6jMf/8Q1/1sM8sGAN6u69jy/t63gGjyqDQ3R1CXeUMX59SMAoUB+RZd XKytQr8E1hANw4N9RClnGNi7xKbLKPIYRk7lHiAw33kvKA5QM9omOSGutWdJuZU= =GsMl -----END PGP SIGNATURE----- --SqfIPepbUVEapbF5QW8uJT8oehujB4ubj--